浏览器工作原理与实践（七）——页面安全

同源策略可以隔离各个站点之间的 DOM 交互、页面数据和网络通信，但也约束了web。所以我们默认页面中可以引用任意第三方资源，然后又引入 CSP 策略来加以限制；默认 XMLHttpRequest 和 Fetch 不能跨站请求资源，然后又通过 CORS 策略来支持其跨域。不过也带来了安全问题，如XSS攻击。

XSS Cookie的HttpOnly

XSS跨站脚本，黑客往HTML文件或DOM中注入恶意脚本，从而在用户浏览页面时利用注入脚本对用户实施攻击。
最开始是通过跨域实现的，所以叫跨域脚本。
当页面被注入了恶意 JavaScript 脚本时，浏览器无法区分这些脚本是被恶意注入的还是正常的页面内容，所以恶意注入 JavaScript 脚本也拥有所有的脚本权限

1. 窃取cookie信息，通过document.cookie获取Cookie信息，然后通过XMLHttpRequest或Fetch加上CORS发送给恶意服务器，恶意服务器拿到cookie可以模拟登录转账
2. 监听用户行为，用addEventListener监听键盘事件，获取信用卡信息、发送到恶意服务器、作违法的事
3. 修改DOM伪造假的登录窗口，欺骗用户输入用户名和密码
4. 页面生成浮窗广告，影响用户体验

XSS分为存储型XSS攻击、反射型XSS攻击和基于DOM的XSS攻击3种方式注入恶意脚本。

• 存储型XSS攻击：黑客利用站点漏洞(输入名称成恶意代码)将恶意代码放到有漏洞的服务器，用户访问了有恶意代码的页面，恶意脚本会上传用户Cookie信息到恶意服务器
• 反射型XSS攻击：恶意脚本成了用户发送请求的一部分(get地址上)，然后网站又把恶意代码返回给用户，页面执行时做恶意操作。Web 服务器不会存储反射型 XSS 攻击的恶意脚本，这是和存储型 XSS 攻击不同的地方。
• 基于DOM的XSS攻击：不牵扯服务器。通过wifi路由器，本地恶意软件劫持在web资源传输过程中或使用页面中修改页面

首先都是先往浏览器注入恶意脚本，然后再通过恶意脚本将用户信息发送到恶意服务器。
解决：

1. 服务器对输入脚本进行过滤或转码
2. 充分利用CSP，限制加载其它域资源、禁止向第三方提交数据、禁止执行内联和未授权脚本、提供上报机制，可以尽快发现攻击进行修复
3. 使用httpOnly属性，无法通过document.cookie读出来
4. 增加验证码
5. 限制输入长度

CSRF 点链接

CSRF跨站请求伪造，利用用户的登录状态通过第三方站点做一些坏事。在黑客站点中

1. 自动发起get接口，比如黑客请求接口在img src中，当加载图片时，会自动去发起img请求，如恶意代码是转账，就会被转走。
2. 自动发起post，隐藏表单并且内容是转账，打开站点会自动加载JS进行提交表单，服务器进行转账。
3. 引诱用户点链接，点图片地址是转账接口

CSRF不需要将恶意代码注入页面，仅是利用服务器的漏洞和用户的登录状态实施攻击。
条件：

1. 目标站点一定要有漏洞
2. 用户登录过目标站点，并在浏览器上保持有站点的登录状态
3. 需要用户打开一个三方站点(黑客or论坛)，关键是找到服务器漏洞

解决：

1. 利用cookie的SameSite属性，cookie是浏览器和服务器之间维护登录状态的关键数据。
   通常CSRF攻击都是从第三方站点发起的，最好能实现从第三方站点发送请求时禁止cookie的发送。因此在浏览器通过不同源发送http请求时，有如下区别：
   (1).第三方发起的请求，需要浏览器禁止发送某些关键cookie数据到服务器
   (2).同一站点发起的请求，需要保证cookie数据正常发送
   通过Set-Cookie的SameSite属性值：
   Strict最严，完全禁止第三方cookie。
   Lax：链接打开get会带cookie，post,img,iframe,加载的url不会带。
   none：都会带。
2. 验证请求的来源点,在服务器端验证请求来源的站点，服务器可以禁止第三方站点请求。
   从请求头中Referer和Origin判断第三方。
   Referer会包含路径来源地址信息。
   会优先判断Origin包含域名信息
3. CSRF token：
   1.浏览器发送请求时，服务器生成CSRF Token植入返回的页面中。2.浏览器发起转账时要带上页面的CSRF Token。

页面安全问题主要原因是浏览器为同源策略开的2个后门：一是页面可以任意引用第三方源。二通过CORS跨域请求。
基于这些，又引入了CSP限制页面任意引入外部资源、引入HttpOnly来禁止请求发送一些关键cookie、引入SameSite和Origin，来防止CSRF攻击。