简单的 HTTP 协议本身并不存在安全性问题,因此协议本身几乎不会成为攻击的对象。应用 HTTP 协议的服务器和客户端,已经运行在服务器上的 Web 应用等资源才是攻击目标。

在客户端即可篡改请求

在 Web 应用中,从浏览器那接收到的 HTTP 请求的全部内容,都可以在客户端自由地变更、篡改。所以 Web 应用可能会接收到与预期数据不相同的内容。

在 HTTP 请求报文内加载攻击代码,就能立发起对 Web 应用的攻击,通过 URL 查询字段或表单、HTTP 首部、Cookie 等途径吧攻击代码传入,若这时 Web 应用存在安全漏洞,那内部信息就会遭到窃取,或被攻击者拿到管理权限。

针对 Web 应用的攻击模式

对 Web 应用的攻击模式有以下两种:

• 
  
• 主动攻击;
  
• 被动攻击;
  

以服务器为目标的主动攻击

主动攻击是指攻击者通过直接访问 Web 应用,把攻击代码传入的模式,由于该模式是直接针对服务器上的资源进行攻击,因此攻击者能够访问到那些资源。

主动攻击模式里面具有代表性的攻击是 SQL 注入攻击和 OS 命令注入攻击。

以服务器为目标的被动攻击

被动攻击是指利用圈套策略执行攻击代码的攻击模式,在被动攻击过程中,攻击者不直接对目标 Web 应用访问发起攻击。

被动攻击通常的攻击模式如下所示:

1. 
   
2. 攻击者诱使用户触发已设置好的陷阱,而陷阱会启动发送已嵌入攻击代码的 HTTP 请求;
   
3. 当用户不知不觉中招之后,用户的浏览器或邮件客户端会触发这个陷阱;
   
4. 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发送给作为攻击目标的 Web 应用,运行攻击代码;
   
5. 执行完攻击代码，存在安全漏洞的 Web 应用会成为攻击者的跳板,可能导致用户所持的 Cookie 等个人信息被窃取,登录状态中的用户权限遭恶意滥用等后果。
   

被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。

利用被动攻击,可发起对原本从互联网上无法直接访问的企业内网等网络的攻击。只要用户踏入攻击者预先设好的陷阱,在用户能够访问到的网络范围内,即使是企业内网也同样会受到攻击。

因输出值转移不完全引发的安全漏洞

实施 Web 应用的安全对策可大致分为以下两部分:

• 
  
• 客户端的验证;
  
• Web 应用端的验证:
  
  • 
    
  • 输入值验证;
    
  • 输出值转义;
    
  
  
  

因为 JavaScript 代码可以在客户端随便修改或者删除,所以不适合将 JavaScript 验证作为安全的方法策略。保留客户端验证只是为了尽早地辨识输入错误,起到提高 UI 体验的作用。

输入值验证通常是指检查是否是符合系统业务逻辑的数值或检查字符编码等预防对策。

从数据库或文件系统、HTML、邮件等输出 Web 应用处理的数据之际,针对输出做值转义处理是一项至关重要的安全策略。当输出值转义不完全时,会因触发攻击者传入的攻击代码,而给输出对象带来损害。

跨站脚本攻击

跨站脚本攻击(Cross-Site Scripting,XSS)是指通过存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的 HTML 标签或 JavaScript 进行的一种攻击。动态创建的 HTML 部分有可能隐藏这安全漏洞。就这样,攻击者编写脚本设下陷阱,用户在自己的浏览器上运行时,一不小心就会受到被动攻击。

跨站脚本攻击有可能造成一下影响:

• 
  
• 利用虚假输入表单骗取用户个人信息;
  
• 利用脚本窃取用户的 Cookie 值,被害者在不知情的情况下,帮助攻击者发送恶意请求;
  
• 显示伪造的文章或图片;
  

跨站脚本攻击案例

在动态生成 HTML 处发生

下面以编辑个人信息页面为例讲解跨站脚本攻击,下放界面显示了用户输入的个人信息内容:

确认姐妹按原样显示在编辑解密输入的字符串。此处输入带有山口伊朗这样的 HTML 标签的字符串。

那如果我把输入的内容换成一段 JavaScript 代码呢,阁下又该如何应对?

<script>
alert("落霞与孤鹜齐飞,秋水共长天一色!");
</script>

XSS 是攻击者利用预先设置的陷阱触发的被动攻击

跨站脚本攻击属于被动攻击模式,因此攻击者会事先布置好用于攻击的陷阱。

下图网站通过地址栏中 URI 的查询字段指定 ID,即相当于在表单内自动填写字符串的功能。而就在这个地方,隐藏着可执行跨站脚本攻击的漏洞。

充分熟知此处漏洞特点的攻击者,于是就创建了下面这段嵌入恶意代码的 URL。并隐藏植入事先准备好的欺诈邮件中或 Web 页面内,诱使用户去点击该 URL。

浏览器打开该 URI 后,直观感觉没有发生任何变化,但设置好的脚本却偷偷开始运行了。当用户在表单内输入 ID 和密码之后,就会直接发送到攻击者的网站,导致个人登录信息被窃取。

之后,ID 及密码会传给该正规网站,而接下来仍然是按正常登录步骤,用户很难意识到自己的登录信息已遭泄露。

除了在表单中设下圈套之外,下面那种恶意构造的脚本统一能够通过跨站脚本攻击的方式,窃取到用户的
Cookie 信息:

const cookie = document.cookie;

执行上面这段 JavaScript 程序,即可访问到该 Web 应用所处域名下的 Cookie 信息,然后这些信息会发送至攻击者的 Web 网站,记录在它的登录日志中,攻击者就这样窃取到用户的 cookie 信息了。

React 中通过 JSX 语法转义来防止 XSS。在 JSX 语法中,可以通过花括号 {} 插入 JavaScript 表达式。JSX 语法会自动转义被插入到 HTML 标签之间的内容。这意味着任何用户输入的内容都会被转义,以防止恶意脚本的执行。在转义过程中,React 会将特殊字符进行转换,例如将小于号 < 转义为 <、大于号 > 转义为 >、引号 " 转义为 " 等。这样可以确保在渲染时,用户输入的内容被当作纯文本处理,而不会被解析为 HTML 标签或 JavaScript 代码。

SQL 注入攻击

会执行非法 SQL 的 SQL 注入攻击

SQL 注入是指针对 Web 应用使用的数据库,通过运行非法的 SQL 而产生的攻击。该安全隐患有可能引发极大的威胁,有时会直接导致个人信息及机密信息的泄露。

SQL 注入攻击有可能会造成以下等影响:

• 
  
• 非法查看或篡改数据库内的数据;
  
• 规避认证;
  
• 执行和数据库服务器业务关联的程序等;
  

SQL 注入攻击案例

• 
  
• 登录绕过攻击: 攻击者可以在登录表单的用户名和密码字段中插入恶意的 SQL 代码。如果应用程序未对输入进行正确的验证和过滤,攻击者可以通过在用户名字段中输入 ' OR '1'='1 的恶意输入来绕过登录验证,使得 SQL 语句变为：SELECT \* FROM users WHERE username = '' OR '1'='1' AND password = '<输入的密码>'，从而成功登录到系统中;
  
• 删除或修改数据攻击: 攻击者可以通过注入恶意的 SQL 代码来删除或修改数据库中的数据。例如,攻击者可以在一个表单的输入字段中插入 '; DROP TABLE users;-- 的恶意输入。如果应用程序未正确处理这个输入,攻击者可以成功删除用户表(假设表名为 "users")导致数据丢失;
  

OS 命令注入攻击

OS 命令注入攻击是指通过 Web 应用,执行非法的操作系统命令达到攻击的目的。只要在能调用 Shell 函数的地方就有存在被攻击的风险。

可以从 Web 应用中通过 Shell 来调用操作系统命令,如果调用 Shell 是存在疏漏,就可以执行插入的非法 OS 命令。

OS 命令注入攻击可以向 Shell 发送命令,让 Windows 或 Linux 操作系统的命令行启动程序。也就是说,通过 OS 注入攻击可执行 OS 上安装着的各种程序。

OS 注入攻击案例

• 
  
• 文件操作攻击: 攻击者可以在应用程序的输入字段中插入恶意的操作系统命令来执行文件操作。例如,如果应用程序在文件上传过程中未对输入进行适当的验证和过滤,攻击者可以在文件名字段中插入 '; rm -rf / ;-- 的恶意输入。如果应用程序在执行文件操作时没有正确处理这个输入,攻击者可能会删除服务器上的所有文件;
  
