空谈Security攻击方法之CSRF和XSS

其实，关于这两个攻击（CSRF和XSS）的介绍，网上有很多文章，大家可以自行搜索。这里只谈一下个人对它们的理解。

CSRF和XSS

CSRF的全称是Cross Site Request Forgery，中文名称叫跨站请求伪造。

XSS的全称是Cross Site Scripting，中文名称叫跨站脚本攻击。

虽然它们的名字都包含“跨站”，但是它们却是不同的攻击方式，无论是攻击的手段还是攻击的原理，都有很大的不同。

简单描述这两个攻击方式：

CSRF

用户已经登陆了授信网站A，这时黑客发送一个钓鱼网站B给这个用户，当用户点击这个钓鱼网站B时，钓鱼网站B利用用户在授信网站A的session，发送请求给授信网站A后端的API，从而达到一些攻击的目的。

XSS

一个博客网站，黑客发表了一篇文章，内容包含一些scripts，这些scripts的逻辑是调用后端的API关注博主。当其他用户打开浏览器浏览这篇文章时，这些scripts就自动执行，用户就自动关注了黑客的博主。

下面是我对这两个攻击的总结：

1. 它们跟浏览器的same-origin policy（同源策略，是浏览器的一个基本安全功能）有什么关系吗？

如果服务器设置成只允许同源访问，对XSS攻击没有任何帮助，但可以一定程度限制CSRF攻击。

因为CSRF攻击原理上是需要跨域的，所以如果把同源策略放开，即CORS，一定程度上会增加CSRF攻击的风险。但是，即使是同源策略，也不能避免CSRF攻击，因为同源策略只能限制Ajax请求不能跨域，但是<img>、<script>等标签还是可以跨域，所以CSRF攻击任然可以利用这些标签，这也是jsonp的原理。

2. 大方向上，CSRF和XSS是两类不同的攻击方式。CSRF属于伪造攻击（冒充别人的名义干坏事）；而XSS属于注入攻击（sql注入也属于注入攻击）。

3. 从解决方案来讲，CSRF一般来说是加一个token；而XSS则是配置csp（content security policy）白名单策略，目的是只允许信任的scripts才能执行，之前做过的一个项目就是用的一个nodejs的library-helmetjs来配置的csp。

4. 关于实际案例，几年之前新浪微博就遭受过一次大规模的XSS攻击。（See https://tech.qq.com/a/20110628/000413.htm）

CSRF和clickjacking

另外，CSRF和clickjacking（点击劫持）有啥区别呢？（关于clickjacking，可以参考这篇文章：一文带你读懂点击劫持详解+实验）

1. CSRF利用受害者已经登陆的其他网站的session；而clickjacking则是利用iframe把恶意的页面嵌入进来，并且隐藏在正常的页面后面。

2. CSRF可以不需要受害者和UI的交互；而clickjacking则需要受害者和UI的交互，比如受害者点击一个关闭广告的按钮，有可能实际是关注了一个微博的好友。

3. clickjacking攻击的难度更大，因为需要受害者和UI的交互，并且攻击的成本更大。

CORS

最后，再聊一下CORS，因为据我了解，好像很多人对它理解都不是很准确。

1. CORS（Cross-Origin Resource Sharing），中文叫跨域资源共享。

2. CORS不是一个安全功能，相反，CORS降低了安全保障。（参考微软的一篇文档：https://docs.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-3.1#same-origin）

“Cross Origin Resource Sharing (CORS):

• Is a W3C standard that allows a server to relax the same-origin policy.
• Is not a security feature, CORS relaxes security. An API is not safer by allowing CORS. For more information, see How CORS works.
• Allows a server to explicitly allow some cross-origin requests while rejecting others.
• Is safer and more flexible than earlier techniques, such as JSONP.”

3. 同源策略是浏览器的一个安全功能，对于一个跨域请求，服务器会正常处理这个请求，只是会在response加上Access-Control-Allow-Origin的header，当浏览器处理response时，发现有这个header，就会block这个response的渲染，报一个错出来。这也是为什么我们用postman等工具不会有这个问题的原因。有时候我们本地快速开发测试，确实需要跨域，这时我们可以把浏览器的安全功能关掉，就可以正常工作。

chrome.exe --disable-web-security --user-data-dir

这里提醒一下，网上很多文章都说服务器端就把请求reject掉了，其实这种说法是错误的，记住！