社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

背 景

随着互联网的迅猛发展，HTTP（HyperText Transfer Protocol，超文本传输协议）已经成为网页传输的基础协议。它在客户端（如浏览器）和服务器之间传递信息，使得我们能够浏览网页、提交表单、下载文件等。然而，HTTP 的普及也使其成为黑客攻击的主要目标之一。HTTP 协议本身是无状态的，这种特性虽然简化了网络通信，但也带来了不少安全隐患。

网络安全攻击利用了 HTTP 协议的各种漏洞和特性，试图在数据传输过程中获取未授权的信息、操纵数据、扰乱服务甚至窃取敏感信息。这些攻击不仅对用户隐私构成威胁，还可能导致严重的经济损失和声誉损害。因此，了解和防范 HTTP 网络安全攻击显得尤为重要。

02

HTTP协议介绍

2.1 HTTP协议概念

HTTP（HyperText Transfer Protocol，超文本传输协议）[1]是万维网（World Wide Web）的核心协议之一。HTTP协议初期运行在TCP/IP协议之上，后期运行在QUIC协议之上，是应用层协议。它定义了客户端（如浏览器）和服务器之间如何传输文本、图像、视频及其他多媒体内容。同时，也是一种客户端-服务端（client-server）协议，也就是说，请求是由接收方—通常是浏览器发起的，客户端与服务端之间通过交换一个个独立的消息（而非数据流）进行通信。由客户端——通常是个浏览器——发出的消息被称作请求（request），由服务端发出的应答消息被称作响应（response）。

图1

2.2 HTTP协议报文格式

HTTP 报文是面向文本的，报文中的每个字段都是一些ASCII码串，各个字段的长度是不确定的。HTTP 有两类报文：请求报文和响应报文。

图2 HTTP请求报文

HTTP 请求报文由以下内容组成：

◆ 请求行

   · 请求方法

   · 请求URL

   · HTTP协议版本

◆ 请求头部：请求头部包含了多个头字段，每个字段包含一个名称和一个值，用于传递客户端的额外信息和指示。每个头字段占一行。

◆ 空行：空行用于分隔请求头部和请求主体。它仅包含回车符和换行符（CRLF），即 rn。

◆ 请求主体：请求主体包含了实际发送的数据，仅在某些方法（如 POST、PUT）中存在。它可以是任意二进制数据或文本数据，格式没有固定要求。

图3 HTTP响应报文

HTTP响应报文由以下内容组成：

◆ 状态行

   · HTTP协议版本

   · 状态码

   · 状态短语

◆ 响应头部：响应头部包含了多个头字段，每个字段包含一个名称和一个值，用于传递服务器的额外信息和指示。每个头字段占一行。

◆ 空行：空行用于分隔响应头部和响应主体。它仅包含回车符和换行符（CRLF），即 rn。

2.3 HTTP协议发展

HTTP/1.0（于1996年发布）最初是由Tim Berners-Lee[2]在1989年提出，是“无状态”的：每个客户端的新请求都建立了一个新连接，而不是通过特定客户端和服务器之间的相同连接处理所有类似的请求。

HTTP/1.1（于1997年发布）包括持久连接、客户端浏览器对HTML文件的解压缩，以及多个域名共享相同的IP地址。

HTTP/2（于2015年发布）旨在解决网页加载缓慢的问题，并且是一种二进制协议，其中使用二进制值而不是像以前版本中那样使用纯文本。

HTTP/3 （于2020年发布）依赖于更快的QUIC协议而不是TCP，受大多数浏览器支持。

2.4 HTTP协议性质

（1）无状态

HTTP是一个基于请求-响应模型的无状态协议。无状态意味着每个请求都是独立的，服务器不会保留之前请求的状态信息。这种设计虽然简化了协议，但也需要引入额外的机制来维护状态，如cookies、sessions等。

（2）无连接

HTTP 是一种无连接协议。每次请求和响应都通过独立的连接完成，服务器处理完请求后即关闭连接。这种特性简化了服务器设计，但也带来了连接频繁创建和关闭的开销。

（3）灵活性

