本文目录一览：
- 1、如何防止xss攻击，需要过滤什么
- 2、2-WAF主要过滤方式及绕过(HPP污染&分块传输&垃圾数据)
- 3、网站受到了XSS攻击，有什么办法？
- 4、关于alert(1)的xss问题？
- 5、CSP策略及绕过方法
如何防止xss攻击，需要过滤什么
XSS攻击通常是指黑客通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微软提出，至今已经成为一个标准。浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie。目前主流浏览器都支持，HttpOnly解决是XSS后的Cookie支持攻击。
我们来看下百度有没有使用。
未登录时的Cookie信息
可以看到，所有Cookie都没有设置HttpOnly，现在我登录下
发现在个叫BDUSS的Cookie设置了HttpOnly。可以猜测此Cookie用于认证。
下面我用PHP来实现下：
?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?
script
alert(document.cookie);
/script
js只能读到没有HttpOnly标识的Cookie
二、输入检查
输入检查一般是检查用户输入的数据中是否包含一些特殊字符，如、、'、"等，如果发现存在特殊字符，则将这些字符过滤或者编码。
例如网站注册经常用户名只允许字母和数字的组合，或者邮箱电话，我们会在前端用js进行检查，但在服务器端代码必须再次检查一次，因为客户端的检查很容易绕过。
网上有许多开源的“XSS Filter”的实现，但是它们应该选择性的使用，因为它们对特殊字符的过滤可能并非数据的本意。比如一款php的lib_filter类：
$filter = new lib_filter();
echo $filter-go('1+11');
它输出的是1，这大大歪曲了数据的语义，因此什么情况应该对哪些字符进行过滤应该适情况而定。
三、输出检查
大多人都知道输入需要做检查，但却忽略了输出检查。
1、在HTML标签中输出
如代码：
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=$b?/div
a href="#"?=$a?/a
这样客户端受到xss攻击，解决方法就是对变量使用htmlEncode,php中的函数是htmlentities
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=htmlentities($b)?/div
a href="#"?=htmlentities($a)?/a
2、在HTML属性中输出
div id="div" name ="$var"/div
这种情况防御也是使用htmlEncode
在owasp-php中实现：
$immune_htmlattr = array(',', '.', '-', '_');
$this-htmlEntityCodec-encode($this-immune_htmlattr, "\"script123123;/script\"");
3、在script标签中输出
如代码：
?php
$c = "1;alert(3)";
?
script type="text/javascript"
var c = ?=$c?;
/script
这样xss又生效了。首先js变量输出一定要在引号内，但是如果我$c = "\"abc;alert(123);//"，你会发现放引号中都没用，自带的函数都不能很好的满足。这时只能使用一个更加严格的JavascriptEncode函数来保证安全——除数字、字母外的所有字符，都使用十六进制"\xHH"的方式进行编码。这里我采用开源的owasp-php方法来实现
$immune = array("");
echo $this-javascriptCodec-encode($immune, "\"abc;alert(123);//");
最后输出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中输出
a href="#" onclick="funcA('$var')" test/a
可能攻击方法
a href="#" onclick="funcA('');alter(/xss/;//')"test/a
这个其实就是写在script中，所以跟3防御相同
5、在css中输出
在owasp-php中实现：
$immune = array("");
$this-cssCodec-encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中输出
先确保变量是否是"http"开头，然后再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中实现：
$instance = ESAPI::getEncoder();
$instance-encodeForURL(‘url’);
四、处理富文体
就像我写这篇博客，我几乎可以随意输入任意字符，插入图片，插入代码，还可以设置样式。这个时要做的就是设置好白名单，严格控制标签。能自定义 css件麻烦事，因此最好使用成熟的开源框架来检查。php可以使用htmlpurify
五、防御DOM Based XSS
DOM Based XSS是从javascript中输出数据到HTML页面里。
script
var x = "$var";
document.write("a href='"+x+"'test/a");
/script
按照三中输出检查用到的防御方法，在x赋值时进行编码，但是当document.write输出数据到HTML时，浏览器重新渲染了页面，会将x进行解码，因此这么一来，相当于没有编码，而产生xss。
防御方法：首先，还是应该做输出防御编码的，但后面如果是输出到事件或脚本，则要再做一次javascriptEncode编码，如果是输出到HTML内容或属性，则要做一次HTMLEncode。
会触发DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
2-WAF主要过滤方式及绕过(HPP污染&分块传输&垃圾数据)
1、速度流量问题
2、工具的指纹被识别
3、工具的检测Poc或Payload
1、SQL注入文件上传绕过
2、XSS跨站其他漏洞绕过
3、HPP污染垃圾数据分块等
SQL注入
关键字替换
like 1
like 12
更换提交方式：
POST id=-1 union select 1,2,3--+
模拟文件上传 传递数据
分块传输：更改数据请求格式
HPP参数污染：id=1/* id=-1%20union%20select%201,2,3%23 /
文件上传：换行解析垃圾溢出%00干扰=符号干扰参数模拟
filename=a.php
filename="a.php
filename="a.php%00"
垃圾数据;filename="a.php"
无限filename;filename="a.php"
filename=="a.php"
filename="name='uploadfile.php"
filename="Content-Disposition: form-data.php"
filename=="a.ph
p"
python sqlmap.py -u " *submit=%E6%9F%A5%E8%AF%A2 " --random-agent --tamper= rdog.py --proxy=" "
格式替换
python xsstrike.py -u " ;submit=submit " --proxy
txt= y);submit=%E6%8F%90%E4%BA%A4
文件包含：没什么好说的就这几种
..\ ..../ ...\等
安全狗：
注入 xss 文件上传拦截
rce 文件包含 等其他不拦截
宝塔：
注入 上传拦截
rce 文件包含 xss等其他不拦截
其中拦截的是关键字
aliyun
拦截的CC速度 和 后门 信息收集和权限维持阶段拦截
漏洞利用 他不拦截 默认的版本（升级版本没测试）
WAF PHP环境 JAVA不支持
网站受到了XSS攻击，有什么办法？
一.跨站脚本攻击(XSS)
跨站脚本攻击（XSS，Cross-site scripting）是最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用 户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击
常见解决办法:确保输出到HTML页面的数据以HTML的方式被转义
出错的页面的漏洞也可能造成XSS攻击.比如页面/gift/giftList.htm?page=2找不到,出错页面直接把该url原样输出,如果攻击者在url后面加上攻击代码发给受害者,就有可能出现XSS攻击
二. 跨站请求伪造攻击（CSRF)
跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了 假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接
解决的思路有:
1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现
2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人
三.Http Heads攻击
凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议.HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到 headers中，这种攻击就可以发生
以登陆为例:有这样一个url:
当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location:
假如把URL修改一下，变成这个样子：
那么重定向发生时的reponse会变成下面的样子：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: ;CRLF
CRLF
scriptalert('hello')/script
这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（CRLFSet-Cookie: evil=value）等。
避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。
服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K，Aapche Server将会返回400 Bad Request响应：
对于大多数情况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害 者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减少因header过大而产生的拒绝访问攻击
四.Cookie攻击
通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特 性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。
现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性
五.重定向攻击
一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信 任、窃取用户资料的目的。为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.常见解决方案是白名单,将合法的要重定向 的url加到白名单中,非白名单上的域名重定向时拒之,第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.
六.上传文件攻击
1.文件名攻击,上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.
2.文件后缀攻击.上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.
3.文件内容攻击.IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可 能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。
关于alert(1)的xss问题？
这是一般用来测试一个 xss 是否能成功的绕过各种 html (entities) 防御机制而运行到的 script.
如果可以执行 alert(1), 那就是可以执行任何 script 了. xss 的最基本生存空间就是这样.
相当於写一般程序的第一个程序 print "hello world!"
CSP策略及绕过方法
XSS的时候经常要绕过CSP，这里总结一下
一个CSP头由多组CSP策略组成，中间由分号分隔，就像这样：
其中每一组策略包含一个 策略指令 和一个 内容源 列表
default-src 指令定义了那些没有被更精确指令指定的安全策略。这些指令包括：
script-src定义了页面中Javascript的有效来源
style-src定义了页面中CSS样式的有效来源
img-src定义了页面中图片和图标的有效来源
font-src定义了字体加载的有效来源
connect-src定义了请求、XMLHttpRequest、WebSocket 和 EventSource 的连接来源。
child-src 指定定义了 web workers 以及嵌套的浏览上下文（如frame和iframe）的源。
内容源有三种：源列表、关键字和数据
源列表是一个字符串，指定了一个或多个互联网主机（通过主机名或 IP 地址），和可选的或端口号。站点地址可以包含可选的通配符前缀 (星号, '*')，端口号也可以使用通配符 (同样是 '*') 来表明所有合法端口都是有效来源。主机通过空格分隔。
有效的主机表达式包括：
http://* .foo.com （匹配所有使用 http协议加载 foo.com 任何子域名的尝试。）
mail.foo.com:443 （匹配所有访问 mail.foo.com 的 443 端口 的尝试。）
（匹配所有使用 https协议访问 store.foo.com 的尝试。）
如果端口号没有被指定，浏览器会使用指定协议的默认端口号。如果协议没有被指定，浏览器会使用访问该文档时的协议。
CSP的设置可能情况太多，这里只讨论几个比较典型的情况。
在default-src 'none'的情况下，可以使用meta标签实现跳转
在允许unsafe-inline的情况下，可以用window.location，或者window.open之类的方法进行跳转绕过。
CSP对link标签的预加载功能考虑不完善。
在Chrome下，可以使用如下标签发送cookie（最新版Chrome会禁止）
在Firefox下，可以将cookie作为子域名，用dns预解析的方式把cookie带出去，查看dns服务器的日志就能得到cookie
有些网站限制只有某些脚本才能使用，往往会使用script标签的nonce属性，只有nonce一致的脚本才生效，比如CSP设置成下面这样：
那么当脚本插入点为如下的情况时
可以插入
这样会拼成一个新的script标签，其中的src可以自由设定
Blackhat2017上有篇 ppt 总结了可以被用来绕过CSP的一些JS库。
例如假设页面中使用了Jquery-mobile库，并且CSP策略中包含"script-src 'unsafe-eval'"或者"script-src 'strict-dynamic'"，那么下面的向量就可以绕过CSP：
在这个PPT之外的还有一些库也可以被利用，例如RCTF2018中遇到的amp库，下面的标签可以获取名字为FLAG的cookie
1.如果页面A中有CSP限制，但是页面B中没有，同时A和B同源，那么就可以在A页面中包含B页面来绕过CSP：
2.在Chrome下，iframe标签支持csp属性，这有时候可以用来绕过一些防御，例如" "页面有个js库会过滤XSS向量，我们就可以使用csp属性来禁掉这个js库。
meta标签有一些不常用的功能有时候有奇效：
meta可以控制缓存（在header没有设置的情况下），有时候可以用来绕过CSP nonce。
meta可以设置Cookie（Firefox下），可以结合self-xss利用。