struts2 有没有jar包能防止xss攻击
配置struts.xml
package name="default" namespace="/"
extends="struts-default, json-default"
!-- 配置拦截器 --
interceptors
!-- 定义xss拦截器 --
interceptor name="xssInterceptor" class="...此处填写拦截器类名"/interceptor
!-- 定义一个包含xss拦截的拦截栈 --
interceptor-stack name="myDefault"
interceptor-ref name="xssInterceptor"/interceptor-ref
interceptor-ref name="defaultStack"/interceptor-ref
/interceptor-stack
/interceptors
!-- 这个必须配置,否则拦截器不生效 --
default-interceptor-ref name="myDefault"/default-interceptor-ref
action
...此处省略n个action
/action
/package
servlet filter和springMVC拦截器的区别
在struts2中用过filter过滤器,在springmvc中还有拦截器,它们都能过滤请求,但是到底有什么区别呢?
一、定义
拦截器 :是在面向切面编程的就是在你的service或者一个 *** ,前调用一个 *** ,或者在 *** 后调用一个 *** 比如动态 *** 就是拦截器的简单实现,在你调用 *** 前打印出字符串(或者做其它业务逻辑的操作),也可以在你调用 *** 后打印出字符串,甚至在你抛出异常的时候做业务逻辑的操作。
过滤器:是在javaweb中,你传入的request、response提前过滤掉一些信息,或者提前设置一些参数,然后再传入servlet或者struts的action进行业务逻辑,比如过滤掉非法url(不是login.do的地址请求,如果用户没有登陆都过滤掉),或者在传入servlet或者 struts的action前统一设置字符集,或者去除掉一些非法字符.。
二、xml文件配置
1.filter
该过滤器的 *** 是创建一个类XXXFilter实现此接口,并在该类中的doFilter *** 中声明过滤规则,然后在配置文件web.xml中声明他所过滤的路径
filter
filter-nameXXXFilter/filter-name
filter-class
com.web.util.XXXFilter
/filter-class
/filter
filter-mapping
filter-nameXXXFilter/filter-name
url-pattern*.action/url-pattern
/filter-mapping
filter
filter-nameXXXFilter/filter-name
filter-class
com.web.util.XXXFilter
/filter-class
/filter
filter-mapping
filter-nameXXXFilter/filter-name
url-pattern*.action/url-pattern
/filter-mapping
2.Interceptor
它也要实现HandlerInterceptor 接口,这里只介绍 *** 注解配置
!-- 拦截器 --
mvc:interceptors
!-- 多个拦截器,顺序执行 --
mvc:interceptor
mvc:mapping path="/entryOrJsonController/*" /!-- 如果不配置或/*,将拦截所有的Controller --
bean class="com.wy.interceptor.CommonInterceptor"/bean
/mvc:interceptor
/mvc:interceptors
!-- 拦截器 --
mvc:interceptors
!-- 多个拦截器,顺序执行 --
mvc:interceptor
mvc:mapping path="/entryOrJsonController/*" /!-- 如果不配置或/*,将拦截所有的Controller --
bean class="com.wy.interceptor.CommonInterceptor"/bean
/mvc:interceptor
/mvc:interceptors
三、具体区别
filter
Interceptor
多个的执行顺序
根据filter mapping配置的先后顺序
按照配置的顺序,但是可以通过order控制顺序
规范
在Servlet规范中定义的,是Servlet容器支持的
Spring容器内的,是Spring框架支持的。
使用范围
只能用于Web程序中
既可以用于Web程序,也可以用于Application、Swing程序中。
深度
Filter在只在Servlet前后起作用
拦截器能够深入到 *** 前后、异常抛出前后等
四、总结
两者的本质区别:拦截器是基于java的反射机制的,而过滤器是基于函数回调。从灵活性上说拦截器功能更强大些,Filter能做的事情,他都能做,而且可以在请求前,请求后执行,比较灵活。Filter主要是针对URL地址做一个编码的事情、过滤掉没用的参数、安全校验(比较泛的,比如登录不登录之类),太细的话,还是建议用interceptor。不过还是根据不同情况选择合适的。
web攻击有哪些?怎么防护?
1、DoS和DDoS攻击(DoS(Denial of Service),即拒绝服务,造成远程服务器拒绝服务的行为被称为DoS攻击。其目的是使计算机或 *** 无法提供正常的服务。最常见的DoS攻击有计算机 *** 带宽攻击和连通性攻击)
防范:(1) 反欺骗:对数据包的地址及端口的正确性进行验证,同时进行反向探测。(2) 协议栈行为模式分析:每个数据包类型需要符合RFC规定,这就好像每个数据包都要有完整规范的着装,只要不符合规范,就自动识别并将其过滤掉。(3) 特定应用防护:非法流量总是有一些特定特征的,这就好比即便你混进了顾客群中,但你的行为还是会暴露出你的动机,比如老重复问店员同一个问题,老做同样的动作,这样你仍然还是会被发现的。(4) 带宽控制:真实的访问数据过大时,可以限制其更大输出的流量,以减少下游 *** 系统的压力。
2、CSRF(Cross Site Request Forgery),即跨站请求伪造,是一种常见的Web攻击,但很多开发者对它很陌生。CSRF也是Web安全中最容易被忽略的一种攻击。
防范:(1) 验证码。应用程序和用户进行交互过程中,特别是账户交易这种核心步骤,强制用户输入验证码,才能完成最终请求。在通常情况下,验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验,网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段,在关键业务点设置验证码。(2) Referer Check。HTTP Referer是header的一部分,当浏览器向web服务器发送请求时,一般会带上Referer信息告诉服务器是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律,如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面,来判断是不是CSRF攻击。但在某些情况下如从https跳转到http,浏览器处于安全考虑,不会发送referer,服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞,那么攻击者可以在其他网站注入恶意脚本,受害者进入了此类同域的网址,也会遭受攻击。出于以上原因,无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。(3) Anti CSRF Token。目前比较完善的解决方案是加入Anti-CSRF-Token,即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token,并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值,会进行校验该请求当中的token和cookie当中的token值是否都存在且相等,才认为这是合法的请求。否则认为这次请求是违法的,拒绝该次服务。这种 *** 相比Referer检查要安全很多,token可以在用户登陆后产生并放于session或cookie中,然后在每次请求时服务器把token从session或cookie中拿出,与本次请求中的token 进行比对。由于token的存在,攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时,当某个页面消耗掉token后,其他页面的表单保存的还是被消耗掉的那个token,其他页面的表单提交时会出现token错误。
3、XSS(Cross Site Scripting),跨站脚本攻击。为和层叠样式表(Cascading Style Sheets,CSS)区分开,跨站脚本在安全领域叫做“XSS”。
防范:(1) 输入过滤。永远不要相信用户的输入,对用户输入的数据做一定的过滤。如输入的数据是否符合预期的格式,比如日期格式,Email格式, *** 号码格式等等。这样可以初步对XSS漏洞进行防御。上面的措施只在web端做了限制,攻击者通抓包工具如Fiddler还是可以绕过前端输入的限制,修改请求注入攻击脚本。因此,后台服务器需要在接收到用户输入的数据后,对特殊危险字符进行过滤或者转义处理,然后再存储到数据库中。(2) 输出编码。服务器端输出到浏览器的数据,可以使用系统的安全函数来进行编码或转义来防范XSS攻击。在PHP中,有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。相应的JavaScript的编码方式可以使用JavascriptEncode。(3) 安全编码。开发需尽量避免Web客户端文档重写、重定向或其他敏感操作,同时要避免使用客户端数据,这些操作需尽量在服务器端使用动态页面来实现。(4) HttpOnly Cookie。预防XSS攻击窃取用户cookie最有效的防御手段。Web应用程序在设置cookie时,将其属性设为HttpOnly,就可以避免该网页的cookie被客户端恶意JavaScript窃取,保护用户cookie信息。(5)WAF(Web Application Firewall),Web应用防火墙,主要的功能是防范诸如网页木马、XSS以及CSRF等常见的Web漏洞攻击。由第三方公司开发,在企业环境中深受欢迎。
4、SQL注入(SQL Injection),应用程序在向后台数据库传递SQL(Structured Query Language,结构化查询语言)时,攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
防范:(1) 防止系统敏感信息泄露。设置php.ini选项display_errors=off,防止php脚本出错之后,在web页面输出敏感信息错误,让攻击者有机可乘。(2) 数据转义。设置php.ini选项magic_quotes_gpc=on,它会将提交的变量中所有的’(单引号),”(双引号),\(反斜杠),空白字符等都在前面自动加上\。或者采用mysql_real_escape()函数或addslashes()函数进行输入参数的转义。(3) 增加黑名单或者白名单验证。白名单验证一般指,检查用户输入是否是符合预期的类型、长度、数值范围或者其他格式标准。黑名单验证是指,若在用户输入中,包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时,一般会配合黑名单验证。
5、上传漏洞在DVBBS6.0时代被黑客们利用的最为猖獗,利用上传漏洞可以直接得到WEBSHELL,危害等级超级高,现在的入侵中上传漏洞也是常见的漏洞。该漏洞允许用户上传任意文件可能会让攻击者注入危险内容或恶意代码,并在服务器上运行。
防范: (1)检查服务器是否判断了上传文件类型及后缀。 (2) 定义上传文件类型白名单,即只允许白名单里面类型的文件上传。 (3) 文件上传目录禁止执行脚本解析,避免攻击者进行二次攻击。 Info漏洞 Info漏洞就是CGI把输入的参数原样输出到页面,攻击者通过修改输入参数而达到欺骗用户的目的。
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。