web安全简介

by Alex Nadalin

通过亚历克斯·纳达林

Web安全：HTTP简介 (Web Security: an introduction to HTTP)

This is part 2 of a series on web security: part 1 was “Understanding The Browser”

这是有关网络安全的系列文章的第2部分：第1部分是“ 了解浏览器 ”

HTTP is a thing of beauty: a protocol that has survived longer than 20 years without changing much.

HTTP是一件很美的事情：一个协议可以生存超过20年而没有太大变化。

As we’ve seen in the previous article, browsers interact with web applications through the HTTP protocol, and this is the main reason we’re drilling down on the subject. If users would enter their credit card details on a website and an attacker would be able to intercept the data before it reaches the server, we would definitely be in trouble.

正如我们在上一篇文章中所看到的，浏览器通过HTTP协议与Web应用程序进行交互，这是我们深入研究该主题的主要原因。 如果用户在网站上输入他们的信用卡详细信息，并且攻击者能够在数据到达服务器之前对其进行拦截，那么我们肯定会遇到麻烦。

Understanding how HTTP works, how we can secure the communication between clients and servers, and what security-related features the protocol offers is the first step towards improving our security posture.

理解HTTP的工作原理，如何保护客户端与服务器之间的通信以及协议提供哪些与安全相关的功能是改善我们的安全状况的第一步。

When discussing HTTP, though, we should always discern between the semantics and technical implementation, as they’re two very different aspects of how HTTP works.

但是，在讨论HTTP时，我们应该始终区分语义和技术实现，因为它们是HTTP工作方式的两个截然不同的方面。

The key difference between the two can be explained with a very simple analogy: 20 years ago people cared about their relatives as much as they do now, even though the way they interact has substantially changed. Our parents would probably take their car and head over to their sister’s in order to catch up and spend some family time together.

可以用一个非常简单的类比来解释两者之间的主要区别：20年前，尽管他们的互动方式已经发生了很大的变化，但人们像现在一样关心他们的亲戚。 我们的父母可能会带上汽车前往姐姐的家，以便赶上并花一些家庭时间在一起。

Instead, these days it’s more common to drop a message on WhatsApp, make a phone call or use a Facebook group, things that weren’t possible earlier on. This is not to say that people communicate or care more or less, but simply that the way they interact changed.

取而代之的是，如今，更常见的是在WhatsApp上发送消息，打电话或使用Facebook组，而这在早期是不可能的。 这并不是说人们或多或少地交流或关心，而仅仅是说他们互动的方式已经改变。

HTTP is no different: the semantics behind the protocol hasn’t changed much, while the technical implementation of how clients and servers talk to each other has been optimized over the years. If you look at an HTTP request from 1996 it will look very similar to the ones we saw in the previous article, even though the way those packets fly through the network is very different.

HTTP没什么不同：协议背后的语义没有太大变化，而多年来，客户端和服务器之间如何通信的技术实现已得到优化。 如果您查看1996年以来的HTTP请求，它将看起来与我们在上一篇文章中看到的请求非常相似，即使这些数据包通过网络的传输方式非常不同。

总览 (Overview)

As we’ve seen before, HTTP follows a request/response model, where a client connected to the server issues a request, and the server replies back to it.

如我们之前所见，HTTP遵循请求/响应模型，在该模型中，连接到服务器的客户端发出请求，然后服务器回复该请求。

An HTTP message (either a request or a response) contains multiple parts:

HTTP消息(请求或响应)包含多个部分：

• “first line”“第一行”
• headers标头
• body身体

In a request, the first line indicates the verb used by the client, the path of the resource it wants as well as the version of the protocol it is going to use:

在请求中，第一行指示客户端使用的动词，所需资源的路径以及将使用的协议版本：

GET /players/lebron-james HTTP/1.1

In this case, the client is trying to GET the resource at /players/lebron-james through version 1.1 of the protocol - nothing hard to understand.

在这种情况下，客户端试图通过协议的1.1版在/players/lebron-james上GET资源-很难理解。

After the first line, HTTP allows us to add metadata to the message through headers, which take the form of key-value pairs, separated by a colon:

第一行之后，HTTP允许我们通过标头将键值对形式添加元数据到消息中，并以冒号分隔：

