[prev in list] [next in list] [prev in thread] [next in thread] 

List:       websecurity
Subject:    Re: [WEB SECURITY] Header Injection Prevention
From:       Prasad N Shenoy <prasad.shenoy () gmail ! com>
Date:       2011-01-17 1:52:07
Message-ID: 9F864EDD-1F19-4050-8BAA-2D3226D0FE60 () gmail ! com
[Download RAW message or body]

What about proxies with SSL accelerators or similar technologies that un-ssl, inspect \
and re-ssl the packets? Same bucket I guess?

Sent from my iPhone

On Jan 16, 2011, at 2:44 PM, PortSwigger <mail@portswigger.net> wrote:

> One potential caveat to this statement, which occurred to me later, applies to any \
> reverse proxies that are employed within the application's own hosting \
> infrastructure. If a reverse proxy resides behind an SSL terminator, and performs \
> caching, then it may be a valid target for cache poisoning attacks, and would \
> likely be affected by any header injection vulnerabilities within the application. 
> Cheers
> PortSwigger
> 
> 
> On 16 Jan 2011, at 14:54, nagiosnagios nagios wrote:
> 
> > Hi List
> > 
> > According to  "Web application Hacker's Handbook", Page 438
> > 
> > *"If it is considered unavoidable to insert user-controllable data into
> > HTTP headers, the application should employ a twofold defense-in-depth
> > approach to prevent any vulnerabilities arising:*
> > *■■ Input validation — The application should perform
> > context-dependent validation of the data being inserted, in as strict a
> > manner as possible. For example, if a cookie value is being set based on
> > user input, it may be appropriate to restrict this to alphabetical
> > characters only, and a maximum length of six bytes.*
> > *
> > *
> > *■■ Output validation — Every piece of data being inserted into
> > headers should be filtered to detect potentially malicious characters. In
> > practice, any character with an ASCII code below 0x20 should be regarded
> > as suspicious, and the request should be rejected. *
> > *
> > *
> > *Applications can prevent any remaining header injection
> > vulnerabilities from being used to poison proxy server caches by using HTTPS
> > for all application **content. "*
> > 
> > 
> > How does using HTTPS prevents header
> > injection vulnerabilities from poisoning proxy cashes?
> > 
> > Thanks
> > Josh
> 
> 
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives: 
> http://www.webappsec.org/lists/websecurity/archive/
> 
> Subscribe via RSS: 
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 
> To unsubscribe email websecurity-unsubscribe@webappsec.org and reply to 
> the confirmation email
> 
> Join WASC on LinkedIn 
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> WASC on Twitter
> http://twitter.com/wascupdates
> 

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

To unsubscribe email websecurity-unsubscribe@webappsec.org and reply to 
the confirmation email

Join WASC on LinkedIn 
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates


[prev in list] [next in list] [prev in thread] [next in thread]