课程体系与VMware Workstation Pro的安装

最新推荐文章于 2024-05-04 02:37:00 发布

钮糊涂甄嬛

最新推荐文章于 2024-05-04 02:37:00 发布

阅读量793

点赞数 18

文章标签：网络安全网络攻击模型

本文链接：https://blog.csdn.net/weixin_62638332/article/details/135487787

版权

本文详细介绍了HTTP协议中的基本方法，强调了GET、POST、HEAD等在Web应用中的正确使用，以及它们在安全性方面的考量。讨论了安全三要素（机密性、完整性和可用性），并提醒开发者在处理敏感数据时要遵循相应的原则，以防止安全漏洞。

摘要由CSDN通过智能技术生成

(本文章仅支持本人学习使用，若造成不良影响，与本人无关！）

安全三要素

安全三要素是安全的基本组成元素，分别是机密性 (Confidentiality)、完整性 (Integrity) 和可用性 (Availability)，简称为 CIA 。

HTTP协议

HTTP协议是一种Client-Server协议，所以只能由客户端单向发起请求，服务端再响应请求。这里的客户端也叫用户代理（User Agent)，在大多数情景下是一个浏览器

HTTP请求

http通信由请求和响应组成，一个HTTP请求的数据包如下所示。（抓包演示）

HTTP请求方法

http方法用于指定请求的操作系统，标准的方法如下所示

方法	用途
OPTIONS	用于客户端向服务端询问是否支持特定的选项
GET	向服务端获取URI指定的资源
HEAD	和GET方法类似，但是服务端不返回实际内容
POST	向服务端提交数据
PUT	向指定的URL存储文件
DELETE	删除URI指定的服务器上的文件
TRACE	让服务器回显请求中的内容
CONNECT	用户在HTTP协议中建立代理隧道

Web应用中的绝大部分请求使用的是GET和POST方法，通过XMLHttpRequest 可以发送HEAD、PUT、DELETE 方法的请求。在部分场景下，浏览器会发送OPTIONS 请求，用于预检。CONNECT 请求一般用于HTTP 隧道代理场景。

虽然 Web 应用中的一项功能，使用不同的HTTP方法都能实现，但出于安全考虑，我们要遵循如下基本原则:

(1)GET和HEAD方法应当只用于对服务端没有副作用的操作，即对服务端是“只读”的操作，它们被称为安全的方法。如果该操作对服务端会有副作用，比如增加、删除、更改数据,则应该使用别的 HTTP 方法。考虑到安全性，对于 GET 请求，浏览器在刷新页面时不会要求用户确认，而对于有副作用的 POST 请求，在刷新页面时浏览器会询问用户是否要重新发送，避免在服务端产生多余的操作，比如重复交易、重复下单等。

在这里插入图片描述

HEAD方法与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用HEAD, 可以： • 在不获取资源的情况下了解资源的情况（比如，判断其类型） • 通过查看响应中的状态码，看看某个对象是否存在， • 通过查看首部，测试资源是否被修改了。服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范，就必须实现HEAD方法。

(2)PUT和 DELETE 方法一般用于直接上传和删除文件，大部分 Web 应用不会用到，如果这两种方法被攻击者利用，危害会非常大。因此如无业务需求，应当禁用这些方法。与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建Web页面，并用PUT直接将其安装到Web服务器上去。

(3)在 Web 应用中，尽量通过 POST 方法提交敏感数据，而不是通过GET 方法提交。POST方法起初是用来向服务器输入数据的。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（比如，送到一个服务器网关程序中，然后由这个程序对其进行处理）。

在这里插入图片描述

(4)在服务端获取请求参数时，应当明确指明是从GET参数还是 POST参数中获取，否则攻击者可将原本设计为用POST方法提交的操作改用GET方法提交，以绕过某些只针对POST请求设计的安全策略(如全局 CSRF 防御方案，我们将在第7 章详细介绍)。例如，在 PHP中尽量不要从$REQUEST中获取请求参数，而是明确指定从$ GET 或者$_POST中获取。

(5)TRACE 方法通常用于诊断调试，服务端直接返回请求中的内容，在 XSS 攻击中可用它绕过 Cookie的HttpOnly 策略,通过 JavaScript代码读取带有 HttpOnly 属性的 Cookie内容生产环境的服务器应当禁用TRACE方法。

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP 请求。TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。TRACE请求会在目的服务器端发起一个“环回” 诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求响应链上，原始报文如何被毁坏或修改过。

在这里插入图片描述

TRACE方法主要用于诊断，也就是说，用于验证请求是否如愿穿过了请求——响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生效果。

尽管TRACE可以很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各种不同类型请求（不同的方法–GET、HEAD、POST等）的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情一比如，代理可能会将POST请求直接发送给服务器，而将GET请求发送给另一个HITP应用程序（比如Web缓存）。TRACE并不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。

(6)HEAD方法和GET 方法所消耗的服务端计算资源是一样的，只是服务端对 HEAD请求的响应不会包含正文，所以网络出方向的带宽消耗不一样。在 DDoS 攻击中，攻击者可能使用HEAD方法发起攻击，让服务器的网络出方向带宽不超过告警阙值，对服务器实施应用层的DDoS攻击，耗尽服务器的计算资源。

(7)CONNECT方法用于在客户端和目标地址之间建立一个 TCP 隧道，这个时候 Web 服务器充当代理服务器，只有初始请求用的是 HTTP 协议，后续的所有双向流量都是在 TCP 连接上传输的。所以当 Web 服务器支持 CONNECT方法时，可用于建立从外网穿透到内网的传输隧道。

host头、user-agent头、referer头

状态码

状态码用于指示服务器对于该请求的操作结果。在标准定义中，状态码按照区段分为 5大类

状态码	说明
100-199	表示已收到请求，但未完成操作，用于通知客户端
200-299	请求中的操作已成功完成
300-399	告知客户端执行额外的操作，通常用于跳转
400-499	客户端请求有错误
500-599	服务端出错

Web 服务器

Web 服务器通过HTTP/HTTPS 协议向访问者提供服务，它可以是一台服务器或者一个服务器集群，我们平常访问 Web应用并不都是直接访问 Web 服务器的，中间可能经过了HTTP代理，其中可能有客户端指定的正向 HTTP 代理，也有网站使用的CDN、WAF、负载均衡等反向 HTTP代理，在使用不当时可能会带来安全隐患。