2

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.

Jens
  • 20,533
  • 11
  • 60
  • 86
  • 2
    For what purpose is the form data used? – Gumbo Aug 30 '10 at 12:19
  • There is no special use for the data. It could be used the change data in a database, upload a file or login into a site. – Jens Aug 30 '10 at 12:57
  • When you upload the file, depending on what reads the file, more attack vectors can be made possible. What if you upload to some directory where all the files are remotely executable? Then a remote user can upload an executable and run it. What if you have some process that reads the file later and runs XPath, Shell, LDAP, etc queries on it? That's another attack vector. What about the code that processes the file? It's probably backed by C in some way, so that's another attack vector, although nobody is really going to audit that low except for "security researchers". – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Aug 30 '10 at 19:14

4 Answers4

2

It always depends on what the form is doing.

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

Felix Kling
  • 795,719
  • 175
  • 1,089
  • 1,143
  • @Gumbo i agree but owasp makes a distinction. – rook Aug 30 '10 at 19:11
  • @Rook: The difference is only where the injected code takes place: either on the server side (OWASP’s “Injection”) or on the client side (OWASP’S “XSS”). But it’s an unintended injection of some code in both cases. – Gumbo Aug 30 '10 at 19:43
1

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.
Mike
  • 396
  • 1
  • 4
1

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.

rook
  • 66,304
  • 38
  • 162
  • 239
0

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.

Hugo Mota
  • 11,200
  • 9
  • 42
  • 60
  • Hello Hugo, Cross-site request forgery (CSRF) is already mentioned in my list. Do you know any more possible ways to abuse HTML forms? – Jens Aug 30 '10 at 12:53
  • wow. sorry about that. i don't acctually remember all the abbreviature of that stuff ^^ i've heard about using strange characters to sploit overflow vulnerabilities. so you should be care about configuring right your encoding in every spot of your application. in the html, code pages and even the database. – Hugo Mota Aug 30 '10 at 13:39