• 远程命令执行攻击: 攻击者可以通过注入恶意的操作系统命令来执行远程系统命令。例如,如果应用程序在一个输入字段中插入 ; ping <恶意 IP 地址> ; 的恶意输入,而没有进行正确的输入验证和过滤,攻击者可以利用该注入漏洞执行远程命令,对目标系统进行攻击或探测;
  

HTTP 首部注入攻击

HTTP 首部注入攻击是指攻击者通过在响应首部字段内插入换行,添加任意响应首部或主体的一种攻击。属于被动攻击模式。

HTTP 首部注入攻击有可能造成以下一些影响:

• 
  
• 设置任何 Cookie 信息;
  
• 重定向值任意 URL;
  
• 显示任意的主体;
  

HTTP 首部注入攻击案例

以下是一些 HTTP 首部注入攻击的案例,展示了攻击者是如何利用该漏洞进行攻击的:

• 
  
• 重定向攻击: 攻击者可以在 HTTP 响应的 Location 首部中插入恶意 URL,从而将用户重定向到恶意网站或欺骗性的页面。如果应用程序未正确验证和过滤用户输入,并将其直接用作 Location 首部的值,攻击者可以在 URL 中插入换行符和其他特殊字符,添加额外的首部字段,导致用户被重定向到意外的位置;
  
• 缓存投毒攻击: 攻击者可以在 HTTP 响应的 Cache-Control 或其他缓存相关首部中插入恶意指令,以欺骗缓存服务器或浏览器,导致缓存数据的污染或泄漏。攻击者可以通过注入换行符等特殊字符来添加额外的首部字段或修改缓存指令,绕过缓存机制或引发信息泄露;
  
• HTTP 劫持攻击: 攻击者可以在 HTTP 响应的 Location 或 Refresh 首部中插入恶意 URL,将用户重定向到恶意网站或欺骗性页面,从而劫持用户的会话或执行其他攻击。通过在响应中插入恶意的 Location 或 Refresh 值,攻击者可以修改用户的浏览器行为;
  
• XSS 攻击: 攻击者可以在 HTTP 响应的 Set-Cookie 或其他首部字段中插入恶意脚本,以执行跨站脚本攻击。如果应用程序未正确过滤和转义用户输入,并将其插入到首部字段中,攻击者可以通过注入恶意代码来窃取用户的会话标识符或执行其他恶意操作;
  

因会话管理疏忽引发的安全漏洞

会话管理是用来管理用户状态的必备功能,但是如果在会话管理上有所疏忽,就会导致用户的认证状态被窃取等后果。

会话劫持

会话劫持是指攻击者通过某种手段拿到了用户的会话 ID,并非法使用此会话 ID 伪装成用户,达到攻击的目的:

具备人中功能的 Web 应用,使用会话 ID 的会话管理机制,作为管理认证状态的主流方式。会话 ID 中记录客户端的 Cookie 等信息,服务端将会话 ID 与认证状态进行一对一匹配管理。

下面列举了几种攻击者可获得会话 ID 的途径:

• 
  
• 通过非正规的生成方法推测会话 ID;
  
• 通过窃听或 XSS 攻击盗取会话 ID;
  
• 通过会话固定攻击强行获取会话 ID;
  

会话劫持攻击案例

下面我们以认证功能为例讲解会话劫持。这里的认证功能通过会话管理机制，会将成功认证的用户的会话 ID,保存在用户浏览器的 Cookie 中。

攻击者在得知该 Web 网站存在可跨站攻击的安全漏洞后,就设置好用 JavaScript 调用 document.cookie 以窃取 cookie 信息的陷阱,一旦用户踏入陷阱访问了该脚本,攻击者就能获取含有会话的 ID 的 Cookie。

攻击者拿到用户的会话 ID 后,往自己的浏览器的 Cookie 中设置该会话 ID,即可伪装成会话 ID 遭窃的用户,访问 Web 网站了。

会话固定攻击

对一切去目标会话 ID 为主动攻击手段的会话劫持而言,会话固定攻击 攻击会强制用户使用指定的会话 ID,属于被动攻击。

会话固定攻击案例

下面我们以认证功能为例讲解会话固定攻击,这个 Web 网站的认证功能,会在认证前发布一个会话 ID,若认证成功,就会在服务器内改变认证状态。

攻击者准备陷阱,先访问 Web 网站拿到会话 ID,此刻,会话 ID 在服务器上的记录仪仍是未认证状态。

