WAS Protect update

[Ivan Ristic <ivanr@webkreator.com>]

I've taken the work one step further and created the attached
examples. This is not my first attempt. I tried other approaches
but this was the only one that could do the work while still
being reasonably easy to use.

Obviously, the examples are not 100% complete but the bulk
of functionality is there. The "edge" functionality is
missing: how to connect the signature to a WAS documented
vulnerability, and how to connect an event with the engine.

In my view Protect should only reference a vulnerability
already documented with Meta/Profile and provide signatures
for detection/protection. Also, the signature should not
decide on an action either. It is there only to report the
findings. So there are two use cases:

1. A signature is there to address a vulnerability, and
   it references it by its unique id. The user downloads
   relevant signatures based on system configuration and
   available meta data.

2. A user deploys a web protection engine that understands
   Protect signatures, and he/she writes custom signatures
   to protect some web application. We don't need to do
   much to support this, perhaps only add mechanisms to
   pass a message from a signature to the engine.

   These types of signatures will not exist in the
   database.

Some features mentioned in my first document are removed for
now or, in other words, left for future development phases.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



WORKFLOW
--------

1) Objects are created by the engine as data comes to
   the server.

2) Rule groups are executed at three different phases
   in request processing: beforeResponseProcess, beforeResponseSend,
   afterResponseSend.
   
3) Rules normally contain no metadata of their own, but instead
   use references to external data. If there are no external
   references rules can specify a message (severity is implicitely
   defined).
   
4) Rules generate three types of events: error (attack detected),
   warning (suspicious behavior), info (worth noting). It is
   up to engines to decide what to do, whether or not to take
   any actions and what exactly to do.


OBJECT HIERARCHY
----------------

_server
	server_software
	server_name
	server_port

_connection
	remote_addr
	remote_host

_request
	request_line	
	path_info
	path_translated
	script_name
	auth_type
	remote_user
	remote_ident
	body
	method
	uri
	version
	query_string
	content_length
	content_type
	headers[]
	params[]
	cookies[]
	http_headername (to access header headername, compatibility with CGI)

_response
	status_line
	status
	headers[]
	body
	content_length
	content_type
	
Variables with names beginning with _ are
not to be used in scripts.


LANGUAGE CONSTRUCTS
-------------------

<if op="operand" arg1="..." arg2="...">
	...
	<else/>
	...
</if>

<for index="i" from="1" to="10" step="2">
	...
</for>	

<foreach list="${_request.params}" as="param" index="i">
	...
	<continue/>
	...
	<break/>
	...
</foreach>

<goto id="..."/>

<gosub id="..."/>

<return/>

<error/>

<warning/>

<info/>

<setVar name="..." value="..." />

<unsetVar name="..." />


FUNCTIONS
---------

strlen

count

exists


EXAMPLE CONFIGURATION
---------------------

<ruleGroup id="..." invokeOn="beforeResponseProcess">

	<!-- Allow admin login from the local network only -->
	<ruleset id="100">
		<if op="eq" arg1="${_request.params['username']" arg2="admin">
			<setvar name="is_admin" value="1"/>	
		</if>

		<if op="ipin" arg1="${_request.remote_addr}" arg2="192.168.0.9/32">
			<fatal/>
		</if>
	</ruleset>

	<!-- Check for XSS attacks but allow certain parameters -->
	<ruleset id="101">		
		<foreach list="${_request.params}" as="param" index="i">
	
			<!-- Ignore parameters whose names start with "html_" -->
			<if arg1="${param}" arg2="^html_">
				<continue/>
			</if>
		
			<!-- Check parameters for XSS attacks -->
			<if arg1="${_request[param]}" arg2="<[:space:]*>">
				<warning .../>
			</if>
		
		</foreach>			
	</ruleset>

	<!-- Allow no more than ten parameters -->
	<ruleset id="102">
	
		<!-- default normalization functions are applied by the engine
		     unless a ruleset explicitely defines which functions it
		     wants applied -->
		     
		<normalization>
			<normalizationFunction1/>
			<normalizationFunction2/>
		</normalization>
	
		<if op="gt" arg1="${count(_request.params)} arg2="10">
			<fatal/>
		</if>
	</ruleset>
	
</ruleGroup>

<ruleGroup invokeOn="beforeResponseSend">
	<!-- Rules to be invoked before the response is
	     sent back to the client -->
</ruleGroup>

<ruleGroup invokeOn="afterResponseSend">
	<!-- Rules to be invoked after the response is
		 sent back to the client -->
</ruleGroup>