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 才支持这一属性。希望未来所有浏览器都能跟上脚步。