Which HTML form attack vectors are there?

Question

Hi,

I am starting to have a look at HTML form security. So far my research revealed three main attack vectors:

1. Cross-site request forgery (CSRF)
2. Cross-site scripting (XSS)
3. SQL Injection

My question is: Are there more attack vectors for HTML forms than these? I am interested in a list of possible attacks through HTML forms.

Answer 1

It always depends on what the form is doing.

Code injection would be another threat (which SQL injection belongs to).

Answer 2

don't forget to look at request forgery. if you do not properly validate an action, atackers could do something like that:

<img src="http://mysite.com/delete_post/4" style="display:none">

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.

Answer 3

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:

• Assuming type=hidden fields are not visible to or will not be manipulated by a user
• Not submitting sensitive data via HTTPS
• Incorrectly masking data (e.g. displaying last N digits of credit card to the user, but all digits are somewhere in the page anyway)
• For languages like PHP where GET and POST data can be accessed from different arrays, applying security checks to $_POST, but taking values from $_GET

Workflow or "business logic" problems aren't specific to forms, but they apply more often to the functionality often handled with them:

• Inadequate workflow enforcement, such as form A must be filled out before form B, but the state transition is tracked on the client side rather than the server side. (A user can skip a step that shouldn't be skipped.)
• Lack of rate limiting. This depends on context, e.g. hitting a form that sends emails to spams users or the ops team, repeatedly hitting an "apply discount" form to reduce a price, a search that requires full table scan might lead to a DoS.

Answer 4

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.