Response Processors

The processors in this section are responsible for issuing the various counter responses to malicious users on a server protected by WebApp Secure. A response is activated when WebApp Secure believes intervention is required between the profiled user and the webserver. This response can manifest into any of the types fully explained below.

Response Methodology: When WebApp Secure believes a response is required, the type of response issued depends on the type of behavior the malicious user exhibited to receive the response. For example, users that WebApp Secure think are automated tools will likely get issued a CAPTCHA response, whereas it is obvious that a real malicious user (not a bot) will be able to solve a CAPTCHA. In the second case, adding a 2 to 6 second slow might be more effective at wasting the hacker's time. Another factor that comes into play when issuing counter responses is risk level. If WebApp Secure believes a user is of no immediate risk to the system, it might only activate those responses which still allow the user to browse the site somehow, such as the Warning response or Slow Connection response. This way, WebApp Secure can monitor that user and gather additional information to properly assess their risk level. If WebApp Secure believes the user is a danger to the system, it will issue a more severe response, such as stripping out all inputs on every request or outright blocking the profile. Some responses might not get issued right away. For example, an incident can produce "a permanent block in 20 minutes". The reason for this delay in the counter response is that WebApp Secure uses this buffer time to gather some last-minute information on the profile before issuing the final response. WebApp Secure will respond instantly if it perceives immediate threat to the integrity of the system, but instances where this is not the case allow WebApp Secure to profile the attacker for a bit longer. The end result will be a more complete look at the attacker and his/her habits.

Types of Responses: Certain response processors are self-explanitory, such as the Block Processor (the user will see that they are blocked). Other responses are "invisible" in that there are no manifestations of the response visible to the user. An example of an invisible response processor is the Strip Inputs Processor. This processor will simply Block Processor 125 remove all values from all inputs on any form submitted because WebApp Secure has determined that the user's input can no longer be trusted. On the user-end, they will see nothing that will indicate to them that this response is active (until they figure out that all inputs are not being recognized).

Response Activation: Responses get automatically activated according to rules set forth within WebApp Secure. These rules are outlined for each incident a user can trigger, and are described in the documentation for each processor. The default response for each incident is documented in the User Guide, and will look something like, "Default Response: 1x = Warn User. 2x = 1 Day Block". The '1x' or '2x' indicate the number of incidents of that type triggered. For this example, triggering this incident once results in the Warning Processor being activated. If the same incident is triggered again on the same profile, the user then gets a 1 day block through the Block Processor.

Note: You might want to disable automatic counter responses entirely. If this is the case, changing the configuration parameter Auto Response Activation Enabled to False will prevent any new automatic activations, but will not hinder your ability to manually activate responses on profiles. (Configuration > Global Configuration > Auto Response Service > Auto Response Activation Enabled = False)

Compounding and Overriding Responses

Captcha overrides:

Strip Inputs overrides: