3

I manage code detecting spam in contact forms, a common technique spammers use is mixing character codes so content checks will not recognise the phrases but a user will, as long as they are viewing in a UTF character set (if not they will see a mess of characters) so my method is detect this mixing and you've caught the spam.

For example a A is ASCII 65 but a very similar character is ASCII 1040

I'm not good on the intricacies of the different character encodings and don't want to have any 'false positives', the strings received will depend on the character set in the senders (or bot) browser and the receiving sites set character set. My current tests are:

preg_match_all("/&#([3-9]\d{2}|\d{4})\;/", $text) // ASCII > 299
strlen($text) != strlen(utf8_decode($text))

Either of the above flags mixed character codes. I would be grateful to know if there is a better way or if the above might create false positives.

  • This really depends on what restrictions (and what languages) you are allowing in user input? In some scenarios blocking numeric HTML entities in there entirety would perhaps be acceptable. But blocking all unicode characters (your 2nd line) could create too many false positives IMO - unless that is a restriction you want to impose on your users? – MrWhite Jun 28 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.