- 四两拨千斤：HttpOnIy
严格地说，HttpOnly并非为了对抗XSS——HttpOnly解决的是XSS后的Cookie劫持攻击。
Cookie设置了HttpOnly，则使用XSS窃取用户的Cookie会失败，因为JavaScript读取不到Cookie的值。
但是，HttpOnly不是万能的，添加了HttpOnly不等于解决了XSS问题。XSS攻击带来的不光是Cookie劫持问题，还有窃取用户信息、模拟用户身份执行操作等诸多严重的后果。如前文所述，攻击者利用AJAX构造HTTP请求，以用户身份完成的操作，就是在不知道用户Cookie的情况下进行的。使用HttpOnly有助于缓解XSS攻击，但仍然需要其他能够解决XSS漏洞的方案。 - 输入检查
使用XSS Filter类，过滤掉非法字符，但要注意不要误伤友军。 - 输出检查
一般来说，除了富文本的输出外，在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击
3.1 安全的编码函数
编码分为很多种，针对HTML代码的编码方式是HtmlEncode。
HtmlEncode并非专用名词，它只是一种函数实现。它的作用是将字符转换成HTMLEntities，对应的标准是ISO-8859-1。
为了对抗XSS，在HtmlEncode中要求至少转换以下字符：
& --> &
< --> <--> >
" --> "
/ --> / 包含反斜线是因为它可能会闭合一些HTML entity
在PHP中，有htmlentities() 和htmlspecialchars() 两个函数可以满足安全要求。
相应地，JavaScript的编码方式可以使用JavascriptEncode。 - 正确地防御XSS
为了更好地设计XSS防御方案，需要认清XSS产生的本质原因。XSS的本质还是一种“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而混淆了原本的语义，产生了新的语义。
如果网站使用了MVC架构，那么XSS就发生在View层——在应用拼接变量到HTML页面时产生。所以在用户提交数据处进行输入检查的方案，其实并不是在真正发生攻击的地方做防御。
想要根治XSS问题，可以列出所有XSS可能发生的场景，再一一解决。 - 处理富文本
如何区分安全的“富文本”和有攻击性的XSS呢？
在处理富文本时，还是要回到“输入检查”的思路上来。“输入检查”的主要问题是，在检查时还不知道变量的输出语境。但用户提交的“富文本”数据，其语义是完整的HTML代码，在输出时也不会拼凑到某个标签的属性中。因此可以特殊情况特殊处理。
在上一节中，列出了所有在HTML中可能执行脚本的地方。而一个优秀的“XSS Filter”，也应该能够找出HTML代码中所有可能执行脚本的地方。
HTML是一种结构化的语言，比较好分析。通过htmlparser可以解析出HTML代码的标签、标签属性和事件。在过滤富文本时，“事件”应该被严格禁止，因为“富文本”的展示需求里不应该包括“事件”这种动态效果。而一些危险的标签，比如<iframe>、<script>、<base>、<form>等，也是应该严格禁止的。
在标签的选择上，应该使用白名单，避免使用黑名单。比如，只允许 <a>、<img>、<div>等比较“安全”的标签存在。
“白名单原则”不仅仅用于标签的选择，同样应该用于属性与事件的选择。
在富文本过滤中，处理CSS也是一件麻烦的事情。如果允许用户自定义CSS、style，则也可能导致XSS攻击。因此尽可能地禁止用户自定义CSS与style。 - 防御DOM Based XSS
DOM Based XSS是一种比较特别的XSS漏洞，前文提到的几种防御方法都不太适用，需要特别对待。
事实上，DOM Based XSS是从JavaScript中输出数据到HTML页面里。而前文提到的方法都是针对“从服务器应用直接输出到HTML页面”的XSS漏洞，因此并不适用于DOM Based XSS。
从JavaScript输出到HTML页面，也相当于一次XSS输出的过程，需要分语境使用不同的编码函数。
文章为总结整理文，原文来自：《白帽子讲Web安全》
https://weread.qq.com/web/reader/7c4327b05cfd497c4eaa52f
