【HTTP完全注解】掘金就这样被我攻击了——Web常见攻击与防护手段-灵析社区

Web常见攻击与防护

前段时间深入的学习了下HTTP的CSP策略，就想着找几个网站练练手，看看哪个倒霉蛋要中招。说巧不巧打开掘金一看，嘻嘻正是我想要的，于是乎就诞生了一个有意思的攻击示例：攻击掘金示例（大家放心访问不造成任何安全风险）。

相信大家看源码之后恍然大悟，并且不屑一顾，我想掘金肯定也是怎么想的，但勿以风险小而不防呀！多少安全事故都是一些细枝末节的风险引起的，但导致了巨大损失！因此我觉得很有必要跟大家一起学习下现在较为常见的攻击以及一些相关的防护手段，以便于减少网站的安全风险，防范于未来！

我们如何得知近期常见的安全风险？

我们都知道攻击方式往往是随着时间而不断进化和变更的，我们如何得知近期最有威胁的攻击方式呢？答案就是OWASP每几年发布的《OWASP Top Ten》。OWASP是一个由Open Web Application Security Project（OWASP）组织的关于Web应用安全的开放社区。该社区每几年都会发布一个十大Web应用安全风险，以反映新的威胁和漏洞，帮助开发人员、安全专家和组织识别和解决这些风险。想要保持Web应用的安全性，我们应该定期查阅了解这些常见的安全风险。

常见的攻击以及防护手段

MitM

