Hey guys,
What is the most efficient way to stop people from putting a form on their own site that posts data to a page on your site? Doing this they can insert bad data into your database. Is making sure on your page that the referrer is a page on your domain good enough? Thus ignoring POST data coming from external websites.
Please let me know if this is a good solution or if there are others, better ones?
Thank you!
HTTP is a stateless protocol. There is no way to stop this against a determined hacker. Therefore you can never fully trust the data coming from any form.
You can protect the page using some authentication means but I’m guessing this is for some contact us page or the like that is open to the public without a log in. In that event you only have a few options.
One of the best is to see if you have a session for the user. Whether logged in or not they should have a session id. Use a heap table to store when the form is sent to a browser and what session it was under. If you get a post request without a corresponding form request for the same session you can be fairly certain it is an attack.
That said, the attacker can spoof the session. So drop the session from the heap table on submit. This forces their script to request the form each time they submit.
Finally time them - note the time you sent the form on said heap table and the time of the response. A bot can send a response faster than humanly possible. Disregard posts received like that. Force the attacker to wait.
At this point if they are simply looking for a spam relay they’ll go to a softer target, but with persistence even this can be thwarted. However, you will have neutralized most of the advantages of automating the attack.
Beyond this you’ll have to use some form of user auth I think.
EDIT: HTTP_REFERER is useless for this purpose. It and all $SERVER vars that start with HTTP are provided by the client and can be faked by a reasonably competent hacker.
Great response man. Thank you very much for the feedback. Anywa, one last uestion. Will forcing users to be logged in with a login session and tuff thwart these atttacks 100% or at least a LOT moe?
Ultimately you’re playing a ‘slow them down’ game, not a stop them game. Sitepoint and all vbulletin sites get spammed regularly after all. If the spammers have to make an account they’ll figure out a way.
Keep this in mind, most spam attacks are conducted by bots. vBulletin sites are attacked by bots specific to vbulletin since there are tons of vb sites out there. If you’re solution is custom them that alone will shut off most bots and script kiddies. You’ll just have to worry with people who know what they are doing, which is relatively rare.
The only real solution is a whitelist, but that isn’t practical for most sites.
Great. Thank you. Appreciate it
Wait are you sure using REFERRER is 100% useless? The way I see it, it can stop people from hosting a replica of the form from my site on their own site and using that one to submit arbitrary text. Because my page will see that the REFERRER is from notmysite.com (the attacker’s site that has the replica form) and will thus ignore it.
I mean your ways are better at handling this, but isn’t using REFERRER able to stop some noob attackers at least who can’t forge their REFERRER?
REFERRER can be spoofed by bots, and it can be blank for legitimate users (Remember the days when Javascript being disabled was common?). I can make my REFERRER look like it’s coming from your site.
REFERRER should never be used for any sort of reliability.
How do you guarantee someone came into your form before submitting data? Have the form page create a $_SESSION variable on load, and check for it (and delete it) on submit. (This btw is how CAPTCHA works)
Wont stop the bots (they’ll just bounce off your form first to set the variable, then submit their data), but it’ll slow them down a bit until they figure it out.