XSS和CSRF 攻击非常规防御方法

跨站脚本攻击xss: 指恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。
xss漏洞通常是通过php的输出函数将javascript代码输出到html页面中,通过用户本地浏览器执行的,所以xss漏洞关键就是寻找参数未过滤的输出函数
常见的输出函数有: echo printf print print_r sprintf die var-dump var_export

一个经典的防御方法就是对内容进行转义和过滤,比如:

var escapeHtml = function(str) { 
   if(!str) return ''; 
   str = str.replace(/&/g, '&'); 
   str = str.replace(//g, '>'); 
   str = str.replace(/"/g, '&quto;'); 
   str = str.replace(/'/g, '''); 
   // str = str.replace(/ /g, ' '); 
   return str; 
}; 

var name = escapeHtml("<script>alert('SB');</script>");

前面转义的方法的出发点,是让用户的输入不要变成程序,输入的什么就让它输出成什么。
事实上现代浏览器为我们带来了一个全新的安全策略,叫作内容安全策略,Content Security Policy,简称CSP。
它的具体使用方式是在 HTTP 头中输出 CSP 策略:

Content-Security-Policy: <policy-directive>; <policy-directive>;

具体到上面的 XSS 例子,可以使用

Content-Security-Policy: script-src 'self';

CSRF 的常规防御
CSRF 比较常规的防御方式是通过判断来源和加 token。
判断来源比较简单,主要是判断referer这个头,如果不是自己的网站,就返回错误。
加 token 即同样的随机 token,在 cookies 中放一份,在表单中再放一份。这样第三方网站就无法获取到这个 token 是什么。

具体的使用方式,是在打 Cookie 的时候,加上一个属性:SameSite,它的值有两:

  • strict 任何来自第三方的请求都不能使用 Cookies ,包括通过链接点进来的
  • lex 只有比较敏感的操作不带 Cookies ,比如表单提交

针对 CSRF ,我们可以将 Cookies 设置成SameSite: strict的,这样就可以有效防御 CSRF 了。不过比较可惜的是,目前只有 Chrome 才支持这一属性。希望未来所有浏览器都能跟上脚步。