Re: [mod-security-users] mod_security causing Apache 1.3.33 to ha ng

[Ivan R. <iv...@we...>]

Tom Anderson wrote:
> Ivan Ristic wrote:
>>> I think it would be extremely useful to be able to modify request
>>> content in this way rather than just flagging it.
>>
>>
>>   Perhaps, give me one real-life example where you would use it?
>>
> The present example of trying to prevent HTML injection in posts where
> user input is going to be displayed on a webpage, possibly by software
> that doesn't do proper sanitizing of its own.  Doing little-constrained
> wildcard matching like "<.+?>" is a recipe for potentially huge
> performance hits, plus it wholesale rejects user input that should
> otherwise be acceptable in an escaped format.

  There are two problems with data sanitisation if it is going
  to be performed on a web application firewall level:

  1. Transforming data from one format to another is not an operation
     that should be performed in this layer. Ideally, the application
     should be in possession of raw data and only transform it when
     the data needs to cross a system boundary. For example, move
     from the application into the database. If you choose to transform
     data sitting on the outside you can perform only one transformation,
     which only works when there is one system boundary.

  2. In a general case, the only way to really know how the data
     should be sanitised is to completely understand the application.
     You'd have to know where the data is flowing and how many
     system boundaries it is crossing. The current state of software
     development is that we are having hard time getting the average
     programmer to understand what they are doing ;) Web application
     firewalls are managed by system administrators and security
     people - I don't think it is realistic to expect them to
     be able to understand applications on a sufficient level.


> Doing something like the last two should not be all that difficult, as
> simple generic escape functions can be written and simply applied to the
> argument listed.  Just implementing SecFilterEscapeHTML ARG_BLOGPOST to
> replace SecFilterSelective ARG_BLOGPOST "<.+>" would both prevent lots
> of false positives (valid HTML discussions, etc) and measurably improve
> performance on moderately busy discussion forum or blog sites.  This is
> real security, not just a perception... replacing key symbols with their
> HTML escape codes can annihilate HTML injection, XSS, and scripting
> attacks with little overhead.

  Not in a general case. Depending on the application the "<" and ">"
  characters may not be necessary to perform an XSS attack. This happens
  for example, if the entry point for the intrusion is inside a tag
  already, or inside JavaScript code.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
Tel: +44 20 8141 2161, Fax: +44 87 0762 3934