Re: IPS Content filtering techniques

["Skough Axel U/IT-S" <axel.skough () scb se>]

The situation mentioned by you is an error as the Content-Type is improperly specified. 

I am not intedning to propagate for the bypass of erroneous packets! 

But in the situation when no content body is present, i e, specified by the Content-Length: 0, then the Content-Type 
may be excluded (according to RFC 2616) because there is no body to describe.

But the content-filtering implementations I've seen do not respect this special case and assume - following the RFC 
2616 - that the content type should be interpreted to be "application/octet-stream" as stated in RFC 2616 although no 
body is present! The "guessing" one can do in accordance with RFC 2616 in this case is that because no body is present 
then one doesn't worry about the content type, the content filtering can be bypassed in this situation or assumed to be 
whatsoever - it has no meaning when no body exists! 

So a bypass under these circumstances would be fully RFC 2616 compliant as far as I can understand! (Some Web servers 
pass a declared content type although no body is present, this is not an error as too much data not is formally 
prohibited, but generates unneccessary overhead).

Best regards and thank you very much for your cooperation! Let's see what other vendors may have to say! 

Axel


-----Original Message-----
From: firewall-wizards-bounces () listserv icsalabs com
[mailto:firewall-wizards-bounces () listserv icsalabs com]On Behalf Of
ArkanoiD
Sent: den 28 augusti 2007 23:39
To: Firewall Wizards Security Mailing List
Cc: Panahi Behzad U/IT-S
Subject: Re: [fw-wiz] IPS Content filtering techniques


But why does redirect have some content-type
other than text/html?

Well, i can fix my code by simply making content type check conditional
to existense of the response body. Is it ok for you?

On Tue, Aug 28, 2007 at 08:15:30AM +0200, Skough Axel U/IT-S wrote:
>  
> It is because some systems send informative responses indicating redirects (permanent or temporarily), HTTP code 301 
> or 302.
>  
> The ways these redirects are created vary strongly, sometimes a data buffer is given, but not always. The rediection 
> directive is present in a HTTP header statement indicating alternate location.
>  
> Some implementations omits declaring the data buffer content as none is present, thus the content is left unknown. A 
> content-filtering firewall therefore doesn't allow a HTTP packet with unknown data to pass - this is correct - BUT 
> should be able to allow HTT packets with no data, i e, Content-Length: 0. In this situation the Content-Type argument 
> can be properly excluded as stated in the RFC 2616 and we cannot therefore encourage the opinion that there should be 
> some error in such a packet from its vendor!
>  
> Best regards,
>  
> Axel
>
> ________________________________
>
> From: firewall-wizards-bounces () listserv icsalabs com on behalf of ArkanoiD
> Sent: Thu 2007-08-23 00:47
> To: Firewall Wizards Security Mailing List
> Cc: Panahi Behzad U/IT-S
> Subject: Re: [fw-wiz] IPS Content filtering techniques
>
>
>
> Well, what's the purpose of getting those null data through?
> Why do you need it?
>
> On Wed, Aug 15, 2007 at 03:35:24PM +0200, Skough Axel U/IT-S wrote:
> > Does really nobody know anything about a Web proxy product filtering on MIME Content-Type setting and capable to 
> > omit this check when the MIME Content-Length setting in force appears to be zero? The RFC 2616 states that the 
> > Content-Type header statement can be omitted in this situation and, indeed, it has no meaning as the data section 
> > is declared to be of length zero.
> >
> > Otherwise the data section should of course be in general be assumed to be of type "application/octet-stream" but 
> > when no data section is present it is obviously no problem in bypassing the Content-Type check! Thus, there are no 
> > data to prevent entering for in this situation, but the packet in force may have othre meanings such as redirect 
> > etc.
> >
> > I would appreciate any comments in this matter!
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards