My email contact form has been attacked by
buletmann@aol.comThis "guy" seems to test all the web forms he finds to see if they can be exploited for sending spam.
http://www.google.fr/search?hl=fr&q=buletmann%40aol.com&btnG=Google+SearchThe technique used is very simple. He adds headers to transform a plain-text message into a multipart message and override the email destination.
My form already sends the message as multipart to avoid that kind of piracy (that's documented on the php site).
But the official mail recepient still recieved tons of those hacking tests.
I added some code that checks the message for keywords that are mandatory when you use that hacking technique ("content-type", "boundry=", "multipart"). That works fine. I display an error message when honorable visitors are trying to send a message that contains one of those terms (that should not occur very often).
But the server still has to process all those hacking requests.
What are the different ways we can protect a form against that type of attack and against other types of attack?
I find captcha complicated to implement and complicated to use for visitors.
I would like a protection that only requires PHP, html and javascript (no database).
These are my current thoughts:
1. Use a session variable.
A random value is saved to the user session when the form is loaded.
That value is included in the form as a hidden field.
The page that processes the form checks if the values match and unset the session variable.
This should protect the form against simple flooding...
The flooding program would need to load the form and read the hidden value each time, otherwise the form won't be processed.
That requires cookies to be enabled on the client side (i refuse to pass the session id in the url).
2. Use obscure names for my form fields.
I currently use name="email" and name="message".
I could change that to name="field1" and name="filed2".
That might make it harder for spiders to identify my form as an email contact form.
3. Use javascript to construct the form's action
That is similar to the technique used to protect email adresses from being harvest by spiders.
Obviously, that requires javascript to be enabled on the client side.
4. Use some timeout
The server can use some reversible encryption method to encrypt the server timestamp and add that to the form as a hidden field.
When the form is processed, the server decrypts the submitted timestamp.
If that timestamp is larger than the current time or if the difference between the timestamp and the current server time is larger than some arbitrary timeout, the server does not process the form.
When the server does not process the form, it displays a confirmation form that includes a new encoded timestamp. Something like "You have taken 2 hours and 24 minutes to submit this form, please confirm".
The reversible encryption can be based on a key that is automatically generated at regular intervals (every day for instance).
So, even if some hacker finds the key that allows him/her to generate the encoded timestamps, that key will only work for a certain period of time.
The timeout needs to be small (1-5 minutes). Hackers will be able to submit any number of forms using the same encrypted timestamp until the timeout is reached. It should not be a big problem for the user, in the worst case, all he/she has to do is to hit the confirm button. The the timeout should be large enough for a dialup visitor to be able to send the confirmation comfortably, even when the server is under high load.
5. Use some timeout in combination with AJAX
We can use AJAX to query the server for a fresh encoded timestamp using the form's "onsubmit" event. This way, the confirmation dialog descibed in #4 would only display when AJAX is not supported. This would allow us to use a very small timeout (20-30 seconds) and keep it easy to use for most visitors. The confirmation dialog could then say something like "You have 30 seconds to send a confirmation".
This forum seems to use something similar... there is some network activity before each post gets submitted.
Criticism, additional info, links, references and other personal ideas are welcome.
GS.