GET /players/lebron-james HTTP/1.1Host: nba.comAccept: */*Coolness: 9000

In this request, for example, the client has attached 3 additional headers to the request: Host, Accept and Coolness.

例如，在此请求中，客户端将3个附加标头附加到请求： Host ， Accept和Coolness 。

Wait, Coolness?!?!

等一下， Coolness ？！？！

Headers do not have to use specific, reserved names, but it’s generally recommended to rely on the ones standardized by the HTTP specification: the more you deviate from the standards, the less the other party in the exchange will understand you.

标头不必使用特定的保留名称，但通常建议使用HTTP规范所标准化的名称：您偏离标准越多，交换的另一方对您的了解就越少。

Cache-Control is, for example, a header used to define whether (and how) a response is cacheable: most proxies and reverse proxies understand it as they follow the HTTP specification to the letter. If you were to rename your Cache-Control header to Awesome-Cache-Control, proxies would have no idea on how to cache the response anymore, as they’re not built to follow the specification you just came up with.

例如， Cache-Control是用于定义响应是否(以及如何)可缓存的标头：大多数代理和反向代理都遵循HTTP规范来理解它。 如果将Cache-Control标头重命名为Awesome-Cache-Control ，则代理将不再具有如何缓存响应的想法，因为它们并未遵循您刚提出的规范。

Sometimes, though, it might make sense to include a “custom” header into the message, as you might want to add metadata that is not really part of the HTTP spec: a server could decide to include technical information in its response, so that the client can, at the same time, execute requests and get important information regarding the status of the server that’s replying back:

不过，有时候，在消息中包含“自定义”标头可能是有意义的，因为您可能想添加不是HTTP规范真正组成部分的元数据：服务器可以决定在响应中包括技术信息，以便客户端可以同时执行请求并获取有关正在回复的服务器状态的重要信息：

...X-Cpu-Usage: 40%X-Memory-Available: 1%...

When using custom headers, it is always preferred to prefix them with a key so that they do not conflict with other headers that might become standard in the future: historically, this has worked well until everyone started to use “non-standard” X prefixes which, in turn, became the norm. The X-Forwarded-For and X-Forwarded-Proto headers are examples of custom headers that are widely used and understood by load balancers and proxies, even though they weren’t part of the HTTP standard.

使用自定义标头时，始终首选为它们添加关键字前缀，以免它们与将来可能成为标准的其他标头冲突：从历史上看，这种方法一直有效，直到每个人都开始使用“非标准” X前缀反过来，这成为了规范。 X-Forwarded-For和X-Forwarded-Proto标头是负载均衡器和代理广泛使用和理解的自定义标头的示例，即使它们不是HTTP标准的一部分也是如此 。

If you need to add your own custom header, nowadays it’s generally better to use a vendored prefix, such as Acme-Custom-Header or A-Custom-Header.

如果您需要添加自己的自定义标头，那么如今通常最好使用供应商提供的前缀，例如Acme-Custom-Header或A-Custom-Header 。

After the headers, a request might contain a body, which is separated from the headers by a blank line:

在标头之后，请求可能包含一个主体，该主体与标头之间用空行分隔：

POST /players/lebron-james/comments HTTP/1.1Host: nba.comAccept: */*Coolness: 9000

Best Player Ever

Our request is complete: first line (location and protocol information), headers and body. Note that the body is completely optional and, in most cases, it’s only used when we want to send data to the server — that is why the example above uses the verb POST.

我们的请求已完成：第一行(位置和协议信息)，标头和正文。 请注意，主体是完全可选的，并且在大多数情况下，仅在我们要将数据发送到服务器时才使用它，这就是为什么上面的示例使用动词POST 。

A response is not very different:

响应不是很不同：

HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

The first information the response advertises is the version of the protocol it uses, together with the status of this response. Headers follow suit and, if required, a line break followed by the body.

响应通告的第一个信息是它使用的协议的版本以及此响应的状态。 标头会跟进，并且，如果需要，请在正文后插入换行符。

As mentioned, the protocol has undergone numerous revisions and has added features over time (new headers, status codes, etc), but the underlying structure hasn’t changed much (first line, headers, and body). What really changed is how client and servers are exchanging those messages — let’s take a closer look at that.

如前所述，该协议经过了多次修订，并随着时间的推移增加了功能(新的标头，状态代码等)，但是底层结构并没有太大变化(第一行，标头和主体)。 真正改变的是客户端和服务器如何交换这些消息-让我们仔细研究一下。

HTTP vs HTTPS vs H2 (HTTP vs HTTPS vs H2)

HTTP has seen 2 considerable semantic changes: HTTP/1.0 and HTTP/1.1.

HTTP发生了2个重大的语义变化： HTTP/1.0和HTTP/1.1 。

“Where are HTTPS and HTTP2?”, you ask.

您问：“ HTTPS和HTTP2在哪里？”。

HTTPS and HTTP2 (abbreviated as H2) are more of technical changes, as they introduced new ways to deliver messages over the internet, without heavily affecting the semantics of the protocol.

HTTPS和HTTP2(缩写为H2)更多是技术更改，因为它们引入了新的方式来通过Internet传递消息，而又不会严重影响协议的语义。

HTTPS is a “secure” extension to HTTP and involves establishing a common secret between a client and a server, making sure we’re communicating with the right party and encrypting messages that are exchanged with the common secret (more on this later). While HTTPS was aimed at improving the security of the HTTP protocol, H2 was geared towards bringing light-speed to it.

HTTPS是HTTP的“安全”扩展，它涉及在客户端和服务器之间建立一个公共机密，以确保我们正在与正确的一方进行通信并加密与该公共机密交换的消息(稍后会详细介绍)。 HTTPS旨在提高HTTP协议的安全性，而H2则致力于为其带来光速。

H2 uses binary rather than plaintext messages, supports multiplexing, uses the HPACK algorithm to compress headers… …long story short, H2 is a performance boost to HTTP/1.1.

H2使用二进制而不是纯文本消息，支持多路复用，使用HPACK算法压缩报头…………总之，H2是对HTTP / 1.1的性能提升。

Websites owners were reluctant to switch to HTTPS since it involved additional round-trips between client and server (as mentioned, a common secret needs to be established between the 2 parties), thus slowing the user experience down: with H2, which is encrypted by default, there are no more excuses, as features such as multiplexing and server push make it perform better than plain HTTP/1.1.

网站所有者不愿意切换到HTTPS，因为它涉及客户端和服务器之间的附加往返(如上所述，需要在两方之间建立一个共同的秘密)，从而减慢了用户体验：使用H2(由H2加密)默认情况下，没有更多的借口，因为多路复用和服务器推送等功能使其性能比纯HTTP / 1.1更好 。

HTTPS (HTTPS)

HTTPS (HTTP Secure) aims to let clients and servers talk securely through TLS (Transport Layer Security), the successor to SSL (Secure Socket Layer).

HTTPS( HTTP安全 )旨在让客户端和服务器通过TLS(传输层安全性)(SSL(安全套接字层)的后继)安全地进行通信。

The problem that TLS targets is fairly simple, and can be illustrated with one simple metaphor: your better half calls you in the middle of the day, while you’re in a meeting, and asks you to tell them the password of your online banking account, as they need to execute a bank transfer to ensure your son’s schooling fees are paid on time. It is critical that you communicate it right now, else you face the prospect of your kid being turned away from school the following morning.

TLS定位的问题非常简单，可以用一个简单的比喻来说明：您最好的另一半在一天中开会时打电话给您，并要求您告诉他们网上银行的密码帐户，因为他们需要执行银行转帐以确保按时支付您儿子的学费。 您现在就进行交流非常重要，否则您将面临第二天早上孩子被放学的前景。

You are now faced with 2 challenges:

您现在面临两个挑战：

• authentication: ensuring you’re really talking to your better half, as it could just be someone pretending to be them

  身份验证 ：确保您确实在与自己的另一半谈话，因为它可能只是假装自己的人

• encryption: communicating the password without your coworkers being able to understand it and note it down

  加密 ：在您的同事无法理解和记录下来的情况下传达密码

What do you do? This is exactly the problem that HTTPS tries to solve.

你是做什么？ 这正是HTTPS试图解决的问题。

In order to verify who you’re talking to, HTTPS uses Public Key Certificates, which are nothing but certificates stating the identity behind a particular server: when you connect, via HTTPS, to an IP address, the server behind that address will present you its certificate for you to verify their identity. Going back to our analogy, this could simply be you asking your better half to spell their social security number. Once you verify the number is correct, you gain an additional level of trust.

为了验证您正在与谁交谈，HTTPS使用公共密钥证书，该证书只不过是说明特定服务器背后身份的证书：当您通过HTTPS连接到IP地址时，该地址后面的服务器将向您显示其证书供您验证其身份。 回到我们的比喻，这可能只是您要求您的另一半拼写他们的社会保险号。 验证数字正确后，您将获得更高的信任度。