HTTP 可以传输任意类型的数据，只要两端能处理数据的内容类型。通过MIME类型（Content-Type）进行标识和处理。例如，文本数据可以是 HTML、JSON、XML 等，二进制数据可以是图像、视频、应用程序数据等。

（4）可扩展性

HTTP 协议支持通过添加新的方法、头字段来扩展功能。例如，HTTP/1.1 引入了许多新的头字段和方法，HTTP/2 和 HTTP/3 引入了更多优化和功能改进。

03

常见攻击方式

3.1 SQL Injection（SQL 注入）

原理：SQL注入[3]是一种将恶意代码插入到程序SQL语句中，从而误导数据库执行恶意逻辑的攻击技术。通过SQL注入，攻击者可以达到获取敏感信息，窃取访问权限等目的。

比如后端有SQL如下，需要前端传入一个id值，以进行信息查询:

SELECT * FROM `MyTable` WHERE `id`="{0}"

而此时，如果前端传入“1” OR TRUE。后端没有校验便传入参数值并对SQL进行拼接。那么直接拼接的SQL为：

SELECT * FROM `MyTable` WHERE `id`="1" OR TRUE

此时将所有数据全部取出。如果后端SQL是DELETE，影响更是不可估量。

防范：SQL 注入得以实施的因素是：网页应用使用 SQL 来控制数据库，用户传入的数据直接被写入数据库。因此，防御 SQL 注入的关键在于：永远不要相信用户的输入；

在此理念的指导下，对于用户提交的输入信息，我们需要进行充分的校验，避免其对后端服务系统造成攻击。相关手段可以是正则式检验参数合法性、html元素校验、SQL元素校验，对用户输入的内容进行转义（escape）处理，不让特殊符号破坏SQL语句的原本结构等，并且可以在前端/后端执行。

如果校验逻辑在前端执行，确实不会对后端性能造成影响，但对于有经验的攻击者，可以修改前端代码，此屏障就形同虚设；而如果在后端进行校验，多少会损耗后端性能，如果校验算法比较复杂耗时，也许又会成为攻击者的另一个攻击点。

根据 OWASP，下面看看具体的预防措施：

◆ Prepared Statements(with Parameterized Queries)： 参数化的查询语句可以强制应用开发者首先定义所有的sql代码，之后再将每个参数传递给查询语句。

◆ Stored Procedures：使用语言自带的存储程序，而不是自己直接操纵数据库。

◆ White List Input Validation：验证用户的输入。

3.2 Distributed Denial of Service（DDoS，分布式拒绝服务）

原理：HTTP DDoS攻击[4]是一种特定类型的DDoS攻击，旨在通过大量HTTP请求淹没目标Web服务器，使其无法正常处理合法用户的请求。总体而言，DDoS 攻击好比高速公路发生交通堵塞，妨碍常规车辆抵达预定目的地。

大致分为以下几类：

◆ HTTP Flood攻击：攻击者通过发送大量合法的HTTP GET或POST请求来耗尽目标服务器的资源，如CPU、内存和带宽。GET请求通常用于获取资源（如网页、图片等），而POST请求则用于提交数据（如表单数据）。

◆ Slowloris攻击：这种类型的攻击更多是面向连接层面，以基于线程的Web服务器为目标，通过慢速请求来捆绑每个服务器线程，从而消耗服务器的线程&连接资源。攻击者与服务器建立大量连接，每个连接只发送部分请求头，并在接近超时之前继续发送更多的头部数据，从而保持连接活跃。

◆ Large Payload POST requests攻击：一般通过POST方法发送容量大、结构复杂的请求体到目标服务器，使得目标服务器在解析这些请求内容的过程发生过载(CPU或内存)；攻击者通过构造特定的序列化请求体，如xml、json等，在服务端执行反序列化操作时引起服务过载。

◆ HTTP请求随机化攻击：攻击者使用各种随机化技术，改变User-Agent头、Referer头、URL参数等，使请求难以被简单地识别和过滤，使每个HTTP请求看起来都是唯一的，从而绕过基于签名的防御机制。

DDoS攻击一般会根据攻击目标的情况，针对性的把技术手法混合，以达到最低的成本最难防御的目的，并且可以进行合理的节奏控制，以及隐藏保护攻击资源。