攻击者设计好强制用户使用该会话 ID 的陷阱,并等待用户拿着这个会话 ID 前去认证,一旦用户触发陷阱并完成认证,会话 ID 服务器上的状态(用户 A 已认证) 就会被记录下来。

攻击者估计用户差不多已触发陷阱后,再利用之前这个会话 ID 访问网站,由于该会话 ID 目前已是用户 A 已认证状态,于是攻击者作为用户 A 的身份顺利登陆网站。

会话固定攻击预防措施

会话固定攻击利用了应用程序在身份验证和会话管理过程中未正确处理会话标识符的漏洞。为了防止会话固定攻击,开发人员可以采取以下措施:

1. 
   
2. 生成随机、唯一的会话标识符,并在用户每次登录或创建新会话时重新生成;
   
3. 不接受用户提供的会话标识符,而是通过服务器生成并返回给客户端;
   
4. 在身份验证之前和之后,对会话标识符进行适当的验证和验证机制;
   
5. 设置会话管理策略,包括会话超时时间和注销会话的方式;
   

通过采取这些预防措施,可以减少会话固定攻击的风险,并提高应用程序的安全性。

跨站点请求伪造

跨站点伪造请求(Cross-Site Require Forgeries,CSRF)攻击是指攻击者通过设置好的陷阱,强制用户对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新,属于被动攻击。

跨站点请求伪造有可能会造成一下等影响:

• 
  
• 利用已通过认证的用户权限更新设定信息等;
  
• 利用已通过认证的用户权限购买商品;
  
• 利用已通过认证的用户权限在评论区发表言论;
  

跨站点伪造请求的攻击案例

下面以一个网站的登录访问功能为例,讲解跨站点请求伪造,如下图所示:

1. 
   
2. 当用户输入账号信息请求登录 A 网站;
   
3. A 网站验证用户信息,通过验证后返回给用户一个 cookie;
   
4. 在未退出网站 A 之前,在同一浏览器中请求了黑客构造的恶意网站 B;
   
5. B 网站收到用户请求后返回攻击性代码,构造访问 A 网站的语句;
   
6. 浏览器收到攻击性代码后,在用户不知情的情况下携带 cookie 信息请求了 A 网站。此时 A 网站不知道这是由 B 发起的。那么这时黑客就可以为所欲为了!!!
   

这首先必须瞒住两个条件:

• 
  
• 用户访问站点 A 并产生了 Cookie;
  
• 用户没有退出 A 网站同时访问了 B 网站;
  

CSRF 攻击的防御

当涉及到跨站伪造请求的防御时,一下是一些防御方法和实践:

1. 
   
2. 
   

   验证来源和引用检查:

   
   
   • 
     
   • 服务器端应该验证每个请求的来源 Referer 字段和源 Origin 字段以确保请求来自预期的域名或网站。如果来源不匹配,服务器应该拒绝请求。Referer 头部并不是 100% 可靠,因为某些浏览器或网络代理可能会禁用或篡改该字段。因此,Origin 字段被认为是更可靠的验证来源的方式;
     
   
   
   
3. 
   

   CSRF Token:

   
   

   
   

   CSRF 令牌是一个随机生成的值,嵌入到表单或请求参数中,与用户会话相关联。它的目的是验证请求的合法性,确保请求是由预期的用户发起的,而不是由攻击者伪造的。

   
   

   
   
   • 
     
   • 在每个表单和敏感操作的请求中,包括一个 CSRF 令牌;
     
   • 令牌可以作为隐藏字段 input type="hidden" 或请求头,例如 X-CSRF-Token 的一部分发送;
     
   • 在服务器端,验证请求中的令牌是否与用户会话中的令牌匹配,以确保请求的合法性;
     
   
   
   
4. 
   

   验证请求的方法: 某些敏感操作应该使用 POST、PUT 或 DELETE 等非幂等方法,而不是 GET 请求。这样可以防止攻击者通过构造图片或链接等 GET 请求来触发敏感操作;

   
   
   
5. 
   

   敏感操作的二次确认: 对于一些敏感操作,例如修改密码、删除账户等,可以在用户执行操作前要求二次确认,以确保用户的意图和授权;

   
   
   

综合采取上述防御措施,可以有效减少跨站伪造请求攻击的风险。然而,没有单一的解决方案可以完全消除跨站伪造请求的威胁,因此建议在开发过程中将安全性作为一个关键考虑因素,并进行全面的安全测试和审查。

参考文献

书籍: 图解HTTP

总结

没有总结,总结个屁,不上网就是