This, though, does not prevent “attackers” from learning the victim’s social security number, stealing your soulmate’s smartphone and calling you. How do we verify the identity of the caller?

但是，这并不能阻止“攻击者”了解受害者的社会安全号码，窃取您的知己的智能手机并给您打电话。 我们如何验证呼叫者的身份？

Rather than directly asking your better half to spell their social security number, you make a phone call to your mom instead (who happens to live right next door) and ask her to go to your apartment and make sure your better half is spelling their social security number. This adds an additional level of trust, as you do not consider your mom a threat, and rely on her to verify the identity of the caller.

与其直接让您的另一半打电话给他们的社会安全号码，不如直接打电话给您的妈妈(后者恰好住在隔壁)，让她去您的公寓并确保您的另一半正在拼写他们的社会保险号。安全号码。 这样就增加了信任度，因为您不认为妈妈是威胁，而是依靠妈妈来验证呼叫者的身份。

In HTTPS terms your mom’s called a CA, short for Certificate Authority: a CA’s job is to verify the identity behind a particular server, and issue a certificate with its own digital signature: this means that, when I connect to a particular domain, I will not be presented a certificate generated by the domain’s owner (called self-signed certificate), but rather by the CA.

用HTTPS术语来说，您妈妈被称为CA，是证书颁发机构的简称：CA的工作是验证特定服务器背后的身份，并颁发带有其自己的数字签名的证书：这意味着，当我连接到特定域时，我会不会显示由域所有者生成的证书(称为自签名证书 )，而是由CA显示。

An authority’s job is to make sure they verify the identity behind a domain and issue a certificate accordingly: when you “order” a certificate (commonly known as SSL certificate, even though nowadays TLS is used instead - names really stick around!), the authority might give you a phone call or ask you to change a DNS setting in order to verify you’re in control of the domain in question. Once the verification process is completed, it will issue the certificate that you can then install on your webservers.

权威机构的工作是确保他们验证域的身份并相应地颁发证书：当您“订购”证书(通常称为SSL证书 ，即使如今使用TLS时，名称确实存在！)，权限可能会给您打个电话或要求您更改DNS设置，以验证您对相关域的控制权。 验证过程完成后，它将颁发证书，然后可以将其安装在Web服务器上。

Clients like browsers will then connect to your servers and be presented with this certificate, so that they can verify it looks genuine: browsers have some sort of “relationship” with CAs, in the sense that they keep track of a list of trusted CAs in order to verify that the certificate is really trustworthy. If a certificate is not signed by a trusted authority, the browser will display a big, informative warning to the users:

然后，像浏览器这样的客户端将连接到您的服务器并获得此证书，以便他们可以验证该证书是否真实：浏览器与CA有某种“关系”，从某种意义上说，它们跟踪其中的受信任CA列表。以便验证证书确实可信。 如果证书不是由受信任的机构签名的，则浏览器将向用户显示一个大的，提示性的警告：

We’re halfway through our road towards securing the communication between you and your better half: now that we’ve solved authentication (verifying the identity of the caller) we need to make sure we can communicate safely, without others eavesdropping in the process. As I mentioned, you’re right in the middle of a meeting and need to spell your online banking password. You need to find a way to encrypt your communication, so that only you and your soulmate will be able to understand your conversation.

我们在确保您与另一半之间的通信安全的道路上已经走了一半：现在，我们已经解决了身份验证(验证呼叫者的身份)的工作，我们需要确保我们可以安全通信，而不会在过程中进行其他人的窃听。 正如我所提到的，您正准备参加会议，需要输入您的网上银行密码。 您需要找到一种加密通信的方法，以便只有您和您的知己才能理解您的对话。

You can do this by establishing a shared secret between the two of you, and encrypt messages through that secret: you could, for example, decide to use a variation of Caesar cipher based on the date of your wedding.

您可以通过在两个人之间建立共享机密并通过该机密对消息进行加密来进行此操作：例如，您可以根据结婚日期决定使用凯撒密码的变体。

This would work well if both parties have an established relationship, like yourself and your soulmate, as they can create a secret based on a shared memory no one else has knowledge of. Browsers and servers, though, cannot use the same kind of mechanism as they have no prior knowledge of each other.

