HTTP和Web应用

最新推荐文章于 2024-07-13 10:25:57 发布

༺小白熊 ༻

最新推荐文章于 2024-07-13 10:25:57 发布

阅读量1k

点赞数 27

分类专栏：网络协议相关知识文章标签： http 前端网络协议知识图谱学习方法网络安全

本文链接：https://blog.csdn.net/qq_62987084/article/details/140077339

版权

网络协议相关知识专栏收录该内容

2 篇文章 0 订阅

订阅专栏

HTTP协议
HTTP的全称是Hypertext transfer protocol，他是构建web应用的基础，虽然开发web应用大部分时候都不用关心http协议细节，但是如果未能正确的使用该协议，可能会带来安全隐患。HTTP协议设计的内容非常多，下面将简单介绍HTTP协议中和安全有关的知识。
HTTP协议简介
HTTP协议是一种Client-Server协议，所以只能由客户端单向发起请求，服务端再响应请求。这里的客户端也叫用户代理（User Agent)，在大多数情景下是一个浏览器
HTTP请求
http通信由请求和响应组成，一个HTTP请求的数据包如下所示。（抓包演示）
http请求方法
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 章详细介绍)。
(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方法时，可用于建立从外网穿透到内网的传输隧道。
URI的全称是Uniform Resource Identifier,客户用其标识该HTTP请求要作用到服务器上的资源路径，URI再加上HOST头才是一个完整的互联网路径，即HOST+URI。但是当浏览器使用了正向代理时，这个URI就是完整的目标URL。
现代浏览器发出的HTTP 请求，其 HTTP 版本号主要是 1.1和2，更低的HTTP版本多见于API调用，因为部分应用的底层 HTTP 库还未升级。更高版本的 HTTP/3虽然已经正式发布但目前支持它的网站不多。
HTTP/1.1比HTTP/1.0 多了一些新特性。HTTP/1.1支持持久连接 (Keep-Alive)，即允许复用一个TCP 连接完成多个HTTP 请求。HTTP/1.1还支持管线化 (Pipelining)，即在一个TCP连接中客户端无须等待前一个请求的响应，就可以发送下一个请求，服务端只需要按照请求的顺序逐一响应即可。这个特性提升了 Web 应用的网络性能，但是在 HTTP Flood攻击中，攻击者利用这个特性能大幅提升攻击效率一一只需要建立少数的 TCP 连接，无须等待服务器响应就能在短时间内连续发送大量HTTP请求。
host头
HTTP/1.1 在请求中新增了 HOST 头用于虚拟主机的场景，即当一个IP 地址上运行了多个网站时，Web 服务器通过 HOST 头中的域名即可判断要访问的目标网站是哪一个。在一些虚拟主机配置错误的服务器上，如果一个 Web 应用使用任意 HOST 头都能正常访问，而且 Web 应用中又没有明确配置网站的域名，而是获取 HOST 头作为网站域名时，那么该应用就可能获取一个错误的域名。当攻击者通过恶意构造的 HOST 头访问时，如果应用内部需要获取网站域名用于关键业务逻辑，比如向该域名的网站发送敏感信息，就会将敏感信息发送给恶意域名。如果HOST 头的域名会出现在缓存页面中(比如 Web 应用中使用了编译型模板，并且其中的某些URL 是通过这个 HOST 头拼接生成的)，攻击者使用恶意构造的 HOST 头访问这个网站，可能导致其他用户访问受污染的页面。
user-agent头
HTTP 请求中的 User-Agent 头用来指示当前访问者的客户端类型，它的值是客户端指定的,黑客工具通常会伪装成一个正常浏览器的 User-Agent，所以在 Web 应用中不能基于User-Agent的值来做关键业务逻辑决策。甚至 User-Agent 头中也可能包含恶意内容，例如攻击者可能向其中插入XSS Payload，以便对后端的日志分析平台实现XSS 盲打。
referer头
Referer 头指示了当前请求是从哪个URL页面发起的,在旧版本的Flash 中这个值可以伪造但是在现代浏览器中不能通过 JavaScript 伪造这个头，所以有些安全防御方案会用这个头校验请求来源。在 JavaScript 中可以通过 window.history 对象的 pushState 和 replaceState 方法修改兰前窗口的历史记录,但是仅能够将其修改为与当前URL同源。所以依赖 Referer 中的域名做来源校验还是可靠的，但只能信任其域名，而不能信任 URL 级别的内容。
此外，当网页跳转到其他站点，或者加载其他站点资源时，会将当前 URL 作为 Referer传递给其他站点，所以URL 中一般不要包含敏感信息，以免信息泄露。
浏览器发送的 HTTP头的格式都是很标准的，而攻击者编写的自动化攻击程序通常是手工构造的 HTTP 头，与标准的 HTTP 头在某些方面可能会有细微差异，如空格、标点符号、头的个数等。通过这些细微差异，我们可识别出异常的访问者并进行处置。另外，使用不同浏览器访问同一个页面时，HTTP 头的个数和顺序也会有差异，甚至同一个浏览器在访问不同类型的资源时，或者在不同的场景中发出的请求，也会有差异。这些细微的差异被安全产品用于鉴别访问者是不是真实用户。例如请求中的 User-Agent 宣称自己是 Firefox 浏览器而实际的HTTP头不符合 Firefox 浏览器的特征，那么访问者可能篡改了 User-Agent，或者它其实是个自动化程序。
HTTP响应
HTTP 响应是与请求一一对应的，服务端将请求的操作结果通过 HTTP 响应返回给客户端。
响应中的版本号不一定要与请求中的版本号一样，但是其大版本号(Major Version)不能高于请求中的大版本号，例如请求是 HTTP/1.0 版本的，服务端响应不能为 HTTP/2 版本，但可以为HTTP/1.1版本。
状态码
状态码用于指示服务器对于该请求的操作结果。在标准定义中，状态码按照区段分为 5大类
状态码的不规范使用是非常普遍的现象。在有些网站中，不管是正常响应、页面未找到，还是服务端出错，全部都响应 200 状态码，还有很多API被设计为全部响应 200状态码，然后通过响应正文JSON 中的某个字段，来标识请求是成功还是出错。这些设计相当于把 HTTP协议当作传输层协议来使用，而把 HTTP 协议本身包含的很强的语义信息全部丢掉了。从非安全的角度看，不规范地使用状态码对 SEO 非常不利，搜索引擎并不能理解“页面未找到”等字眼而会将状态码为 200 的页面全部收录进来。
从安全的角度看，在利用访问日志做安全分析时，状态码非常有价值，例如一个访问者在短时间内产生大量的 404 响应，很可能是有攻击者在做网站扫描探测;某个页面有大量的 500 响应，可能意味着程序存在 Bug，甚至是代码存在 SQL注入漏洞，正在被黑客攻击。通过统计和分析 HTTP 响应的状态码，对这类情况就能实现简单的安全监测。
HTTP 的响应头是通过“\r\n”分割的，如果请求中的数据会出现在响应头中，当这些数据未经服务端严格过滤时，可能产生 HTTP 消息头注入(有些文章里也叫 CRLF 注入)，即攻击者可以使用“\r\n”注入任意的 HTTP 头。
如果在受害者的响应中注入了 Location 头，可将受害者重定向到指定网站；注入 Set-Cookie 头，可以让受害者使用攻击者指定的 Cookie 值，如实施定会话攻击；在跨域资源共享(CORS)和内容安全策略(CSP)中注入特定的响应头，可以改变浏览器接收到的安全策略，以便攻击者实施其他的攻击行为。所以，如果用户输入的数据会出现在响应头中，需要对其进行严格的校验，或在输出时对回车和换行符进行编码。
Web服务器
Web 服务器通过HTTP/HTTPS 协议向访问者提供服务，它可以是一台服务器或者一个服务器集群。
Web 服务器提供的内容按照其存在的形式可以分为两类:静态资源和动态资源。静态资源是指服务器上已经存在的文件，当客户端访问时，Web 服务器直接将它返回给客户端，比如图片和视频文件，通常这类资源可以缓存。动态资源是指服务端需要经过计算才能生成的内容，比如查询结果，不同的用户或不同的时间获得的结果都不一样，这类资源一般不缓存。
我们平常访问 Web应用并不都是直接访问 Web 服务器的，中间可能经过了HTTP代理，其中可能有客户端指定的正向 HTTP 代理，也有网站使用的CDN、WAF、负载均衡等反向 HTTP代理，在使用不当时可能会带来安全隐患。
apache+php+mysql 配套组合
iis+.asp+sqlserver 配套组合
tomcat+java 配套组合
正向代理：
一位企业老总，他有一位助理小李，当老总想要订火车票时，就会委托小李帮忙订票，当老总想要订酒店时，小李就会负责查找合适的酒店并安排老总入住。助理小李帮老总办了很多事情，也就是代理了一些事情，而助理小李就充当了一个代理服务器的角色。
反向代理：
雷池waf