Forum Moderators: coopster
Is there a method to check if the POST originated from the server?
I have a form that users use to submit data. If a spammer were to host that form on some other server, it would be possible to submit data. I need to stop this from happening. Captcha is not an option.
Is there a method that would check if the POST was not triggered from my server?
TIA
I can't seem to think of a solution with the server variables. If a server variable were to be sent via a hidden field, a spammer would still be able to copy that.
Any ideas?
Once a spammer figures out your form, they don't place a form on another server; they post directly to the processor via command line using a robot (program.)
There are quite a few tools that need to be in place to adequately stop form spam. It's always been my opinion that if you can figure out what they are after, and take that away, they will have no interest in using your form for a spam attack.
Some key points would be:
- Make sure that data input cannot be abused to directly inject mail header information. For example, if your script does not cleanse input, I could do this:
Subject=hello\nbcc:address1@example.com,address2@example.com . . . .
The actual character wouldn't be a "\n", it could be an octal or hex character equivalent of a newline that could slip past your input filters. What I've done is created my OWN bcc field; you get one email, example.com gets 1000 or more. They abuse you for spam until you are blacklisted for sending spam and never even know it.
This approach can even be perverted to allow a multi-part email so it doesn't matter what you do with the headers; the multi-part that follows does all the work.
- Same is true of the actual to email address; if you use a "hidden" recipient field, this field could be modified:
recipient=address1@example.com,address2@example.com .....
Keep your intended recipient hidden, a constant or variable in the script, never as an input in the form.
- Throw away any characters that are not used in normal English. If some meta characters are allowed to pass through uncleansed, they can execute system commands.
- Log all input data. The only way to truly figure out "what they are up to" is to directly log raw input; this is not the same as what you'd get from server logs. Create a function that logs input to a file in some non-public location, check it often.
- Anything that echoes back to the page is a key point for injection. This can allow direct injection to your database, system, or cross site scripting. If you have this anywhere in your code,
echo $_POST['email'];
The input is allowed to pass through unfiltered and is dangerous. Once discovered, they now know the data is not filtered and attempt to use it for other injection.
- use a "no-reply" for auto responses. Sometimes they will submit the form just to get at your email. This stops this type of attack. For legitimate users, you get their email and can reply, the user now has your "real" address. When setting up the "no-reply" email account, don't even make it a mailbox; and most importantly, do not set up an autoresponder for this address. Once figured out, all someone has to do is send target emails to it and it will bounce back to the intended recipient, from YOUR server.
- Content filtering: once you've done all of the above, you can start to look for "patterns" in your log. The #1 attack I've found is link spam; it can come in various forms:
<a href=.....
[url=....
[link=....
With octal equivalents for < or [. IF any of these are found, exit the script immediately with a simple message: script halted due to malicious input. Don't be "funny" or snarky, or they are likely to turn more drastic measures against you. Just let them know nothing was sent.
There is only one exception to the above, and that is in a link exchange form. Otherwise, there is no reason to have a fully linked URL in any input field. If you have a link exchange form, make sure you do extra filtering on the link input field.
There are more, based on the situation and environment.
You will note Captcha is not in my "toolbox." With rigorous input filtering and logging, I've never had to make the task more difficult for real users.
another thing you can do, if you'd like to learn more about how people are using your script you could log it all, referers, post array, all of it, to a text/log file. Then download and view it, to see what's going on.
So if it doesn't come from your server, what's the issue? Are you trying to stop bad data or malicious data?
