Re: The document's address
FOURNEL Alexandre <[email protected]> Fri, 18 Jan 2013 13:51:24 +0100
| Newsgroups | gmane.comp.web.html.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-504-101678635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For more info on cache poisoning : = http://packetstorm.igor.onlinedirect.bg/papers/general/whitepaper_httpresp= onse.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 =95 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: >=20 >> On 17 January 2013 19:49, Ian Hickson <[email protected]> wrote: >>> On Wed, 21 Nov 2012, Nicholas Shanks wrote: >>>>=20 >>>> 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. >>>=20 >>> My understanding is that Content-Location is essentially dead: >>>=20 >>> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154 >>=20 >> That ticket says: >>=20 >> "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." >>=20 >>=20 >> 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: >>=20 >> POST /collection-uri >> { representation of new resource } >>=20 >> 201 Created >> Content-Location: /resource-uri >> { representation of created resource } >>=20 >> 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. >=20 > 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. >=20 > Search for "cache poisoning" for more explanation. >=20 >> But instead I have to do this: >>=20 >> POST /collection-uri >> { representation of new resource } >>=20 >> 303 Go Here >> Content-Location: /resource-uri >>=20 >> GET /resource-uri >>=20 >> 200 OK >> { representation of created resource } >>=20 >>=20 >> 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 >=20 > Not likely in either case, >=20 > ....Roy >=20 >=20 --Apple-Mail-504-101678635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">For = more info on cache poisoning : <a = href=3D"http://packetstorm.igor.onlinedirect.bg/papers/general/whitepaper_= httpresponse.pdf">http://packetstorm.igor.onlinedirect.bg/papers/general/w= hitepaper_httpresponse.pdf</a> (31 pages) or <a = href=3D"https://www.owasp.org/index.php/Cache_Poisoning">https://www.owasp= ..org/index.php/Cache_Poisoning</a><div><br></div><div><br></div><div><i>"T= o successfully carry out such an attack, an = attacker:<br></i><div><ul><li><i>Finds the vulnerable service code, = which allows them to fill the HTTP header field with many = headers.</i></li><li><i>Forces the cache server to flush its actual = cache content, which we want to be cached by the = servers.</i></li><li><i>Sends a specially crafted request, which will be = stored in cache.</i></li><li><i><div>Sends the next request. The = previously injected content stored in cache will be the response to this = request.<br></div></i></li></ul></div></div><div><i>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.<br>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."</i></div><div><i><br></i></div><div><br></div><div>Good = conversation so far, thanks!</div><div><div><br></div><div>-Alexandre = FOURNEL =95 Fire Starter!</div><div><br></div><div>-Connect with me = on:</div><div>LinkedIn: <a = href=3D"http://www.linkedin.com/in/alexandrefournel">http://www.linkedin.c= om/in/alexandrefournel</a></div><div>G+ <a = href=3D"https://plus.google.com/101679988447344945552/posts">https://plus.= google.com/101679988447344945552/posts</a></div><div><br></div><div>-Proje= cts:</div><div><a = href=3D"http://www.alexandrefournel.com">http://www.alexandrefournel.com</= a></div><div><a = href=3D"http://www.malea-massage.com">http://www.malea-massage.com</a></di= v><div><a = href=3D"http://www.malea.fr">http://www.malea.fr</a></div><div><br></div><= div><br></div><div><br><div><div>On 18 Jan 2013, at 13:23, Roy T. = Fielding wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>On Jan 18, 2013, at 3:46 AM, Nicholas Shanks = wrote:<br><br><blockquote type=3D"cite">On 17 January 2013 19:49, Ian = Hickson <<a href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">On Wed, 21 Nov 2012, Nicholas Shanks = wrote:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">The = definition of the document's = address:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a = href=3D"http://dev.w3.org/html5/spec/dom.html#the-document's-address">http= ://dev.w3.org/html5/spec/dom.html#the-document's-address</a><br></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">doesn't mention if the = Content-Location header should be taken into = account.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">My understanding is that = Content-Location is essentially = dead:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"> <a = href=3D"http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154">http://trac= ..tools.ietf.org/wg/httpbis/trac/ticket/154</a><br></blockquote></blockquot= e><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">That ticket says:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">"2) HTTP's = advice to set Content-Location when doing = server-driven<br></blockquote><blockquote type=3D"cite">content = negotiation results in links that are relative to a = negotiated<br></blockquote><blockquote type=3D"cite">resource, rather = than the desired (non-negotiated) URI."<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I find this is = a real pain and wish I could turn it off in Apache. = I<br></blockquote><blockquote type=3D"cite">only want Content-Location = to be present when I intend it to be, e.g I<br></blockquote><blockquote = type=3D"cite">want to do this:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">POST = /collection-uri<br></blockquote><blockquote type=3D"cite">{ = representation of new resource }<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">201 = Created<br></blockquote><blockquote type=3D"cite">Content-Location: = /resource-uri<br></blockquote><blockquote type=3D"cite">{ representation = of created resource }<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">and have caches = and the address in the browser's address bar use = the<br></blockquote><blockquote type=3D"cite">given Content-Location for = the representation returned, not use the<br></blockquote><blockquote = type=3D"cite">request URI.<br></blockquote><br>Which would be a security = hole if /collection-uri and /resource-uri<br>are controlled by different = owners. In practice, there is no way<br>for clients to know the = scope of resource ownership.<br><br>Search for "cache poisoning" for = more explanation.<br><br><blockquote type=3D"cite">But instead I have to = do this:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">POST = /collection-uri<br></blockquote><blockquote type=3D"cite">{ = representation of new resource }<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">303 Go = Here<br></blockquote><blockquote type=3D"cite">Content-Location: = /resource-uri<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">GET = /resource-uri<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">200 = OK<br></blockquote><blockquote type=3D"cite">{ representation of created = resource }<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">requiring an = extra round-trip and losing the semantics of a = 201<br></blockquote><blockquote type=3D"cite">response. If HTTP could be = changed so that content negotiation MUST<br></blockquote><blockquote = type=3D"cite">NOT cause C-L: header to be added, and HTTP software = patched to obey<br></blockquote><blockquote type=3D"cite">this, then = there may be scope in the future for requiring UAs = to<br></blockquote><blockquote type=3D"cite">display the = Content-Location rather than the request URI, once = servers<br></blockquote><blockquote type=3D"cite">have had their = software updated. HTTP 1.x may be a lost cause, = but<br></blockquote><blockquote type=3D"cite">there is still time to fix = it for 2.0<br></blockquote><br>Not likely in either = case,<br><br>....Roy<br><br><br></div></blockquote></div><br></div></div><= /body></html>= --Apple-Mail-504-101678635--