如果双方都像您和您的灵魂伴侣一样建立了牢固的关系，这将很有效，因为他们可以基于彼此没有人知道的共享记忆创建秘密。 但是，浏览器和服务器不能使用相同的机制，因为它们彼此之间没有先验知识。

Variations of the Diffie-Hellman key exchange protocol are used instead, which ensure parties without prior knowledge establish a shared secret without anyone else being able to “sniff” it. This involves using a bit of math, an exercise left to the reader.

而是使用Diffie-Hellman密钥交换协议的变体，该变体可确保在没有先验知识的情况下，各方可以建立共享的秘密，而其他任何人都无法“嗅探”它。 这涉及使用一些数学 ，这是留给读者的练习。

Once the secret is established, a client and a server can communicate without having to fear that someone might intercept their messages. Even if attackers do so, they will not have the common secret that’s necessary to decrypt the messages.

一旦建立了秘密，客户端和服务器就可以通信，而不必担心有人会截获其消息。 即使攻击者这样做，他们也不会拥有解密消息所必需的公共秘密。

For more information on HTTPS and Diffie-Hellman, I would recommend reading “How HTTPS secures connections” by Hartley Brody and “How does HTTPS actually work?” by Robert Heaton. In addition, “Nine Algorithms That Changed The Future” has an amazing chapter that explains Public-key encryption, and I warmly recommend it to Computer Science geeks interested in ingenious algorithms.

有关HTTPS和Diffie-Hellman的更多信息，我建议阅读Hartley Brody的“ HTTPS 如何确保连接安全 ”和“ HTTPS如何实际工作？ ”由Robert Heaton撰写。 此外，“ 改变未来的九种算法 ”中有精彩的一章介绍了公钥加密，我热烈地将其推荐给对精巧算法感兴趣的计算机科学爱好者。

HTTPS无处不在 (HTTPS everywhere)

Still debating whether you should support HTTPS on your website? I don’t have good news for you: browsers have started pushing users away from websites not supporting HTTPS in order to “force” web developers towards providing a fully encrypted browsing experience.

还在争论是否应该在网站上支持HTTPS？ 对您来说，我不是一个好消息：浏览器已开始将用户从不支持HTTPS的网站上撤离，以“强迫”网络开发人员提供完全加密的浏览体验。

Behind the motto “HTTPS everywhere”, browsers started to take a stand against unencrypted connections - Google was the first browser vendor who gave web developers a deadline by announcing that starting with Chrome 68 (July 2018) it would mark HTTP websites as “not secure”:

在座右铭“ 无处不在的HTTPS ”的背后，浏览器开始反对未加密的连接-Google是第一个给Web开发人员提供最后期限的浏览器供应商，宣布从Chrome 68开始(2018年7月)，它将HTTP网站标记为“不安全”。 ”：

Even more worrying for websites not taking advantage of HTTPS is the fact that, as soon as the user inputs anything on the webpage, the “Not secure” label turns red - a move that should encourage users to think twice before exchanging data with websites that don’t support HTTPS.

对于不使用HTTPS的网站，更让人担心的是，一旦用户在网页上输入任何内容，“不安全”标签就会变成红色-此举应鼓励用户在与网站交换数据之前三思而后行。不支持HTTPS。

Compare this to how a website running on HTTPS and equipped with a valid certificate looks like:

将其与运行在HTTPS上并配备有效证书的网站的外观进行比较：

In theory, a website does not have to be secure, but in practice, this scares users away - and rightfully so. Back in the day, when H2 was not a reality, it could have made sense to stick to unencrypted, plain HTTP traffic. Nowadays there’s almost no reason to do so. Join the HTTPS everywhere movement and help make the web a safer place for surfers.

从理论上讲，网站不必一定是安全的，但实际上，这会使用户吓跑，这是理所当然的。 过去，当H2成为现实时，坚持使用未加密的普通HTTP流量是很有意义的。 如今，几乎没有理由这样做。 加入HTTPS无处不在的运动，并帮助使网络成为冲浪者更安全的地方 。

GET与POST (GET vs POST)

As we’ve seen earlier, an HTTP request starts with a peculiar first line:

如前所述，HTTP请求以特殊的第一行开始：

First and foremost, a client tells the server what verbs it is using to perform the request: common HTTP verbs include GET, POST, PUT and DELETE, but the list could go on with less common (but still standard) verbs such as TRACE, OPTIONS, or HEAD.