防范：

◆ Web应用防火墙（WAF）：过滤和阻止恶意HTTP请求。

◆ CDN（内容分发网络）：使用CDN将流量分散到多个节点，提高整体抗攻击能力。

◆ 流量清洗服务：使用专门的DDoS防护服务来识别和清洗恶意流量。

3.3 Cross Site Script（XSS， 跨站脚本攻击)

原理：XSS是一种安全漏洞。攻击者可以利用这种漏洞在网站上注入恶意的客户端代码。当受害者运行这些恶意代码时，攻击者就可以突破网站的访问限制并冒充受害者。根据开放式Web应用安全项目（OWASP）的数据，XSS是 2017年第七名[5]最常见的Web应用程序漏洞。

如果 Web 应用程序没有部署足够的安全验证，那么，这些攻击很容易成功。浏览器无法探测到这些恶意脚本是不可信的，所以，这些脚本可以任意读取cookie、session token，或者其他敏感的网站信息，或者让恶意脚本重写HTML内容。

大致分为以下几类：

◆ 存储XSS：注入的脚本永久的存在于目标服务器上，每当受害者向服务器请求此数据时就会重新唤醒攻击脚本。

◆ 反射型XSS：当用受害者被引诱点击一个恶意链接，提交一个伪造的表单，恶意代码便会和正常返回数据一起作为响应发送到受害者的浏览器，从而骗过了浏览器，使之误以为恶意脚本来自于可信的服务器，以至于让恶意脚本得以执行。

◆ DOM型XSS：有点类似于存储型XSS，但存储型XSS是将恶意脚本作为数据存储在服务器中，每个调用数据的用户都会受到攻击。但DOM型XSS则是一个本地的行为，更多是本地更新DOM时导致了恶意脚本执行。

防范：

◆ 输入验证：从客户端和服务器端双重验证所有的输入数据，这一般能阻挡大部分注入的脚本。

3.4 Cross Site Request Forgery(CSRF，跨站请求伪造)

原理：CSRF攻击[6]是一种利用用户在已登录网站上的身份来伪造用户请求的攻击方式，造成用户数据的损失或网络安全的风险。也是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

CSRF 攻击一般是攻击者通过某些手段，伪造用户请求，让用户在不知情的情况下，达到攻击者预期的目的，主要涉及以下步骤：

a. 攻击者获取用户已登录的Cookie信息。

b. 攻击者构造一些恶意代码，将这些代码注入到受害者的浏览器中。

c. 受害者在未经过任何提示的情况下，被恶意代码引导访问攻击者的网站，其中URL中包含了攻击者构造的恶意参数。

d. 受害者浏览器访问攻击网站时，将自动向受害者之前已登录过的网站发送请求（上面存在的请求）。

e. 被恶意代码引导，受害者访问攻击者的网站，正在被他人攻击造成的后果并不为受害者所知，而浏览器会自动发送包含受害者的Cookie信息的请求，造成CSRF攻击。

当攻击者伪造了用户的请求后，服务器端将无法准确判断这个请求的合法性，导致用户数据被篡改、删除、操作等，产生极大的安全风险。因此，在设计Web应用程序时，需要充分考虑CSRF防御策略以保护用户的信息安全。

防范：那怎么预防CSRF攻击呢？OWASP推荐了两种检查方式来作为防御手段。

◆ 检查标准头部，确认请求是否同源：检查source origin和target origin，然后比较两个值是否匹配。

◆ 检查 CSRF Token：主要有四种推荐的方式

   · Synchronizer Tokens：在表单里隐藏一个随机变化的token，每当用户提交表单时，将这个token提交到后台进行验证，如果验证通过则可以继续执行操作。

   · Double Cookie Defense：当向服务器发出请求时，生成一个随机值，将这个随机值既放在cookie中，也放在请求的参数中，服务器同时验证这两个值是否匹配。

   · Encrypted Token Pattern：对token进行加密。

   · Custom Header：使用自定义请求头部，这个方式依赖于同源策略。其中最适合的自定义头部便是："X-Requested-With: XMLHttpRequest"。

参考文献：