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.

---

---

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.

 

We’ve been blind to attacks on our Web sites

I installed a Web application firewall in my company’s DMZ to tell us about active attacks that may not be identified by our other devices. I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on. I wanted to know more about what’s inside the connections to those Web servers.

What I discovered is that our Web sites are being “scraped” by other companies — our competitors! Some of the information on our sites is valuable intellectual property. It is provided online, in a restricted manner (passwords and such), to our customers. Such restrictions aren’t very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don’t know much about security. They make a token attempt to put passwords and restrictions on sensitive files, but they often don’t do a very good job.

 

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:

• Innovative Web Protection and Compliance 
• BIG-IP v10.1 Security [Slideshare Presentation]
• Excuse Me But Is That a Gazebo On Your Site?!
• Web Application Security at the Edge is More Efficient Than In the Application
• I Can Has UR .htaccess File
• Automatically Removing Cookies
• Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox
• Stop brute force listing of HTTP OPTIONS with network-side scripting
• Jedi Mind Tricks: HTTP Request Smuggling
• I am in your HTTP headers, attacking your application

read more

More: continued here

Technorati Tags: Featured, Web 2.0 Ajax Software

If you’re new here, you may want to subscribe to my RSS feed. Thanks for visiting Web 2.0 Portals!