有哪些 HTML 表单攻击媒介？
我开始研究 HTML 表单安全性。到目前为止，我的研究揭示了三种主要的攻击媒介：
- 跨站点请求伪造 (CSRF)
- 跨站点脚本 (XSS)
- SQL 注入
我的问题是：HTML 表单的攻击媒介是否比这些更多？我对通过 HTML 表单进行的可能攻击列表感兴趣。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它总是取决于表单正在做什么。
代码注入将是另一种威胁（SQL注入属于其中） 。
It always depends on what the form is doing.
Code injection would be another threat (which SQL injection belongs to).
就作为用户提供的数据的注入向量而言，表单与 URI 或标头相同。一般的“不信任客户端”规则适用，如 SQL 注入、XSS 等的可能性所示。因此，仅依赖 JavaScript 验证而没有服务器端验证的表单是不好的。
更具体的表单问题包括：
工作流或“业务逻辑”问题并不特定于表单，但是它们更频繁地应用于经常使用它们处理的功能：
A form is identical to a URI or headers in terms of being an injection vector for user-supplied data. The general "don't trust the client" rules apply as shown by the possibility of SQL injection, XSS, etc. So, forms that only rely on JavaScript validation without server-side validation are bad.
Problems more specific to forms include:
Workflow or "business logic" problems aren't specific to forms, but they apply more often to the functionality often handled with them:
阅读 owasp top 10。特别是 A1-Injection。但值得注意的是，CSRF/XSS/注入缺陷也可能出现在其他地方，例如 GET 请求和 HTTP 标头。
Read the owasp top 10. Especially A1-Injection. Although it should be noted that CSRF/XSS/Injection flaws also can crop up in other places such as GET requests and HTTP headers.
There are other issues with
<form>'s, like not using an HTTPS url if you are posting sensitive information. Also not using the "password" variable type for login forms.不要忘记查看请求伪造。如果您没有正确验证操作，攻击者可能会执行类似的操作：
这会迫使用户在不知情的情况下删除自己的帖子。因为用户自己被迫这样做，所以登录验证是不够的。仅仅迁移到岗位也是不够的。
为了解决这个问题，一种替代方法是发送带有表单的令牌（例如通过隐藏输入），该令牌将从内部进行验证。因此攻击将失败，因为攻击者不知道令牌。即使他发现了，他也只会影响一个用户，并且令牌可以在一段时间后或每次登录后更改。
don't forget to look at request forgery. if you do not properly validate an action, atackers could do something like that:
and this forces the user to delete his own post without even knowing it. and because the user himself is being forced to do that, login validation is just not enough. just migrating to post is not enough either.
to solve this, one alternative is to send a token with the form (through a hidden input for example) that will be validated from the inside. so the atack will fail since the atacker doen't know the token. and even if he discovers, he would affect just one user and the token can be changed after some time or after each login.