[Webkit-unassigned] [Bug 68560] New: [Qt] HTTP header injection vulnerability (QWebPage::userAgentForUrl)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=68560

           Summary: [Qt] HTTP header injection vulnerability
                    (QWebPage::userAgentForUrl)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Keywords: Qt
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jarred at sencha.com


Created an attachment (id=108210)
 --> (https://bugs.webkit.org/attachment.cgi?id=108210&action=review)
userAgentForUrl stripping

This is an interesting issue, that isn't any one particular tier's fault.

When working with PhantomJS (based on QtWebKit), where the user is able to provide their own user agent, we discovered that the user (or attacker?) can set the user agent in such a way to add another HTTP header implicitly to the ResourceRequest:

userAgent = 'My User Agent\nX-My-New-Header: oh noes!';

Which will result in sending the HTTP request w/ headers:

User-Agent: My User Agent
X-My-New-Header: oh noes!

Clearly, this could be problematic.  HTTPHeaderMap doesn't filter the values at all (relying on platform network stack?).  QNetworkRequest clearly just writes the headers onto the stream without a care.  This is either everyone's fault or no one's fault.  While XMLHttpRequest does a validity check of header values (to make sure they don't contain \r or \n) since it's a scriptable API, internal header management does not validate, falling back to the platform's network stack to handle it properly.  Though this is an edge case, QWebPage is offering to the consumer of the QtWebKit API the ability to set the user agent header and doesn't protect it.

Attached is a patch that does the obvious and strips out newline chars to protect this particular scenario, from within WebCore.  But, maybe some handling belongs in QNetwork as well, which would make this a temporary patch.  Or such behavior is acceptable in QNetwork, which means the validation should occur on a higher tier.

Input on this matter is welcomed!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.