解密CSRF、CORS和HTTP安全标头 - vnaik


随着入侵和数据盗窃的数量日益增加,保护Web应用程序极为重要。另一方面,程序员通常对攻击的工作原理以及如何缓解攻击没有足够的了解。这篇文章试图弥补这一差距。
 
CSRF
跨站点请求伪造CSRF是一种攻击,其中第三方迫使用户对他们当前登录的网站执行操作。
这是一个说明其工作原理的示例:

  1. 您访问evil.com
  2. evil.com有一个隐藏的表单,该表单会在页面加载时提交到mybank.com/transfer-funds。由于您已经登录到mybank.com,因此此请求是使用mybank.com cookie发出的,将以静默方式从您的帐户中进行转帐。
  3. 由于“ evil.com ”和“ mybank.com ”的来源不同,因此浏览器拒绝提供对evil.com的响应(由于存在CORS),但攻击者不在乎,这笔钱已经在“mybank.com”转移了。

现在,如果mybank.com正确实现了CSRF保护:
  1. 每次mybank.com向用户提供表单时,它都会生成CSRF令牌并将其插入表单中的隐藏字段中
  2. 当mybank.com收到POST请求,它将根据其数据库检查CSRF令牌-如果该令牌存在且有效,则请求通过。如果CSRF令牌丢失或不正确,它将被拒绝。

CSRF攻击的目标是状态更改请求,而不是数据的直接盗窃,因为攻击者看不到伪造请求的响应。CSRF令牌是永远不会存储在Cookie或永久存储区中的无状态令牌,从而提供了安全性。
需要将CSRF保护支持添加到您的应用程序代码中,并且不能在代理服务器层(例如,在Nginx中)添加CSRF保护支持。OWASP的CSRF的详细介绍
最好始终将SameSite指令与cookie一起使用,因为这可以防止CSRF攻击。
 
CORS
跨域请求共享CORS仅适用于浏览器场景,是一种安全机制,允许一个来源向另一个来源发出请求。所有浏览器都遵循“单一来源策略”,这意味着默认情况下脚本无法向其他来源发出请求-但是,如果服务器提供了正确配置的CORS标头,则可以有选择地放宽此策略。因此,CORS是有选择地放松安全性而不是加强安全性的一种方法。
当网站向另一个来源发出XHR请求时,浏览器会首先启动预检OPTIONS请求-仅当服务器以允许的来源列表响应该预检时,才发出原始请求,并且该列表包含当前来源页。
请注意,浏览器不会为具有默认标头的GET HEAD POST请求发出CORS预检请求。
作为对OPTIONS请求的响应而发送的一些关键标头:
  • access-control-allow-credentials:如果设置,则cookie由浏览器发送
  • access-control-allow-origin:允许发出请求的来源列表,或“ *”允许任何人发出请求的来源。如果设置了access-control-allow-credentials,则不能将其设置为“ *”,否则浏览器将拒绝该请求
  • access-control-allow-methods:允许通信的HTTP方法列表-POST,PUT等。

设置 access-control-allow-credentials 时,access-control-allow-origin 不能为“ *”的原因是为了防止开发人员采用添加*的快捷方式,然后完全忘记它,这种强制行为迫使开发人员考虑如何他们的API将被使用。
CORS会散发经常各种各样的代码坏气味,例如,CORS的常见用途是允许多个属性访问一个API,例如mybank.com的API能被mybankpersonal.com和 mybankbusiness.com访问,在这些情况下,CORS可以通过使用API​​网关可以被完全避免。
如果所有网页均来自同一域(mybank.com),则无需设置CORS标头,并且浏览器可以应用完整的Same Origin Policy,并提供最大的安全性。毕竟,CORS仅用于选择性降低安全性,而不能提高安全性。
另一方面,如果您要提供第三方供浏览器使用的API(例如,经过Oauth流程之后),则不可避免地要使用CORS。
当然,CORS与例如Web浏览器之外的请求无关、与使用Curl或与服务器到服务器的通信无关。
 
XSS
跨站点脚本攻击XSS是一种攻击,攻击者将客户端脚本注入到网页中。XSS可用于绕过同源策略和CSRF保护。
这可以通过破坏服务器(例如,通过使用已知的漏洞利用)或利用不良的用户输入来向网站添加脚本来完成,只要用户访问该网站就会触发该脚本。
这是最常被利用的漏洞,可以通过仔细的清理和编码来修复,以显示所有用户输入-即使像电子邮件地址之类的东西也可能是脚本注入的媒介。例如。,
"><script>alert(1);</script>"@example.org

是RFC 5321的有效电子邮件地址!
XSS最好在输出端进行清理,这样原始数据将作为用户的输入存储在数据库中,然后在再次发送时将其转义为适当的格式。
参考OWASP的XSS绕过了全面的章节 。
防止XSS的OWASP速查表是确保应用程序免受XSS攻击的良好起点。
 
