共计 2758 个字符，预计需要花费 7 分钟才能阅读完成。
残缺高频题库仓库地址：https://github.com/hzfe/aweso…
残缺高频题库浏览地址：https://hzfe.github.io/awesom…
相干问题
- 如何防备 XSS / CSRF 攻打
- 说说 HTTPS 中间人攻打，及其如何防备
答复关键点
XSS CSRF 中间人攻打
- XSS（跨站脚本攻打） 是指攻击者利用网站破绽将代码注入到其余用户浏览器的攻击方式。常见类型有：
- 反射型（非持久性）
- 存储型（持久性）
- DOM 型
- CSRF（跨站申请伪造） 是指攻击者能够在用户不知情的状况下，窃用其身份在对应的网站进行操作。
- 中间人攻打（MITM） 是指攻击者与通信的两端别离创立独立的分割，在通信中充当一个中间人角色对数据进行监听、拦挡甚至篡改。
知识点深刻
1. XSS（跨站脚本攻打）
1.1 反射型（非持久性）
原理：攻击者通过在 URL 插入恶意代码，其余用户拜访该歹意链接时，服务端在 URL 取出恶意代码后拼接至 HTML 中返回给用户浏览器。
要点：
- 通过 URL 插入恶意代码。
- 有服务端参加。
- 须要用户拜访特定链接。
例子：
攻击者诱导被害者关上链接 hzfe.org?name=<script src="http://a.com/attack.js"/>。
被攻打网站服务器收到申请后，未经解决间接将 URL 的 name 字段间接拼接至前端模板中，并返回数据。
被害者在不知情的状况下，执行了攻击者注入的脚本（能够通过这个获取对方的 Cookie 等）。
1.2 存储型（持久性）
原理：攻击者将注入型脚本提交至被攻打网站数据库中，当其余用户浏览器申请数据时，注入脚本从服务器返回并执行。
要点：
- 恶意代码存储在指标网站服务器上。
- 有服务端参加。
- 只有用户拜访被注入歹意脚本的页面时，就会被攻打。
例子：
攻击者在指标网站留言板中提交了<script src="http://a.com/attack.js"/>。
指标网站服务端未经本义存储了恶意代码，前端申请到数据后间接通过 innerHTML 渲染到页面中。
其余用户在拜访该留言板时，会主动执行攻击者注入脚本。
1.3 DOM 型
原理：攻击者通过在 URL 插入恶意代码，客户端脚本取出 URL 中的恶意代码并执行。
要点：
- 在客户端产生。
例子：
攻击者诱导被害者关上链接 hzfe.org?name=<script src="http://a.com/attack.js"/>。
被攻打网站前端取出 URL 的 name 字段后未经本义间接通过 innerHTML 渲染到页面中。
被害者在不知情的状况下，执行了攻击者注入的脚本。
1.4 防备 XSS
- 对于内部传入的内容进行充沛本义。
- 开启 CSP（Content Security Policy，内容安全策略），规定客户端哪些内部资源能够加载和执行，升高 XSS 危险。
- 设置 Cookie httpOnly 属性，禁止 JavaScript 读取 Cookie 避免被窃取。
2. CSRF（跨站申请伪造）
原理：攻击者诱导受害者进入第三方网站，在第三方网站中向被攻打网站发送跨站申请。利用受害者在被攻打网站曾经获取的身份凭证，达到假冒用户对被攻打的网站执行某项操作的目标。
要点：
- 利用浏览器在发送 HTTP 申请时会主动带上 Cookie 的原理，冒用受害者身份申请。
- 攻打个别产生在第三方网站上。
- 攻击者只能“冒用”受害者的身份凭证，并不能获取。
- 跨站申请有多种形式，常见的有图片 URL，超链接，Form 提交等。
例子：
攻击者在第三方网站上搁置一个如下的 img
<img src="http://hzfe.org/article/delete" />
受害者拜访该页面后（前提：受害者在 hzfe.org 登录过且产生了 Cookie 信息），浏览器会主动发动这个申请，hzfe.org 就会收到蕴含受害者身份凭证的一次跨域申请。
若指标网站没有任何防范措施，那攻击者就能假冒受害者实现这一次申请操作。
防备：
- 应用 CSRF Token 验证用户身份
- 原理：服务端生成 CSRF Token（通常存储在 Session 中），用户提交申请时携带上 Token，服务端验证 Token 是否无效。
- 长处：能比拟无效的进攻 CSRF（前提是没有 XSS 破绽泄露 Token）。
- 毛病：大型网站中 Session 存储会减少服务器压力，且若应用分布式集群还须要一个公共存储空间存储 Token，否则可能用户申请到不同服务器上导致用户凭证生效；有肯定的工作量。
- 双重 Cookie 验证
- 原理：利用攻击者不能获取到 Cookie 的特点，在 URL 参数或者自定义申请头上带上 Cookie 数据，服务器再验证该数据是否与 Cookie 统一。
- 长处：无需应用 Session，不会给服务器压力。
- 设置白名单，仅容许平安域名申请
- 减少验证码验证
3. 中间人攻打（MITM）
原理：中间人攻打是一种通过各种技术手段入侵两台设施通信的网络攻击办法。
图片起源 Man in the middle (MITM) attack
胜利的中间人攻打次要有两个不同的阶段：拦挡 和解密。
3.1 拦挡
即攻击者须要用户数据在达到指标设施前拦挡并通过攻击者的网络。分为被动攻打和主动攻击。
常见的被动攻打（也是最简略）的办法，攻击者向公众提供收费的歹意 WiFi 热点，一旦有受害者连贯了该热点，攻击者就能齐全理解其所有的在线数据交换。
常见的主动攻击有两种：
- ARP 坑骗： 攻击者利用 ARP 的破绽，通过假冒网关或其余主机，使得达到网关或其余主机的流量通过攻击者主机进行转发。
- DNS 坑骗： 攻击者假冒域名服务器，将受害者查问的 IP 地址转发到攻击者的 IP 地址。
3.2 解密
拦挡后，若连贯是应用 HTTPS 协定即传递的数据用了 SSL / TLS 加密，这时还须要其余伎俩去解密用户数据。
SSL 劫持（伪造证书）
攻击者在 TLS 握手期间拦挡到服务器返回的公钥后，将服务器的公钥替换成本人的公钥并返回给客户端，这样攻击者就能用本人的私钥去解密用户数据，也能够用服务器公钥解密服务器数据。
因为是伪造的证书，所以客户端在校验证书过程中会提醒证书谬误，若用户仍抉择持续操作，此时中间人便能获取与服务端的通信数据。
SSL 剥离
攻击者拦挡到用户到服务器的申请后，攻击者持续和服务器放弃 HTTPS 连贯，并与用户降级为不平安的 HTTP 连贯。
服务器能够通过开启 HSTS（HTTP Strict Transport Security）策略，告知浏览器必须应用 HTTPS 连贯。然而有个毛病是用户首次拜访时因还未收到 HSTS 响应头而不受爱护。
3.3 中间人攻打防备
对于开发者来说：
- 反对 HTTPS。
- 开启 HSTS 策略。
对于用户来说：
- 尽可能应用 HTTPS 链接。
- 防止连贯不出名的 WiFi 热点。
- 不疏忽不平安的浏览器告诉。
- 公共网络不进行波及敏感信息的交互。
- 用可信的第三方 CA 厂商，不下载来源不明的证书。
参考资料
- Cross-site scripting
- Man in the middle (MITM) attack