Web应用安全性: HTTP简介(3)

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

从理论上讲，网站不一定是安全的，但在实践中，这会吓跑用户 - 这是理所当然的。 当 H2 还没普遍时，坚持使用未加密的纯HTTP通信是有意义的，如今几乎没有理由这样做。

GET 和 POST

正如我们前面看到的，HTTP请求以一个特殊的请求行开始:

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

理论上，没有一种方法比其他方法更安全;实际上，事情并没有那么简单。

GET 请求通常不带主体，因此参数包含在 URL 中(如 www.example.com/articles?article_id=1)，而 POST 请求通常用于发送(“post”)包含在内的数据。

另一个区别在于这些动词带有的副作用：GET 是一个幂等动词，意思是无论你要发送多少个请求，你都不会改变网络服务器的状态。 相反，POST 不是幂等的：对于你发送的每个请求，你可能正在更改服务器的状态(例如，考虑发布新的付款 - 现在您可能理解为什么站点要求你在执行时不刷新页面 交易)。

幂等性：指一次和多次请求某一个资源应该具有同样的副作用，也就是一次访问与多次访问，对这个资源带来的变化是相同的。

为了说明这些方法之间的一个重要区别，我们需要看一看 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 200 
192.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 200 
192.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 

如你所见，web服务器记录请求路径:这意味着，如果你在 URL 中包含敏感数据，那么它将被 web 服务器泄露并保存在你的日志中的某个位置—你的密钥将以明文的形式出现，这是我们绝对需要避免的。假设攻击者能够访问你的一个旧日志文件，该文件可能包含信用卡信息、私有服务的访问令牌等等:这将是一场彻底的灾难。

Web 服务器不记 录HTTP标头或主体，因为要保存的数据太大 - 这就是为什么通过请求主体而不是URL发送信息通常更安全。 从这里我们可以得出 POST(和类似的，非幂等方法)比 GET 更安全，即使更多的是使用特定动词时数据的发送方式而不是特定动词本身比其他动词更安全：如果你 将敏感信息包含在 GET 请求的主体中，然后你不会遇到比使用 POST 时更多的问题，即使这种方法被认为是不寻常的。

我们信任 HTTP 报头

在本文中，我们研究了HTTP，它的演变以及它的安全扩展如何集成身份验证和加密，以使客户端和服务器通过安全通道进行通信：这不是所有 HTTP 在安全性方面提供的。

正如我们将在下一篇文章中看到的，HTTP安全头文件提供了一种改进应用程序安全状态的方法，下一篇文章将致力于理解如何利用它们。

（编辑：ASP站长网）