CSP
内容安全策略是检测和缓解XSS攻击的附加安全层。通过指定应被视为脚本有效来源的域,Web浏览器将仅执行从这些白名单域加载的脚本。CSP可以为所有动态原点指定允许的原点,包括脚本,样式表,图像,字体,对象,媒体(音频,视频),框架,甚至是表单动作。
CSP是通过Content-Security-Policy HTTP标头设置的。
与CORS的区别在于,CORS阻止访问第三方服务器,而CSP阻止网站本身从第三方加载内容,以防御XSS。
CSP不是针对XSS的灵丹妙药,但它可以帮助您。最终,需要通过仔细的应用程序设计和有效的用户输入卫生防护(在前端和后端)来防止XSS。
CSP由于其选择的深度而最复杂,而且可能也是最难实施的,因为每次前端开发人员每次添加CDN资源(用于字体,脚本等)时,它都会将CDN添加到CSP标头中。如果没有经过精心设计的测试设置,那么在开发人员测试中就可以正常工作,但是在推向生产阶段时就失败了。
CSP非常复杂,需要不止几个段落-整页将更加合理。
内容安全策略的网站介绍如何CSP支持添加到您的Web服务器和谷歌的方便的测试工具可以帮助测试这些策略。
 
HSTS
HTTP严格传输安全性HSTS通过允许服务器声明浏览器应仅使用HTTPS连接与其进行交互,绝不使用HTTP,这样来防御协议降级攻击和cookie劫持。并且浏览器应始终将所有使用HTTP的访问尝试都转换为HTTPS,例如HTTPS。通过重写所有链接以使用HTTPS代替HTTP。
通过透明地将http连接转换为纯https来防止窃听和中间人攻击。
例如,您可能连接到机场的免费wifi服务以访问您的银行网站,但访问点实际上是黑客的笔记本电脑,该笔记本电脑会进行MITM攻击并将您重定向到该银行网站的克隆。只要您至少通过HTTPS访问银行网站一次(并且银行使用HSTS),HSTS便会在这种情况下提供安全性,浏览器将完全拒绝此请求。
此页面包含有关为Nginx配置HSTS的详细信息。
 
HPKP
HTTP公钥固定HPKP可通过为浏览器提供一组公钥来使HTTPS网站使用欺诈性获得的SSL证书来抵制假冒,这是将来可信任的唯一连接到同一来源的公钥。
与过去使用Comodo发生的情况一样,这可提供安全保护,以防止受到破坏的证书颁发机构的侵害。
在上述机场场景中,如果黑客也有从银行骗取的证书,则仅HSTS不能保护您-但是使用HPKP,即使这种攻击也可以缓解。这是首次使用时信任的技术。
HPKP最终将被Expect-CT标头取代。有关HPKP的更多信息
 
Set-Cookie
这是一个相当标准的标头,到目前为止是页面上最古老的标头,但它也是正确配置最重要(也是最简单)的标头之一。
这可以通过设置一些指令来完成。
  • SameSite: Strict指令抵御来自所有跨域请求打开cookie的CSRF攻击。
  • Secure 指令确保cookie的HTTPS连接只使用过的-从而提供了基于HPKP和HSTS的额外的安全性。
  • HttpOnly指令确保JavaScript不能访问cookie。

通常,您将要设置所有三个。有关Set-Cookie的更多信息
 
其他标头
通常,这些设置不太重要,但需要注意。
  • X-XSS Protection:此标头已过时,可能有害,CSP在提供保护方面做得更好。Chrome的主要工作是触发XSS审核程序,审核程序由于不安全[url=https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ]而被弃用[/url]。
  • X-Frame-Options:此标头指示是否应允许该网站在iFrame中显示。这已被CSP的frame-ancestors选项所取代,该选项在现代浏览器中得到了更好的支持。
  • X-Content-Type-Options:如果未设置Content-Type标头,则可以防止浏览器尝试猜测内容的类型。这可以防止允许用户上传和共享文件的网站受到XSS攻击。
  • X-Download Options(X-下载选项):在涉及上传用户文件的场景中再次有用,当设置为“ noopen”时,这将强制浏览器下载文件,而不是尝试在浏览器中显示该文件。
  • Referrer-Policy:将其设置为“ no-referrerer”时,浏览器在发出请求时不会发送该Referrer,这对于保护隐私很有用。有关referrer-policy的更多信息

 
总体而言,随着Web在功能和复杂性方面的增长,攻击面也相应增大。正确配置的Web服务器和有效使用HTTPS的经过精心设计的应用程序(例如,使用Let's Encrypt)可以提供良好的保护。
另外,本文的许多缓解措施都可以在代理服务器(CSP,HSTS,HPKP)或网络级别(更好的服务器代理,以消除对CORS的需要)中应用,并且只有CSRF和XSS保护才真正需要被添加到应用程序中。