在我上一篇《前端安全之XSS进犯》文中，并没有把XSS进犯的处理办法说完好，而XSS的进犯又那么形形色色，有没有一招“独孤九剑”能够抗衡，究竟那么多状况场景，开发人员无法逐个照料过来，而今日经过阅览《白帽子讲Web安全》这本书，对应对方法有了更好的总结，分为两类，一是服务端能够干的事，二是客户端能够干的事。

条件

在说XSS处理方法时，有一个条件。便是同源战略——浏览器的同源战略（浏览器安全的根底，即使是进犯脚本也要恪守这规律），约束了来自不同源的“document”或脚本，对当时“document”读取或设置某些特点。除了DOM、Cookie、XMLHttpRequest会遭到同源战略的约束外，浏览器加载的一些第三方插件也有各自的同源战略。不过script、img、iframe、link等标签都能够跨域加载资源，而不受同源战略的约束。

服务端能够干的事

1. HttpOnly

其实便是现在HTTP协议（HTTPS也是能够的）才干读取cookies，JavaScript是读取不到cookies的。支撑浏览器是IE6+、Firefox2+、Google、Safari4+。

JavaEE给Cookie增加HttpOnly的代码：

response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

PS：关于HTTPS，仍是能够设置Secure字段，对Cookie进行安全加密。

这是本质上不是防备XSS，而是在被攻破时分不允许JS读取Cookie。

2.处理富文本

有些数据由于运用场景问题，并不能直接在服务端进行转义存储。不过富文本数据语义是完好的HTML代码，在输出时也不会拼凑到某个标签的特点中，所以能够当特别状况特别处理。处理的进程是在服务端装备富文本标签和特点的白名单，不允许呈现其他标签或特点（例如script、iframe、form等），即”XSS Filter“。然后在存储之前进行过滤（过滤原理没有去探明）。

Java有个开源项目Anti-Samy是非常好的XSS Filter：

Policy ploicy = Policy.getInstance(POLICY_FILE_LOCATION); AntiSamy as = new AntiSamy(); CleanResults cr = as.scan(dirtyInput, policy); MyUserDao.storeUserProfile(cr.getCleanHTML());

PS：当然也能够在前端显现前过滤，可是我觉得，让前端人员少做东西好，而且服务端只需要转一次。

客户端能够干的事

1. 输入查看

输入查看的逻辑，有必要放在服务器端代码中完成（由于用JavaScript做输入查看，很简单被进犯者绕过）。现在Web开发的遍及做法，是一起在客户端JavaScript中和服务器代码中完成相同的输入查看。客户端JavaScript的输入查看，能够阻挠大部分误操作的正常用户，然后节省服务资源。

PS：简单说，便是输入查看，服务端和客户端都要做。

[1] [2] [3]  黑客接单网