[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WAS Protect
Hi all, I've finally managed to compile my notes on WAS Protect (and the HTTP server side protection in general). I also now have time in my schedule to work on this element - I expect we can have it completed in time. I can start and finish the work on my own but, for things like this, I prefer to have input from other people - it's always useful to consider various points of view. The document is a result of my work on mod_security, its limitations, analysis of other similar attempts, and various server side programming APIs. Mod_security limitations were particularly useful. In my opinion, WAS Protect should consist of a specification of an execution engine, with a data model and a (simple) programming language. The capabilities of the engine are specified in the document. I have the following concerns: 1) The scope of the effort On one level, WAS Protect can and should be used to protect from known and unknown threats. On the next language, it can also be designed to be a more generic server-side protection language, which people can use to secure their web servers and applications. I've done both for mod_security but generic protection may not make sense for WAS Protect. It would be cool but would it serve a purpose? Would anyone implement it? Personally, I prefer iterative development and wouldn't mind leaving the fancy stuff for later. Another thing to consider is that a simpler standard will be more likely to be accepted, or accepted faster. Some of the features mentioned in the document are an order of magnitude harder to implement. For example, stateful operation. This functionality is a good candidate for a later version. Stateful operation is necessary for these: * Detect brute force attacks * Session fixation detection * Session hijacking detection * IP address / user blacklisting 2) Overlap with WAS Test There's a large overlap in functionality between Test and Protect. Test creates requests, and analyses responses. Protect analyses requests, and responses, possibly creates responses. Therefore a single language should be used for both. From what I've seen, VulnXML cannot support Protect. So we need to resolve this issue. 3) The question of format XML is obviously the flavor of the day, for good reasons. But is it a good choice to store engine statements/instructions? XML is good for storage and parsing, but it's not very user friendly. And if we use XML it is unlikely anyone will want to write Protect by hand. Is having more than one representation a good way of solving this problem? PS. In case the attachment does not go through the email, I've uploaded it here: http://www.webkreator.com/download/was-protect-1.pdf -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]