5

I don't run a mission critical web site so I'm not looking for an industrial strength solution. However I would like to protect against basic attacks such as someone mocking up a false page on the hard disk and attempting to gain unauthorized access. Are there any standard techniques to ensure that form submission is only accepted from legitimate uses?

deltanovember
  • 42,611
  • 64
  • 162
  • 244
  • The answers you are getting so far (although good) are quite broad in scope. If you could make your question more specific, you might get more detailed answers. In particular, what kind of authorization are you using, that can be circumvented by 'mocking up a false page'? – Todd Owen Jan 18 '11 at 03:59
  • Once someone has access to your disk its game over. They have remote code execution at that point. Standard Techniques? Against what? Read OWASP. – rook Jan 18 '11 at 19:02
  • @rook - I'd imagine that deltanovember was referring to the attackers' own hard drive. – PiggyMacPigPig Jul 05 '18 at 15:14

5 Answers5

7

A few techniques come close:

  • Produce a form key for every form. The key would relate to a database record, and something else unique about the page view (the userID, a cookie, etc.). A form cannot be posted if the form key does not match for that user/cookie. The key is used only once, preventing an automated tool from posting again using a stolen key (for that user).
  • The form key can also be a shared-secret hash: the PHP generating the form can hash the cookie and userID, for example, something you can verify when the form is posted.
  • You can add a captcha, requiring a user to verify.
  • You can also limit the number of posts from that user/cookie (throttling), which can prevent certain forms of automated abuse.

You can't guarantee that the form isn't posted from disk, but you can limit how easily it is automated.

Bruce Alderson
  • 1,517
  • 13
  • 19
5

You can't. There's no reliable way to distinguish between an HTTP request generated from a user on your page, or a malicious user with their own web-page.

Just use a proper password authentication approach, and no-one will be able to break anything unless they know the password (regardless of where the HTTP requests are coming from). Once you have reliable server-side authentication, you don't need to waste time jumping through non-robust hoops worrying about this scenario.

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • @Ben: That's easy for a malicious attacker to circumvent. – Oliver Charlesworth Jan 17 '11 at 23:47
  • Using password authentication doesn't protect against a person with low level credentials manipulating page markup (with developer tools built into every browser) and sending requests back to your server to exploit loopholes. You can't trust any request from the browser. You must require SSL, and validate all inputs on the server side to ensure the person is authorized to perform the task being attempted and they aren't trying to damage your system. I highly recommend watching OWASP Top 10 Videos https://www.owasp.org/index.php/Category:OWASP_Video – RonnBlack Oct 11 '19 at 04:44
4

You should not create a login-system yourself because it is difficult to get it right(security). You should NOT store the passwords(in any form whatsoever) of your users on your site(dangerous) => Take for example lifehacker.com which got compromised(my account too :(). You should use something like lightopenid(as stackoverflow also uses openid) for your authentication.

The remaining forms you have on your site should have the following protection(at least):

Community
  • 1
  • 1
Alfred
  • 60,935
  • 33
  • 147
  • 186
1

i also recommend:

  1. Save the IP of the computer that sends the form (to block it from the server if it.s annoying)
  2. Use CAPTCHA when required, to avoid robots...
  3. Send users to another page when the info is loaded, so the POST data won't be retrieved when you refresh the page.
Linus Kleen
  • 33,871
  • 11
  • 91
  • 99
Raul Leaño Martinet
  • 2,035
  • 6
  • 28
  • 44
1

Proper validation of form data is important to protect your form from hackers and spammers!

  • Strip unnecessary characters (extra space, tab, newline) from the user input data (with the PHP trim() function)
  • Remove backslashes () from the user input data (with the PHP stripslashes() function)

for more detail, you can refer to Form Validation

Mohsin Saeed
  • 97
  • 1
  • 3