posted on Monday, November 23, 2009 3:58 AM
The long, lost application delivery spell compendium has been found! Its once hidden, arcane knowledge is slowly being translated for the good of all web applications. Luckily, you don’t have to be Elminster or Gandalf or <insert powerful wizard you know here> to cast this spell over your infrastructure
Detect Invisible (Application) Stalkers 
School of Magic: Abjuration (Protective Spells)
Components: Somatic (requires gestures), Material (requires physical component)
Casting Time: special
Range: Layers 3-7
Area: global
Duration: Until discharged
Saving Throw: Special
Spell Resistance: No
Invisible (application) stalkers are creatures native to the Internet. They sometimes serve miscreants, corporate spies, and script kiddies, who summon them to perform attacks against specific targets. A summoned invisible stalker undertakes the form of a legitimate application request, pretending to be a real user, and will tirelessly undertake whatever task the caster commands, even if the task sends packets hundreds or thousands of miles away. The creature follows a command until the task is completed and obeys only the caster.
Invisible (application) stalkers operate only at layer 7 and eschew the use of forms commonly recognized as being of evil intent. Thus an invoke firewall log spell will show only multiple requests over time from similar agents, and intrusion detection spells have no effect on the creatures. Only a detect invisible (application) stalker spell can recognize and subsequently dismiss these agents of evil.
This spell inserts into the path of the invisible (application) stalker a wall which cannot be avoided, blocking them or reporting to the caster their proximity, as determined by the caster. The material component for this spell is a web application firewall, which must be placed between the invisible (application) stalker and its intended target. The somatic component requires the caster to complete a series of mouse clicks and keyboard strokes that deploy an application security policy including the ability to prevent web scraping. The casting time for this spell varies based on the complexity of the existing environment, and how many victims are being targeted by the invisible (application) stalkers.
Once completed, the spell will last until the caster discharges it by disabling the policy created by the somatic gestures.
The invisible (application) stalker may attempt a saving throw (Will) to realize it is being blocked. If it makes the save, it may attempt to figure out how the wall is blocking it. It must then make a second Will save or discorporate immediately. If the spell is cast as a reporting only mechanism, there is no saving throw allowed and the invisible (application) stalker will never be aware it has been detected.
THE FIRST STEP IN ANY SOLUTION IS ALWAYS RECOGNIZING THERE IS A PROBLEM
There are a few attacks today that just can’t be detected by applications.
Layer 7 DoS can’t be detected from within an application because the code that executes does so in the context of a
single request and a DoS implies many requests from many sources. The only way for a developer to detect this attack is to be able to view the single request that is typical of an application in the context of
all requests across
all instances of the application – even across machines – and that’s simply not possible from within the application.
Similarly, web scraping attacks are nearly impossible for a developer to detect because there is nothing in the request that would indicate anything is out of the ordinary. Nothing. No special code, no special characters, no odd manifestations within the headers or network data. In order for the developer to detect such an attack s/he would need to be able to determine whether the client is manned by a human being or is a script/bot. And no, using User-Agent headers isn’t going to work on this one because miscreants have figured out that too many security devices are able to block their attacks based on that value and thus have learned to circumvent it by scripting real browsers or manipulating the HTTP headers such that their bots/scripts appear to be valid user-driven browsers.
But that’s what a web application firewall (WAF) was designed to do: to watch, to evaluate requests in context, across all instances and all requests. It has the visibility, it has the capability, and it can detect attacks that are not easily if at all detected from within the application. Even if the WAF isn’t blocking the attacks, it can at least tell you they are happening, which is something the developers need to know if they’re going to put in place solutions to prevent them.
“Security manager, ‘J.F. Rice,’ whose name and employer have been disguised for obvious reasons” explains his need to “see” inside connections and understand what is happening in his environment.
Web application security requires visibility as well as the expected defensive capabilities. A web application firewall can provide both capabilities even though you may not leverage both at the same time or at all. Using a WAF as a mechanism to determine what kind of attacks are being directed at your web applications is just as valuable a proposition as enabling its preventative capabilities.
Either way, knowing is the first step to moving forward on a strategy to address it.
Related blogs & articles:
Technorati Tags:
MacVittie,
F5,
web application security,
security,
web 2.0,
web scraping,
ASM,
web application firewall,
WAF,
D&D,
ADSB