MitM(Man-in-the-Middle Attack，中间人攻击，简称MitM攻击）是一种常见的网络攻击方式，攻击者通过在通信过程中插入自己作为中间人的角色，窃取或篡改通信内容。MITM攻击的基本原理是攻击者在通信的两端之间插入自己的存在，使得双方都认为他们在与对方直接通信，但实际上所有的通信都经过了攻击者的窃听和干扰。

防范手段：

· 将所有HTTP升级为HTTPS，如果无法升级HTTPS请自行妥善加密请求内容

· 设置HTTP响应标头Strict-Transport-Security字段，要求浏览器在与特定网站通信时强制使用HTTPS连接，并向Google提供的HSTS预加载列表站点提交你的域名，以申请加入HSTS预加载列表中

XSS

XSS（Cross-Site Scripting，跨站脚本攻击，简称XSS）攻击是一种利用网页应用程序的安全漏洞的攻击方式，攻击者通过在网页中注入恶意脚本代码，使其在用户的浏览器中执行。这些恶意脚本可以用来窃取用户的敏感信息、篡改网页内容或进行其他未经授权的操作。

防范手段：

用户输入数据以及动态渲染用户输入数据时要严格验证、过滤以及转义

确保用户提交的数据符合预期的格式和类型，拒绝不合法的输入，在将用户输入插入到HTML、JavaScript、CSS或其他上下文中之前，要对数据进行严格验证、过滤以及转义，防止浏览器将输入识别为可执行脚本。

切勿滥用任何动态渲染、插入、执行js、css以及html的方法，慎用任何序列以及反序列化的方法

在使用上述方法时一定要仔细思考是否一定要使用这些方法才能满足需求，如若不是最好不要使用，非要使用一定要仔细验证数据来源是否已经经过严格的验证、过滤以及转义。

选择受信任的源（如官方仓库或社区维护的库）的依赖，定期审查项目依赖的安全风险

避免使用来自不明来源、未经验证或不活跃维护的依赖项，因为这些依赖项可能包含安全漏洞，项目依赖需要定期监控和更新，因为漏洞和安全问题可能随着时间而出现。

使用内容安全策略（CSP）

使用CSP指定浏览器应该如何处理页面中的内容和资源，告诉浏览器哪些来源是受信任的，哪些操作是允许的，以此增强Web应用程序的安全性，减少或防止跨站脚本攻击（XSS）和其他类型的注入攻击。

各类注入攻击

各类注入攻击(如SQL、NoSQL、OS等注入攻击)，其本质与XSS攻击相同，也是一种利用网页应用程序的安全漏洞的攻击方式，它通过在网页中注入恶意脚本代码，只不过这些恶意代码不在浏览器运行，而是在服务器中运行。它的防范手段与XSS相同，但CSP并不能防范这类攻击。

防范手段：

用户输入数据以及动态渲染用户输入数据时要严格验证、过滤以及转义

切勿滥用任何动态渲染、插入、执行js、css以及html的方法，慎用任何序列以及反序列化的方法

选择受信任的源（如官方仓库或社区维护的库）的依赖，定期审查项目依赖的安全风险

点击劫持

点击劫持（Clickjacking）是一种Web应用程序安全漏洞，旨在欺骗用户，使其在不知情的情况下执行某些意外的操作，通常是通过将透明的或隐藏的页面元素覆盖在诱导用户单击的元素上来实现的。点击劫持的攻击者可以操纵用户的行为，例如单击恶意链接、提交表单或进行其他操作，而用户认为他们正在与合法的网站或应用程序进行交互。

防范手段：

设置CSP中的frame-ancestors属性

通过设置frame-ancestors属性定义哪些网页可以使用 iframe、frame、object、embed 等元素嵌套显示当前页面，以此来防止恶意网站嵌套页面发起恶意攻击。

不使用Cookie认证身份或保持会话

Cookie的存储方式不同于Web Storage 和 IndexedDB的存储方式是以源进行分割的，因此如果你的网站使用了Cookie认证身份以及保持会话，那么当恶意网站嵌入您的网站时会与你的网站共享Cookie，这也意味这如果你登陆了你的网站，那么访问恶意网站时，它嵌入的网站也是登录状态。而点击劫持攻击最重的是嵌入的网站能够保持登录状态，因此使用Cookie认证身份或保持会话会有造成该攻击的安全风险，为了减轻这些风险你可以使用Authorization认证身份或保持会话。

CSRF

CSRF（Cross-Site Request Forgery，跨站请求伪造，简称CSRF）是一种利用Web应用程序中的信任关系的攻击方式，攻击者通过某些方式(例如社交媒体、广告等)诱骗受害者访问恶意网站，恶意网站利用受骗者已登录的身份信息隐式发送敏感操作的请求，由于该受骗者已登录该网站因此该请求则会自动携带该用户的身份信息，由于身份信息正确服务器也会执行相应的敏感操作，这样用户在访问浏览恶意网站时并不需要任何操作，神不知鬼不觉的情况下就被攻击了，执行了恶意操作。

防范手段：

使用CSRF令牌: 在每个敏感操作的请求中包含一个随机生成的CSRF令牌，该令牌只有在请求发起页面和接收页面具有相同的令牌时，请求才会被接受。这可以确保只有合法的请求才能成功。
检查Referer头: 服务器可以检查HTTP请求头中的Referer字段，以确保请求来自期望的来源。然而，这种方法并不总是可靠，因为Referer字段可能被篡改或缺失。
使用合理的请求方式： 由于获取资源等不被同源策略限制的请求通常是Get方法，因此我们应当合理定义敏感操作的请求方法(如：Post等)，即可规避利用该方法发起的CSRF攻击
慎用JSONP等跨源访问手段，改用CORS： JSONP（JSON with Padding）是一种跨源访问手段，它允许在浏览器中加载来自不同域的数据，它在早期的网络应用中很常见。攻击者可以利用这种机制来发起CSRF攻击，通过向目标网站发送JSONP请求，以触发未经授权的操作。CORS 是一种用于解决跨源网络访问问题的标准化机制。服务器可以通过设置HTTP响应头来明确指定哪些域名的网页可以访问其资源。这样，只有被授权的域名才能够进行跨源访问。
使用Cookie认证身份或保持会话需要设置其SameSite等相关安全属性，最好还是使用Authorization认证手段： 确保使用Cookie进行身份认证和会话管理时，设置Cookie的SameSite属性，以限制跨站点请求。
同源策略的合理利用： 尽量在应用中合理利用同源策略，将敏感操作限制在同一域内进行，从而降低跨域请求的风险。

会话劫持

会话劫持（Session Hijacking）是一种较为常见的Web攻击，攻击者通过尝试获取或窃取合法用户的会话标识，然后使用这些标识来模拟合法用户，绕过身份验证并获得对用户帐户的访问权限来发起攻击。这种攻击通常发生在会话标识以Cookie或URL参数的形式存储在客户端的网站，由于URL参数以及Cookie如果未设置相关的安全属性是很容易暴露的，因此攻击者可以使用不同的技术和手段来实施会话劫持。并且该攻击通常需要于其他攻击配合使用，例如：MitM、XSS、点击劫持等。

防范手段：

· 防护MitM的手段

· 防护XSS的手段

· 防护点击劫持的手段

· 使用Cookie认证身份或保持会话需要设置其SameSite等相关安全属性，最好还是使用Authorization认证手段： 确保使用Cookie进行身份认证和会话管理时，设置Cookie的SameSite属性，以限制跨站点请求。

· 定期更改会话标识： 会话标识的定期更改可以减少会话劫持的风险。

如何知道自己的网站是否安全

目前我主要使用的工具是Mozilla Observatory，Mozilla Observatory是一个由Mozilla维护的在线Web安全检测工具，它能够检测出我们的网站是否使用安全的加密传输、评估HTTP头部的配置，包括CSP、X-Content-Type-Options、X-Frame-Options等、检查敏感数据的存储和传输方式以及跨站脚本（XSS）、SQL注入、XXE等常见漏洞。根据检测的结果，它还会给出相应的改善建议，然后我们就可以通过这些建议调整服务器配置、修复代码漏洞、更新依赖项。

Mozilla Observatory虽然是一个有用的工具，可以帮助我们快速评估和改善Web应用程序的安全性。但请注意，Mozilla Observatory只是一个工具，它并不能解决所有安全问题。因此我们并不是说使用了它就能杜绝一切安全问题，维护Web应用程序的安全性需要综合性的措施和定期审查。