为什么表格不应该与GET一起提交

Question

我有一个我用GET提交的表单，这意味着数据会附加到URL中。表单由安全令牌保护。

我总是被告知应该使用POST提交表单。在我的情况下，如果表格是通过GET提交的，会发生什么？那里的安全风险是什么？

Answer 1

真正的风险是用户能够准确查看提交给您服务器的参数，并且不仅可以为该URL添加书签（重新提交），还可以修改URL以向服务器提交其他可能无意义的参数边脚本。

在某些情况下，这是可取的（例如Google使用GET以便可以对搜索进行书签），而在其他情况下，这会带来风险（例如，登录表单）。

在您自己的情况下，它取决于“安全令牌”的性质，如果您的站点/应用程序的用户可以看到（并且可修改）该令牌，​​则可能会造成伤害。但值得注意的是，即使您使用POST提交表单，这在提交页面的html源代码中也是可见的。

根据服务器端脚本收到的数据发生的情况，您还应该清理提交的信息，减少SQL注入的范围等等（+1到@Switz）。< / p>

Answer 2

如果您有大型表单，请记下每个浏览器的URL长度限制

• Maximum URL length is 2083 characters in Internet Explorer
• What's the Maximum URL length in Firefox
• Discussion on web-server URL length limit (IIS especially)

URL Length = protocol+domain+port+query_string (GET)

出于安全方面的考虑，其他答案也很清楚 请注意，表单提交不需要具有书签功能

Answer 3

如果你有一个实现良好的令牌，那么除了书签问题之外没有区别。 GET将允许您使用提交的参数为URL添加书签，POST不会。 至于什么是实现良好的令牌，我会说12-15个字符长的随机字符串，哈希到MD5应该做的工作。

一般来说，GET被认为更容易通过Cross Site Scripting Forgery来利用，但如果你有令牌并不重要，那么再次认可。

任何用户都可以向服务器端脚本提交任何荒谬或重新提交的数据，无论数据是如何在那里发送的（POST或GET），所以这不是一个有效的考虑因素......这是任务服务器端脚本，用于验证提交的数据，并决定是否处理它。如果敏感信息提交给服务器，您应该使用POST，以避免用户为其添加书签，主要是为了避免浏览器将其存储在浏览历史记录中，这样任何人都可能会查看用户的密码等。

数据清理至关重要，但与表单方法无关。一般来说，针对XSS（htmlentities），SQL注入（mysql_real_escape_string）的保护被认为是应该在用户输入上实现的最基本的保护（前者如果用户提交的数据将出现在html源代码中，如果您使用sql访问提交的数据，则后者。

Answer 4

IMO使用POST的主要原因不是安全性（您可以保护GET），但这是一个具有正确语义的问题。

GET请求应该没有副作用。例如，使用GET的搜索表单非常好。 如果用户使用后退按钮，可能会重复GET请求，或者某些反病毒或内部加速器可能会在用户实际访问之前执行它，...

GET的一个安全问题是url（以及令牌）成为冲浪历史的一部分。因此，您必须使用一次性令牌进行GET请求。