从一次攻击看前端安全问题

Posted 2021-09-03 前端一锅煮

微信公众号：[前端一锅煮]
一点技术、一点思考。
问题或建议，请公众号留言。

最近网站遭遇了一次 CSRF 攻击，短信调用接口被第三方调用导致发出大量无效短信，后来经过接口签名和 IP 封禁解决。今天就来详细学习下前端领域的安全问题。

Web 应用中存在很多安全风险，这些风险会被攻击者利用，轻则篡改网页内容，重则窃取网站内部数据，更为严重的则是在网页中植入恶意代码，使得用户受到侵害。常见的安全漏洞如下：

• XSS 攻击：对 Web 页面注入脚本，使用 javascript 窃取用户信息，诱导用户操作。
• CSRF 攻击：伪造用户请求向网站发起恶意请求。
• 钓鱼攻击：利用网站的跳转链接或者图片制造钓鱼陷阱。
• HTTP 参数污染：利用对参数格式验证的不完善，对服务器进行参数注入攻击。
• 远程代码执行：用户通过浏览器提交执行命令，由于服务器端没有针对执行函数做过滤，导致在没有指定绝对路径的情况下就执行命令。

XSS

XSS（cross-site scripting 跨域脚本攻击）攻击是最常见的 Web 攻击，其重点是『跨域』和『客户端执行』。

XSS 攻击一般分为两类：Reflected XSS（反射型的 XSS 攻击）和 Stored XSS（存储型的 XSS 攻击）。

Reflected XSS

反射型的 XSS 攻击，主要是由于服务端接收到客户端的不安全输入，在客户端触发执行从而发起 Web 攻击。比如：在某购物网站搜索物品，搜索结果会显示搜索的关键词。搜索关键词填入<script>alert(\'handsome boy\')</script>，点击搜索。页面没有对关键词进行过滤，这段代码就会直接在页面上执行，弹出 alert。此攻击需要用户触发执行。

防御措施：不要信任用户的任何输入，对用户输入全部做过滤处理。转义 <>、过滤掉双引号，单引号，阻止靠元素属性来触发事件执行脚本。

Stored XSS

基于存储的 XSS 攻击，是通过提交带有恶意脚本的内容存储在服务器上，当其他人看到这些内容时发起 Web 攻击。一般提交的内容都是通过一些富文本编辑器编辑的，很容易插入危险代码。存在于网页的数据库内，不需要用户触发。

防御措施：不信任用户的输入，可对属性、域名做过滤，后端不可信任前端输入，需要再次过滤。

JSONP XSS

JSONP 的 callback 参数非常危险，他有两种风险可能导致 XSS。

1. callback 参数意外截断 js 代码，特殊字符单引号双引号，换行符均存在风险。
2. callback 参数恶意添加标签（如 <script> ），造成 XSS 漏洞。

防御措施：限制 callback 函数名词最长 50 个字符，callback 函数名只允许 [, ]，a-zA-Z0123456789_, $，.，防止一般的 XSS，utf-7 XSS等攻击。

CSRF

CSRF（Cross-site request forgery 跨站请求伪造，也被称为 One Click Attack 或者 Session Riding，通常缩写为 CSRF 或者 XSRF，是一种对网站的恶意利用。CSRF 攻击会对网站发起恶意伪造的请求，严重影响网站的安全。

防御措施：

1. 前后端接口做签名并设置过期时间，防止第三方调用。
2. 后端验证请求的 referer 来源。
3. 把恶意请求 IP 加入黑名单。
4. 限制请求频率，超过正常频率，明显接口恶意调用的，锁死 IP。

钓鱼攻击

钓鱼有多种方式，这里介绍 url 钓鱼、图片钓鱼和 iframe 钓鱼。

url 钓鱼

服务端未对传入的跳转 url 变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；也可能引发的 XSS 漏洞（主要是跳转常常使用 302 跳转，即设置 HTTP 响应头，Locatioin: url，如果 url 包含了 CRLF，则可能隔断了 HTTP 响应头，使得后面部分落到了 HTTP body，从而导致 XSS 漏洞）。

防御措施：在跳转的时候对 url 进行按规则校验，判断 url 是否在应用授权的白名单内。

图片钓鱼

如果可以允许用户向网页里插入未经验证的外链图片，这有可能出现钓鱼风险。

比如常见的 401 钓鱼，攻击者在访问页面时，页面弹出验证页面让用户输入帐号及密码，当用户输入之后，帐号及密码就存储到了黑客的服务器中。通常这种情况会出现在 <img src=xxx/>中，系统不对 src 是否在域名白名单内进行校验。

防御措施：在 html 标签中要解析 url 的地方进行白名单校验。

iframe 钓鱼

iframe 钓鱼，通过内嵌 iframe 到被攻击的网页中，攻击者可以引导用户去点击 iframe 指向的危险网站，甚至遮盖，影响网站的正常功能，劫持用户的点击操作。

防御措施：加上以下代码限制网站被嵌套。

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

HPP 攻击

Http Parameter Pollution（HPP)，即 HTTP 参数污染攻击。在 HTTP 协议中是允许同样名称的参数出现多次，而由于应用的实现不规范，攻击者通过传播参数的时候传输 key 相同而 value 不同的参数，从而达到绕过某些防护的后果。可能导致的安全威胁有：绕过防护和参数校验；产生逻辑漏洞和报错，影响应用代码执行。

防御措施：在客户端传输 key 相同而 value 不同的参数时，服务端强制使用第一个参数，因此不会导致 hpp 攻击。

中间人攻击

在网络环节的数据传输过程中，内容请求和获取时会经过许多中间人，包括充当内容入口的浏览器、路由器厂商、WIFI提供商、通信运营商等。如果使用了代理、翻墙软件则会引入更多中间人。由于 HTTP 请求的路径、参数默认情况下均是明文的，因此这些中间人可以对 HTTP 请求进行监控、劫持、阻挡。

在没有 HTTPS 时，运营商可在用户发起请求时直接跳转到某个广告，或者直接改变搜索结果插入自家的广告。如果劫持代码出现了 BUG ，则直接让用户无法使用，出现白屏。

数据泄露、请求劫持、内容篡改等等问题，核心原因就在于 HTTP 是全裸式的明文请求，域名、路径和参数都被中间人们看得一清二楚。HTTPS 做的就是给请求加密，让其对用户更加安全。对于自身而言除了保障用户利益外，还可避免本属于自己的流量被挟持，以保护自身利益。

尽管 HTTPS 并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击。不过HTTPS是现行架构下最安全的解决方案，并且它大幅增加了中间人攻击的成本。

防御措施：把网站升级到 HTTPS。

防御总结

XSS 攻击：前端过滤用户输入，后端过滤前端传的数据。

CSRF 攻击：前后端接口做签名并设置过期时间，referer 检验，封 IP，锁 IP。

钓鱼攻击：对第三方跳转链接进行白名单校验，限制网站被嵌套。

HPP 攻击：服务端强制使用第一个参数。

中间人攻击：网站升级为 HTTPS。

SSL 安全检测

服务端 SSL 支持检测：https://www.ssllabs.com/sslte...

本地 SSLv3 支持检测：https://www.ssllabs.com/sslte...