Web Application Defender's Cookbook

Recipe 4-5: Detecting Malicious Links

This recipe demonstrates how to use third-party RBLs to identify malicious URLs sent to or served from your site.

Ingredients

• URI Blacklist RBL6
• Google’s Safe Browsing API7
• ModSecurity
  • @rbl operator
  • @gsbLookup operator
  • @rsub operator
  • SecGsbLookupDb directive
  • SecStreamOutBodyInspection directive
  • SecContentInjection directive
  • STREAM_OUTPUT_BODY variable

Suspicious URL Identification

Using RBLs to identify known malicious clients has obvious merit. Although this information does help provide immediate data about a client’s disposition, it is insufficient on its own, because malicious clients constantly change their source location. They employ a variety of methods to loop through anonymizing systems such as the Tor network or compromised hosts to easily alter their IP address information. Sometimes the key to identifying malicious behavior is not where you are coming from but what data you are sending.

This brings us to the final recipe, which uses third-party reputation systems. However, the data analyzed is not the client’s IP address but URLs and domain names. Comment spammers and malware criminals always are looking for ways to post their hyperlinks on web sites. They hope to either drive up search engine optimization (SEO) efforts or conduct “drive-by downloads,” which aim to compromise clients’ computers with malicious code.

The challenge for web application defenders in this scenario is to be able to distinguish a malicious ...