IncapRules is a new custom security rules engine that lets you integrate your own policies on top of Incapsula’s core security logic. As we’ve discussed previously in this blog, the IncapRules scripting language is now being used globally by online organizations to gain complete and granular control over application security.
In this post, we’re going to cover how IncapRules can be applied to a prevalent security issue: comment spam.
What Is Comment Spam?
Comment spam is an overarching term referring to any unsolicited advertising or sales material posing as comments on an online forum, blog, or wiki. These are often posted by spammers or spambots to create a large number of crosslinks pointing to an unrelated site, thereby artificially inflating its search engine ranking and driving traffic to it.
These links can also be malicious, infecting users who click on them with malware.
Comment spam comes in many forms: some instigators are blatant, while others attempt to be stealthy in order to hide their true intent. For example, a spammer might post a seemingly legitimate comment with the user name “Cheap Viagra,” and then use that to link back to a website offering that product.
The spammers seek to create these links at such a scale as to drive a quick spike in a website’s visibility, or to infect users en masse. To achieve the desired magnitude, they typically employ specialized bots that search for, and post on, unprotected comment sections on blogs, social media sites, forums, et al.
Identifying and blocking these automated “users” is an effective way to deal with comment spam, so Incapsula created a rule to help you deal with this annoying threat.
The IncapRule For Spam
Method == POST & ClientType == Unknown & ParamExists == "post-id" [Request JavaScript Challenge]
This rule presents a JavaScript challenge before processing POST requests from all unknown clients (i.e., those not already in Incapsula’s 10M+ signature pool covering over 500 web client variants) having a “post-id” parameter.
“Post-id” is a sample variable. To use this rule, replace this variable with a parameter included in URLs from the location of your website where comment posting is enabled.
Method == POST & (ParamValue contains {"post-id";"viagra"} | ParamValue contains {"post-id";"cialis"}) [Request CAPTCHA]
This rule requests a challenge before processing POST requests having a “post-id” parameter and a list of words you want to filter out. (You can find some ideas here.)
In essence, Incapsula presents a CAPTCHA to any user – human or machine- attempting to post about topics found on our spam blacklist. Humans are still able to post once they complete the test. Spambots are blocked on the spot, thus preventing large scale abuse.
The rule offers a good balance between hardened restrictions and a redemption option. It still freely allows human visitors to interact with your website. However, to make this even more specific and further reduce the probability of false positives, you might deploy something like this:
ClientType != Browser & Method == POST & (ParamValue contains {"post-id";"viagra"} | ParamValue contains {"post-id";"cialis"}) & URL contains "/forum/" [Request CAPTCHA]
Here, the addition of ClientType and URL contains filters refines the security rule, so as to be activated only for non-browsers and those URLs containing the term “/forum/”.
With a specific “likely to be spammed” area of the website defined and the affected user limited to bots and browsers whose footprint is yet unknown (e.g., requests heavily modified by multiple proxies) the rule is now even less likely to cause any false positives.
Also, if a user is using several proxies to publish a post about “viagra” on your forum, maybe flashing him/her a CAPTCHA is not such a bad idea.
Note that this version of the rule uses a negative “!=” operator to indicate a contradictory relations (i.e. “ClienType is not a Browser”). While you could achieve the same with another syntax often times it’s easier to simply disclude the variables to which the rule should not be applied.
More Than Meets the Eye
These examples are just a few of the nearly 90 different filters provided by IncapRules.
Employing one or more of your own creation lets you take better advantage of Incapsula’s entire range of powerful traffic inspection abilities. Using such filters, you can create custom policies based on HTTP header content, geolocation, our list of over 500 bot clients, and much more.
When employing multiple filters with various logical operators (e.g., and, and/or, larger/smaller than) to link between them, the IncapRules filter set offers limitless combinations. This empowers you to create and deploy a custom security policy for every scenario.
Try Imperva for Free
Protect your business for 30 days on Imperva.
