TL;DR： HTTPS 提供加密，它是唯一保护参数的东西。

众所周知，嵌入了 ?xx=yy 参数的 GET 请求可以在传输过程中被更改，因此是不安全的。

如果您不使用加密，那么一切都是不安全的：HTTP、Telnet、FTP、TFTP、IRC、SNMP、SMTP、IMAP、POP3、DNS、Gopher...

如果我将请求更改为 POST ...

...它根本没有改变任何东西。

并使用 HTTPS...

HTTPS 改变了一切。

任何不受 TLS 保护的 HTTP 请求都不受保护。无论您使用 GET、POST、PUT，如果它是自定义标头，都不会改变任何事情。

例如，这是一个 GET 请求：

GET /test?field1=value1&field2=value2 HTTP/1.1
Host: foo.exam
Accept: text/html

这是一个 POST 请求：

POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2

有什么区别？在 GET 请求中，参数位于第一行，而在 POST 中，参数位于最后一行。只是。GET 或 POST 背后的技术原因不是这里的重点。

假设 GET 样式参数被添加到 POST 请求中——这些参数会被可靠地忽略吗？

这完全取决于应用程序。例如，在 PHP 上，如果应用程序期望$username = $_POST['username']，将其作为 GET 参数发送根本不会改变，因为应用程序将获取 POST 参数。

那么某种安全降级攻击呢？如果 URL 操纵器强制 HTTPS 事务失败，然后客户端/服务器“有帮助”降级到 HTTP，这将允许操纵未加密的 POST 正文。

对于正确配置的服务器来说并不容易。如果他们使用HTTP 严格传输安全标头，它会强制客户端仅使用 HTTPS 访问站点，即使用户强制使用 HTTP 和端口 80。浏览器将有助于升级到 HTTPS，而不是其他方式。

即使在不使用 HSTS 标头的服务器上，如果第一次访问是通过 HTTPS 完成的，降级到 HTTP 也并非易事。攻击者必须发送伪造的证书，并且客户端必须接受伪造的证书才能将 HTTPS 连接重定向到 HTTP。但是如果攻击者成功了，他通常会继续使用 HTTPS，因为客户端已经接受了他的假证书。

不不不。

HTTPS 保护整个 HTTP 请求。url 路径、参数、cookie、http 标头、正文……它唯一不保护的东西（除了 tcp 参数，如 ip 地址和端口）是您要连接的主机名，它通过 SNI 泄露扩展（这应该由tls-esni 修复，现在只是一个草稿）

因此，当使用 HTTPS 时，在 GET 中发送“敏感”参数（例如用户和密码，或银行帐户到帐单）并不是不安全的，因为攻击者可以更改它。

（如果不使用 HTTPS，即使使用 POST 也是一个坏主意）

然而，它仍然是有问题的。

• GET 参数是 url 的一部分，并出现在服务器日志、浏览器历史记录、网站分析、页面打印、页面的防病毒分析...
• GET 请求被定义为幂等的。重试 GET 请求（甚至自动）不应有副作用。您可以想象如果请求的意思是“请将此金额转入帐户###”会发生什么
• 另一方面，POST 没有这种行为。在重新发送 POST 请求之前，您肯定会注意到您的浏览器警告您，警告可能再次发生的操作。
• 通过 GET 获得某些参数可以帮助进行会话固定攻击（例如，在收取“您的”在线信用之前，让您加载一个使用攻击者的用户和密码记录您的 url）
• 一般来说，让某人加载带有一些参数的页面比通过 POST 更容易（但仍然可以使用 javascript，但使用反 XSS 令牌）。

假设 GET 样式参数被添加到 POST 请求中——这些参数会被可靠地忽略吗？

这取决于网站。他们可能只接受一些参数作为 GET 和其他只作为 POST，但也接受一些作为 GET 或 POST。如果以两种方式提供具有相同名称的 a 参数，他们可能会选择 POST 一种，但可以将其配置为使用 GET，或者也可以错误输出。

那么某种安全降级攻击呢？如果 URL 操纵器强制 HTTPS 事务失败，然后客户端/服务器“有帮助”降级到 HTTP，这将允许操纵未加密的 POST 正文。

自动将 HTTPS 请求降级为 HTTP 的客户端（正如您所注意到的，网络上的攻击者可以很容易地做到这一点）是完整且完全损坏的。请为此提交 CVE。

众所周知，嵌入了 ?xx=yy 参数的 GET 请求可以在传输过程中被更改，因此是不安全的。

这通常是指 GET 请求被记录在历史日志中的情况，包括本地浏览器和可能的内容检查软件或代理。否则，通过 TLS 使用 HTTP GET 和 POST 请求在安全性方面没有功能差异。

还有两个案例与我有关。假设 GET 样式参数被添加到 POST 请求中——这些参数会被可靠地忽略吗？

完全取决于您的应用程序的代码。

那么某种安全降级攻击呢？如果 URL 操纵器强制 HTTPS 事务失败，然后客户端/服务器“有帮助”降级到 HTTP，这将允许操纵未加密的 POST 正文。

您可以选择使用严格传输安全 (HSTS) 和preload. 这指示浏览器在一定的超时时间内拒绝访问 HTTP 中的给定站点。并且有一个初始请求，除非您使用preload浏览器，否则需要了解 HSTS 已启用。

如果您在浏览器中看到该 URL，这并不意味着该 URL 是以这种形式通过网络发送的。在 HTTPS 的情况下，攻击者只能看到您请求的目标主机和端口。攻击者看不到更多类似方法、URL、标头、正文的东西。

如果您使用 HTTPS，您的数据将无法在到达目标主机和端口的途中发生更改。这也适用于 URL：它对任何人都是不可见的，也不能被操纵。

在服务器解密您的请求后，该 URL 仅在服务器端可见。