[Development] Newlines in XHR / QNetworkAccessManager headers

[Thiago Macieira]

On domingo, 7 de outubro de 2012 21.23.53, Mikko.Saario at nokia.com wrote:
> That's one debatable issue, but perhaps there is another more interesting
> case (at least in my opinion). I can also add newlines ("\n" or "\r\n") and
> thus spoof any header, even without that all-caps shouting. This time I
> added the new stuff (still in QML + JS) into the value side of the header
> (also works on the Header part, but then it's all caps [which I suppose
> should not make a difference really]) (interestingly, this attack vector
> did not succeed when I tried supplying malicious input via QML TextInput,
> as the newlines were printed as "\n" [which is good - a header value
> something\nReferer:abc is of no use for an attacker]):
> 
> 
> 
> xhr.setRequestHeader("Origin","http://www.google.fi\nReferer:http://www.goog
> le.fi/whatever<http://www.google.fi/nReferer:%20http:/www.google.fi/whatever
> >");
> 
> and this results on the HTTP ===>
> 
> ORIGIN: http://www.google.fi
> Referer: http://www.google.fi/whatever

This looks like a bug. First of all, QNAM should do something about it, so 
that the newline is correctly escaped -- if there's such a thing as escaped 
newlines. If there isn't such a thing, we might have to add to the 
documentation that the behaviour is undefined.

As for accessing this from untrusted sources, like JS scripts running on web 
pages, WebKit should do the validation. If it doesn't do that, it's a security 
issue.

> Small bug or something else?

If you find that it's a security issue, contact us at security at qt-project.org 
so we can deal with it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121007/5193adfa/attachment.sig>