03-
XSS Auditor
xss auditor是Chrome 和 Safari中内建的一个防御xss攻击的功能模块,相当于一个审计器,有预设规则,主要功能就是针对上述这种情况。此功能默认是开启的,当然也可以关闭,需要在response header中显式指定:
//关闭 xss auditor
X-XSS-Protection: 0
当然,更强大的是,触发后还可以将详情上报,便于分析跟踪:
X-XSS-Protection: 1; report=http://example.com/your_report_URI
也可以使用block模式:一旦触发,当前页面就会终止,并同时展示一个空白页面给用户:
X-XSS-Protection: 1; mode=block
如果将请求换成post,xss auditor还会被触发吗?答案是:可以!
XSS Auditor的缺点
我们将后台逻辑改一下,给每个">"后加一个分号。
if(isset($_REQUEST["wd"]))
$wd=str_replace(">",">;",$_REQUEST["wd"]);
if($wd){
echo "
关键字'$wd'搜索的结果如下:
"}
?>
然后依然是之前的链接,刷新:
alert
成功了,当然本例只是一个说明,通常情况下,我们都会对用户提交的数据进行一些处理,如果这些处理导致和提交的内容不一样了,但是仍然可以执行,比如像本例一样。那么xss auditor 就无能为力了。不过xss auditor本身的智能度也挺高,像字符编码,大小写变化这种变化依然躲不过xss auditor。
04-
存储型xss
比如网站有个留言板功能,但后台未对用户输入进行过滤,攻击者可以在留言编辑框中输入:
然后再随便输入点其它文字,提交留言,提交成功后,内容将会被保存到服务器数据库,只要再访问留言列表,这个就会被插入到网页中,xss.payload.js中的代码就可以执行,如果访问的用户都是已登录用户,xss.payload.js可以获取老浏览用户的信息,如的登录token、用户的个人资料等,payload甚至可以拉一个全家桶下来。以前的防御手段主要是对用户输入进行过滤如:去除html标签,实体化,关键字过滤等等,这样一来,最终的结果就是后台的大多数代码都是在做字符串验证,非常的让人不舒服。所以W3 org引入了CSP:
05-
Content-Security-Policy