Re: The document's address

For more info on cache poisoning : http://packetstorm.igor.onlinedirect.bg/papers/general/whitepaper_httpresponse.pdf (31 pages) or https://www.owasp.org/index.php/Cache_Poisoning


"To successfully carry out such an attack, an attacker:
Finds the vulnerable service code, which allows them to fill the HTTP header field with many headers.
Forces the cache server to flush its actual cache content, which we want to be cached by the servers.
Sends a specially crafted request, which will be stored in cache.
Sends the next request. The previously injected content stored in cache will be the response to this request.
This attack is rather difficult to carry out in a real environment. The list of conditions is long and hard to accomplish by the attacker. However it's easier to use this technique than Cross-User Defacement.
A Cache Poisoning attack is possible because of HTTP Response Splitting and flaws in the web application. It is crucial from the attacker's point of view that the application allows for filling the header field with more than one header using CR (Carrige Return) and LF (Line Feed) characters."


Good conversation so far, thanks!

-Alexandre FOURNEL • Fire Starter!

-Connect with me on:
LinkedIn: http://www.linkedin.com/in/alexandrefournel
G+ https://plus.google.com/101679988447344945552/posts

-Projects:
http://www.alexandrefournel.com
http://www.malea-massage.com
http://www.malea.fr



On 18 Jan 2013, at 13:23, Roy T. Fielding wrote:

> On Jan 18, 2013, at 3:46 AM, Nicholas Shanks wrote:
> 
>> On 17 January 2013 19:49, Ian Hickson <ian@hixie.ch> wrote:
>>> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>>> 
>>>> The definition of the document's address:
>>>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>>>> doesn't mention if the Content-Location header should be taken into account.
>>> 
>>> My understanding is that Content-Location is essentially dead:
>>> 
>>>  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
>> 
>> That ticket says:
>> 
>> "2) HTTP's advice to set Content-Location when doing server-driven
>> content negotiation results in links that are relative to a negotiated
>> resource, rather than the desired (non-negotiated) URI."
>> 
>> 
>> I find this is a real pain and wish I could turn it off in Apache. I
>> only want Content-Location to be present when I intend it to be, e.g I
>> want to do this:
>> 
>> POST /collection-uri
>> { representation of new resource }
>> 
>> 201 Created
>> Content-Location: /resource-uri
>> { representation of created resource }
>> 
>> and have caches and the address in the browser's address bar use the
>> given Content-Location for the representation returned, not use the
>> request URI.
> 
> Which would be a security hole if /collection-uri and /resource-uri
> are controlled by different owners.  In practice, there is no way
> for clients to know the scope of resource ownership.
> 
> Search for "cache poisoning" for more explanation.
> 
>> But instead I have to do this:
>> 
>> POST /collection-uri
>> { representation of new resource }
>> 
>> 303 Go Here
>> Content-Location: /resource-uri
>> 
>> GET /resource-uri
>> 
>> 200 OK
>> { representation of created resource }
>> 
>> 
>> requiring an extra round-trip and losing the semantics of a 201
>> response. If HTTP could be changed so that content negotiation MUST
>> NOT cause C-L: header to be added, and HTTP software patched to obey
>> this, then there may be scope in the future for requiring UAs to
>> display the Content-Location rather than the request URI, once servers
>> have had their software updated. HTTP 1.x may be a lost cause, but
>> there is still time to fix it for 2.0
> 
> Not likely in either case,
> 
> ....Roy
> 
>