【浏览器】Web安全

[swiftwind0405]

---

XSS

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

XSS类型

类型	存储区	插入点
存储型 XSS	后端数据库	HTML
反射型 XSS	URL	HTML
DOM 型 XSS	后端数据库/前端存储/URL	前端 JavaScript

反射型XSS

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

DOM 型 XSS

DOM 型 XSS 攻击，实际上就是前端 JavaScript 代码不够严谨，把不可信的内容插入到了页面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API时要特别小心，不要把不可信的数据作为 HTML 插到页面上，尽量使用 .innerText、.textContent、.setAttribute() 等。

存储型XSS

恶意脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行，影响范围比反射型和DOM型XSS更大。存储型XSS攻击的原因仍然是没有做好数据过滤：前端提交数据至服务端时，没有做好过滤；服务端在接受到数据时，在存储之前，没有做过滤；前端从服务端请求到数据，没有过滤输出。

防御手段

主要防御手段：字符转义。

其他防御手段：

除了谨慎的转义，我们还需要其他一些手段来防范XSS攻击。

1. Content Security Policy
本质也是白名单，通过设置白名单， 我们可以设置允许浏览器加载哪些外部资源。
在服务端使用 HTTP的 Content-Security-Policy 头部来指定策略，或者在前端设置 meta 标签。

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

1. 禁止加载外域代码，防止复杂的攻击逻辑。
2. 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
3. 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
4. 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
5. 合理使用上报可以及时发现 XSS，利于尽快修复问题。

CSP 文档地址：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

2. 输入内容长度控制

对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。

3. 输入内容限制

对于部分输入，可以限定不能包含特殊字符或者仅能输入数字等。

4. 其他安全措施

• HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
• 验证码：防止脚本冒充用户提交危险操作。

CSRF

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF的特点：

1. 攻击通常在第三方网站发起，如图上的站点B，站点A无法防止攻击发生。
2. 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；并不会去获取cookie信息(cookie有同源策略)
3. 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等(来源不明的链接，不要点击)

防御：

1. 添加验证码(体验不好)

验证码能够防御CSRF攻击，但是由于用户的体验会非常差，因此只在重要操作时增加验证码，确保账户安全。

2. 判断请求的来源：检测Referer(并不安全，Referer可以被更改)

Referer 可以作为一种辅助手段，来判断请求的来源是否是安全的，但是鉴于 Referer 本身是可以被修改的，因为不能仅依赖于 Referer

3. 使用Token(主流)

CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

• 服务端给用户生成一个token，加密后传递给用户
• 用户在提交请求时，需要携带这个token
• 服务端验证token是否正确

4. Samesite Cookie属性

为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。部署简单，并能有效防御CSRF攻击，但是存在兼容性问题。

Samesite=Strict
Samesite=Strict 被称为是严格模式,表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie，有能力阻止所有CSRF攻击。此时，我们在B站点下发起对A站点的任何请求，A站点的 Cookie 都不会包含在cookie请求头中。

Samesite=Lax
Samesite=Lax 被称为是宽松模式，与 Strict 相比，放宽了限制，允许发送安全 HTTP 方法带上 Cookie，如 Get / OPTIONS 、 HEAD 请求。但是不安全 HTTP 方法，如： POST ， PUT ， DELETE 请求时，不能作为第三方链接的 Cookie。

为了更好的防御CSRF攻击，可以组合使用以上防御手段。

点击劫持

frame busting

if ( top.location != window.location ){
    top.location = window.location
}

需要注意的是: HTML5 中 iframe 的 sandbox 属性、IE 中 iframe的 security 属性等，都可以限制 iframe 页面中的 JavaScript 脚本执行，从而可以使得 frame busting 失效。

X-Frame-Options

X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
可以设置为以下值:

• DENY: 拒绝任何域加载
• SAMEORIGIN: 允许同源域下加载
• ALLOW-FROM: 可以定义允许 frame 加载的页面地址

中间人攻击（Man-in-the-Middle Attack, MITM）

MITM 攻击就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探来达到攻击的目的，而通信的双方却毫不知情。

防御：

1. 网站使用HTTPS
2. 服务器执行HSTS协议：在HTTP Header中增加 Strict-Transport-Security 请求头

安全扫描工具

Mozilla HTTP Observatory
检查的主要范围包括：

• Cookie
• 跨源资源共享（CORS）
• 内容安全策略（CSP）
• HTTP公钥固定（Public Key Pinning）
• HTTP严格安全传输（HSTS）状态
• 是否存在HTTP到HTTPs的自动重定向
• 子资源完整性（Subresource Integrity）
• X-Frame-Options
• X-XSS-Protection

参考资料

• 前端安全系列之一：如何防止XSS攻击？
• 前端安全系列之二：如何防止CSRF攻击？
• 部署 HSTS 提升网站安全性
• 常见 Web 安全攻防总结
• 干货：熟悉面试中常见的的 web 安全问题
• 【面试篇】寒冬求职之你必须要懂的Web安全
• 常见六大Web安全攻防解析

[swiftwind0405]

https://mp.weixin.qq.com/s/g_l4JX_8by_rSfuyO3woLA

[swiftwind0405]

什么是CSRF攻击，如何防御
CSRF即Cross-site request forgery(跨站请求伪造)，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

假如黑客在自己的站点上放置了其他网站的外链，例如"www.weibo.com/api，默认情况下，浏览器会带着weibo.com的cookie访问这个网址，如果用户已登录过该网站且网站没有对CSRF攻击进行防御，那么服务器就会认为是用户本人在调用此接口并执行相关操作，致使账号被劫持。

如何防御CSRF攻击

验证Token：浏览器请求服务器时，服务器返回一个token，每个请求都需要同时带上token和cookie才会被认为是合法请求
验证Referer：通过验证请求头的Referer来验证来源站点，但请求头很容易伪造
设置SameSite：设置cookie的SameSite，可以让cookie不随跨域请求发出，但浏览器兼容不一

[swiftwind0405]

什么是XSS攻击，如何防御
XSS即Cross Site Scripting（跨站脚本），指的是通过利用网页开发时留下的漏洞，注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。常见的例如在评论区植入JS代码，用户进入评论页时代码被执行，造成页面被植入广告、账号信息被窃取

XSS攻击有哪些类型

存储型：即攻击被存储在服务端，常见的是在评论区插入攻击脚本，如果脚本被储存到服务端，那么所有看见对应评论的用户都会受到攻击。
反射型：攻击者将脚本混在URL里，服务端接收到URL将恶意代码当做参数取出并拼接在HTML里返回，浏览器解析此HTML后即执行恶意代码
DOM型：将攻击脚本写在URL中，诱导用户点击该URL，如果URL被解析，那么攻击脚本就会被运行。和前两者的差别主要在于DOM型攻击不经过服务端

如何防御XSS攻击

输入检查：对输入内容中的<script><iframe>等标签进行转义或者过滤
设置httpOnly：很多XSS攻击目标都是窃取用户cookie伪造身份认证，设置此属性可防止JS获取cookie
开启CSP，即开启白名单，可阻止白名单以外的资源加载和运行