Our (Signatureless) Approach to Web Application Security

Posted: February 6th, 2015
Filed under: Web and Application Security


In a recent post, we focused on the problems with the signature-based security model. Signatures have been a staple of web application security and cyber security for some time, but are problematic in the sense that they don’t provide adequate protection in today’s landscape of ever-evolving threats.

Now, we want to explain how we approach web application security with our Web app firewall, ServerDefender.

(We encourage you to go back and read that article in full. It’s a good read, we promise!)

The Behavioral & Algorithm-based approach

Although we don’t use signatures, we still have a means for analyzing and determining whether or not a user is malicious.

Our method analyzes behavior by tracking the actions that occur over the course of a session. Activity is monitored by an algorithm that establishes what bad behavior looks like (we’ll touch on this more later), and should the user cause too many errors, the software will begin to take action. Users who repeatedly cause errors are going raise an alert and the software will begin to impede their site usage until they’re ultimately blocked temporarily, then permanently.

Behavioral scoring allows errors errors to broader or more generic (not signature matches but actual error states like 404s and 500s) because you’re not blocking every single error. By continuously tracking and monitoring and building up a sort of “threat profile” that discerns patterns and indicates misbehavior – even before anything that would match a threat signature is seen.

Whitelist vs. Blacklist = Greylist?

On top of behavioral scoring, we also employ a combination of blacklists and whitelists – a sort of greylist approach.

The signature model is inherently a blacklist approach to security. That means that everything is allowed by default unless it is on a ‘naughty list’ or list of malicious inputs or actions. This is dangerous because the default action is to allow, and only when something is known to be bad is it blocked.

The whitelist approach isn’t perfect either. This is the inverse of blacklisting, where everything is blocked by default unless it’s on a list approved inputs or actions. This might be easiest to think of as analogous to a list at an exclusive club or restaurant. With the whitelist approach only people with their name on the list are allowed in, while all others are turned away. The blacklist approach turns away anyone who is on a disallowed list, and lets everyone else in without discretion.

Here’s an example of one of the whitelists within ServerDefender’s controls. This particular example is not very permissive and shows how broad the controls can be.

Here’s an example of a blacklist in ServerDefender. This shows the specific resources that cannot be requested on a site, with all other resources being allowed.

The whitelist approach is inherently more secure, but more prone to false positives since the default action is block. However, our powerful and easy-to-use method for creating exceptions makes adding to whitelists entirely manageable.

Algorithmic Detection

We also look at a number of factors within a given user input and determines if there is an exploit contained in it. This is the algorithmic type of rule. It’s not based on a specific signature or set of signatures. Instead it looks for conditions that have to be met for a particular type of exploit to be effective, and blocks when those conditions are met. This makes it much more generic than signature based rules.

This does increase the false positive risk, so again, you do need good exception-management. This is something we built into ServerDefender in order to quickly loosen security controls for something very specific, while not compromising the overall security of the app. Plus, it is much more manageable to apply these occasional exceptions than to build up fully accurate whitelists field-by-field for an entire app, and keep them up to date as code changes.

Find the log for your false-positive by either entering the event ID, or filtering down to a specific set of parameters. Right-click and select ‘Add Input Exception’.

The add exception dialogue let’s you specify name, comment, what criteria to match, and the restrictions to make.

This allows errors to be broader or more generic (not signature matches but actual error states like 404s and 500s) because you’re not blocking on every single one. But if you track and build up a score or profile you can discern patterns that indicate misbehavior, even before anything that would match any actual threat ‘signature’ is thrown at the app. (e.g., too many ‘innocent’ looking errors from the same source, or with too great a frequency).

Philosophy

Signatures may make for a great business model, but they don’t make for a great security model. Signatures don’t account for unknown vulnerabilities, and are too easily bypassed in today’s world of advanced hackers. Our approach is and has always been to create tools that provide real security through algorithmic analysis and distrusting inputs.

If you have any questions about our approach to security, please feel free to reach out to our team. We’d love to chat!

No Comments »

Leave a Reply