发现很多同学想学安全,上手就是一堆工具直接堆,成了就成了没成就拉到,个人感觉安全不仅仅是表面上的干进去了到索然无味!其中终端操作系统、网络架构、协议、代码编程、数据库、应用服务、容器、等等等各种常见项目都要去了解,今天想了想出个最基础的web安全最应该懂得连载吧!
HTTP是一个协议,其允许资源,诸如HTML文档的抓取。它是 Web上任何数据交换的基础,并且是客户端-服务器协议,这意味着请求是由收件人(通常是Web浏览器)发起的。从获取的不同子文档中重构出完整的文档,例如文本,布局描述,图像,视频,脚本等。
客户端和服务器通过交换单个消息(而不是数据流)进行通信。客户端(通常是Web浏览器)发送的消息称为请求,而服务器作为答案发送的消息称为响应。
HTTP是在1990年代初期设计的,是随时间发展的可扩展协议。它是通过TCP或TLS加密的TCP连接发送的应用程序层协议,尽管理论上可以使用任何可靠的传输协议。由于其可扩展性,它不仅可用于获取超文本文档,而且还可用于获取图像和视频,或将内容发布到服务器(如HTML表单结果)。HTTP还可以用于获取部分文档以按需更新Web页面。
HTTP是一种客户端服务器协议:请求由一个实体,用户代理(或代表它的代理)发送。大多数情况下,用户代理是Web浏览器,但也可以是任何东西,例如,可以爬网以填充并维护搜索引擎索引的机器人。
每个单独的请求都发送到服务器,由该服务器处理并提供答案(称为响应)。在客户端和服务器之间有许多实体(统称为代理),它们执行不同的操作并充当网关或缓存。
实际上,浏览器和服务器之间有更多处理请求的计算机:路由器,调制解调器等。由于Web的分层设计,这些隐藏在网络和传输层中。HTTP在应用程序层之上。尽管对于诊断网络问题很重要,但是底层几乎与HTTP的描述无关。
所述用户代理是作用于用户的代表任何工具。该角色主要由Web浏览器执行。其他可能性是工程师和Web开发人员用来调试其应用程序的程序。
浏览器始终是发起请求的实体。它绝不是服务器(尽管多年来已经添加了一些机制来模拟服务器启动的消息)。
要显示网页,浏览器会发送原始请求以获取代表该页面的HTML文档。然后,它解析该文件,并发出与执行脚本,要显示的布局信息(CSS)以及页面中包含的子资源(通常为图像和视频)相对应的其他请求。然后,Web浏览器将这些资源混合在一起,以向用户提供完整的文档,即Web页面。浏览器执行的脚本可以在以后的阶段中获取更多资源,并且浏览器会相应地更新Web页面。
网页是超文本文档。这意味着显示的文本的某些部分是可以激活(通常通过单击鼠标)以获取新网页的链接,从而允许用户定向其用户代理并浏览Web。浏览器将这些指示转换为HTTP请求,并进一步解释HTTP响应以向用户提供清晰的响应。
在通信通道的另一侧是服务器,该服务器根据客户端的请求提供文档。一台服务器实际上实际上只是一台机器:这是因为它实际上可能是服务器的集合,共享负载(负载平衡)或询问其他计算机(例如缓存,数据库服务器或电子商务)的复杂软件服务器),按需全部或部分生成文档。
服务器不一定是一台计算机,但是可以在同一台计算机上托管多个服务器软件实例。使用HTTP / 1.1和Host
标头,它们甚至可以共享相同的IP地址。
在Web浏览器和服务器之间,许多计算机和机器中继HTTP消息。由于Web堆栈的分层结构,其中大多数都在传输,网络或物理级别上运行,在HTTP层上变得透明,并可能对性能产生重大影响。在应用程序层上运行的那些通常称为代理。这些请求可以是透明的,可以转发接收到的请求而不以任何方式更改请求,也可以是不透明的,在这种情况下,它们将以某种方式更改请求,然后再将其传递给服务器。代理可以执行许多功能:
HTTP通常被设计为简单易读,即使HTTP / 2通过将HTTP消息封装到帧中而增加了复杂性。人工可以读取和理解HTTP消息,从而为开发人员提供了更轻松的测试,并为新手提供了降低的复杂性。
HTTP标头是HTTP / 1.0中引入的,使此协议易于扩展和试验。甚至可以通过客户端与服务器之间关于新标头语义的简单协议来引入新功能。
HTTP是无状态的:在同一连接上连续执行的两个请求之间没有链接。对于试图例如使用电子商务购物篮连贯地与某些页面进行交互的用户而言,这立即具有问题。但是,尽管HTTP本身的核心是无状态的,但HTTP cookie允许使用有状态会话。使用标头可扩展性,HTTP Cookie被添加到工作流中,从而允许在每个HTTP请求上创建会话以共享相同的上下文或相同的状态。
连接是在传输层进行控制的,因此基本上不在HTTP的范围之内。尽管HTTP不需要底层的传输协议是基于连接的;仅要求其可靠,否则不会丢失消息(因此至少会出现错误)。在Internet上两种最常见的传输协议中,TCP是可靠的,而UDP不是。因此,HTTP依赖于基于连接的TCP标准,即使并非总是需要连接也是如此。
在客户端和服务器可以交换HTTP请求/响应对之前,它们必须建立TCP连接,此过程需要多次往返。HTTP / 1.0的默认行为是为每个HTTP请求/响应对打开一个单独的TCP连接。当多个请求连续发送时,这比共享单个TCP连接的效率低。
为了缓解此缺陷,HTTP / 1.1引入了流水线(事实证明难以实现)和持久连接:可以使用Connection
标头部分控制基础TCP连接。HTTP / 2通过在单个连接上多路复用消息来进一步推进,从而使连接保持温暖和更高效。
正在进行实验,以设计更适合HTTP的更好的传输协议。例如,谷歌正在试验基于UDP的QUIC,以提供更可靠和有效的传输协议。
随着时间的流逝,HTTP的这种可扩展性质允许对Web进行更多控制和功能。缓存或身份验证方法是HTTP历史记录中早期处理的功能。相比之下,放宽原点约束的功能仅在2010年代才添加。
这是可通过HTTP控制的常见功能列表。
WWW-Authenticate
和相似的标头提供基本身份验证,也可以使用HTTP cookie设置特定的会话。当客户端要与服务器(最终服务器或中间代理)进行通信时,它将执行以下步骤:
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
如果激活了HTTP管道传输,则可以发送多个请求,而无需等待完全接收到第一个响应。事实证明,HTTP管道难以在现有网络中实现,现有网络中的旧软件与现代版本共存。HTTP管道已被HTTP / 2取代,并在一个帧内具有更强大的复用请求。
HTTP消息(在HTTP / 1.1及更早版本中定义)是人类可读的。在HTTP / 2中,这些消息被嵌入到二进制结构(框架)中,从而允许进行优化,例如压缩标头和多路复用。即使在此版本的HTTP中仅发送原始HTTP消息的一部分,每个消息的语义也不会改变,并且客户端会(虚拟地)重构原始HTTP / 1.1请求。因此,理解HTTP / 1.1格式的HTTP / 2消息很有用。
HTTP消息有两种类型,即请求和响应,每种都有自己的格式。
HTTP请求示例:
请求包含以下元素:
GET
)POST
或名词(OPTIONS
或)HEAD
,它定义了客户端要执行的操作。通常,客户端希望获取资源(使用GET
)或发布HTML表单的值(使用POST
),尽管在其他情况下可能需要更多操作。http://
),域(此处为developer.mozilla.org
)或TCP 端口(此处为80
)。POST
类似于响应中的那些方法(如),其中包含发送的资源。响应示例:
响应包含以下元素:
基于HTTP的最常用的API是XMLHttpRequest
API,可用于在用户代理和服务器之间交换数据。现代版Fetch API
提供了相同的功能,但功能更强大,更灵活。
另一个API,即服务器发送的事件,是一种单向服务,它允许服务器使用HTTP作为传输机制将事件发送到客户端。EventSource
客户端使用该接口打开连接并建立事件处理程序。客户端浏览器会自动将到达HTTP流的消息转换为适当的Event
对象,type
如果已知,则将它们传递给已为事件注册的onmessage
事件处理程序,如果未建立特定于类型的事件处理程序,则将其传递给事件处理程序。
HTTP是易于使用的可扩展协议。客户端-服务器结构与简单添加标头的功能相结合,使HTTP能够随着Web的扩展功能一起前进。
尽管HTTP / 2增加了一些复杂性,但通过将HTTP消息嵌入帧中以提高性能,消息的基本结构自HTTP / 1.0起一直保持不变。会话流保持简单,可以对其进行调查,并使用简单的HTTP消息监视器进行调试。