首先，客户端告诉服务器它使用什么动词来执行请求：常见的HTTP动词包括GET ， POST ， PUT和DELETE ，但是列表可以继续使用不太常见(但仍是标准)的动词，例如TRACE ， OPTIONS或HEAD 。

In theory, no method is safer than others; in practice, it’s not that simple.

从理论上讲，没有任何一种方法比其他方法更安全。 在实践中，并不是那么简单。

GET requests usually don’t carry a body, so parameters are included in the URL (ie. www.example.com/articles?article_id=1) whereas POST requests are generally used to send (“post”) data which is included in the body. Another difference is in the side effects that these verbs carry with them: GET is an idempotent verb, meaning no matter how many requests you will send, you will not change the state of the webserver. POST, instead, is not idempotent: for every request you send you might be changing the state of the server (think of, for example, POSTing a new payment — now you probably understand why sites ask you not to refresh the page when executing a transaction).

GET请求通常不包含主体，因此参数包含在URL中(即www.example.com/articles?article_id=1 )，而POST请求通常用于发送(“发布”)包含在其中的数据身体。 这些动词附带的副作用是另一个区别： GET是幂等动词，意味着无论您将发送多少请求，都不会更改Web服务器的状态。 相反， POST不是幂等的：对于您发送的每个请求，您可能都在更改服务器的状态(例如，考虑过POST新付款-现在您可能已经理解为什么网站要求您在执行广告时不刷新页面交易)。

To illustrate an important difference between these methods we need to have a look at webservers’ logs, which you might already be familiar with:

为了说明这些方法之间的重要区别，我们需要看一下您可能已经熟悉的Web服务器的日志：

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201

As you see, webservers log the request path: this means that, if you include sensitive data in your URL, it will be leaked by the webserver and saved somewhere in your logs - your secrets are going to be somewhere in plaintext, something we need to absolutely avoid. Imagine an attacker being able to gain access to one of your old log files, which could contain credit card information, access tokens for your private services and so on: that would be a total disaster.

如您所见，网络服务器记录了请求路径：这意味着，如果您在URL中包含敏感数据，它将被网络服务器泄漏并保存在日志中的某个位置–您的机密信息将以纯文本格式存储，这是我们所需要的绝对避免。 想象一下，攻击者能够访问您的旧日志文件之一 ，该文件可能包含信用卡信息，用于您的私人服务的访问令牌等：那将是完全的灾难。

Webservers do not log HTTP headers or bodies, as the data to be saved would be too large - this is why sending information through the request body, rather than the URL, is generally safer. From here we can derive that POST (and similar, non-idempotent methods) is safer than GET, even though it’s more a matter of how data is sent when using a particular verb rather than a specific verb being intrinsically safer than others: if you were to include sensitive information in the body of a GET request, then you’d face no more problems than when using a POST, even though the approach would be considered unusual.

Web服务器不记录HTTP标头或正文，因为要保存的数据太大-这就是为什么通过请求正文(而不是URL)发送信息通常更安全的原因。 从这里我们可以得出POST (以及类似的非幂等方法)比GET更安全，即使它更多地是关于在使用特定动词时如何发送数据的问题，而不是特定动词在本质上比其他动词更安全：如果将敏感信息包含在GET请求的正文中，那么与使用POST相比，您所面临的问题不会更多，即使该方法被认为是不寻常的。

在HTTP标头中，我们信任 (In HTTP headers we trust)

In this article we looked at HTTP, its evolution and how its secure extension integrates authentication and encryption to let clients and servers communicate through a safe(r) channel: this is not all HTTP has to offer in terms of security.

在本文中，我们研究了HTTP，HTTP的发展以及它的安全扩展如何集成身份验证和加密以使客户端和服务器通过safe(r)通道进行通信：就安全性而言，这并不是HTTP所必须提供的。

As we’ll see in the next article, HTTP security headers offer a way to improve our application’s security posture, and the next post is dedicated to understanding how to take advantage of them.

正如我们将在下一篇文章中看到的那样，HTTP安全标头提供了一种改善应用程序安全性的方法，而下一篇则致力于理解如何利用它们。

Originally published at odino.org (22 August 2018).You can follow me on Twitter - rants are welcome! ?

最初发布于odino.org (2018年8月22日)。 您可以在Twitter上关注我-欢迎咆哮！ ？

翻译自: https://www.freecodecamp.org/news/web-security-an-introduction-to-http-5fa07140f9b3/

web安全简介