[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WAS Protect update
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]