Universal XSS in Rekonq inherited from QtDemoBrowser?

[Tim Brown]

Please see https://bugs.kde.org/show_bug.cgi?id=217464, specifically the description and comment #2. Essentially, Rekonq and QtDemoBrowser quote unresolvable/unaccesible URLs verbatim in their error message. For sites that set wildcard domain'd cookies (for example Twitter) these can be stolen by requesting a web page such as http://thisdomainwillnotresolveandrekonqerrorpagewillbeshownwithfullurlembedded.twitter.com/"><script>alert(document.cookies)</script>.

[Tim Brown]

This was also reported as http://bugreports.qt.nokia.com/browse/QTWEBKIT-22 and closed by one of the Trolls with a request to resubmit here.

[Tor Arne Vestbø]

Please follow the QtWebKit bug reporting guidelines when reporting bugs.

See http://trac.webkit.org/wiki/QtWebKitBugs

Specifically:

  - The 'QtWebKit' component should only be used for bugs/features in the
    public QtWebKit API layer, not to signify that the bug is specific to
    the Qt port of WebKit

      http://trac.webkit.org/wiki/QtWebKitBugs#Component

  - Add the keyword 'Qt' to signal that it's a Qt-related bug

      http://trac.webkit.org/wiki/QtWebKitBugs#Keywords

[Robert Hogan]

The QtDemoBrowser is not part of QtWebKit. QtLauncher does seem to suffer from this problem though, as it uses the string reported to ErrorPageExtension for reporting errors.

ErrorPageExtension uses the failingUrl() and localizedDescription() ResourceError passed by QNetworkReplyHandler:

        if (httpStatusCode) {
            ResourceError error("HTTP", httpStatusCode, url.toString(), m_reply->attribute(QNetworkRequest::HttpReasonPhraseAttribute).toString());
            client->didFail(m_resourceHandle, error);
        } else {
            ResourceError error("QtNetwork", m_reply->error(), url.toString(), m_reply->errorString());
            client->didFail(m_resourceHandle, error);
        }
So these strings look to be unsanitized. I guess this could be done in ResourceError's Qt-specific constructor in platform/qt/ResourceError.h.

[Tor Arne Vestbø]

I can reproduce this in the QtLauncher. Exactly which URL did you type into the location field?

If we're somehow parsing http://foo.com/some-html-content into a valid URL and then end up also injecting that as page content at some point I'd say we need to look at the URL parsing and see if that makes sense first. If that URL is valid then I'm guessing this would be a problem in other places too?

[Robert Hogan]

(In reply to comment #4)
> I can reproduce this in the QtLauncher. Exactly which URL did you type into the
> location field?
> 
Do you mean 'can't'?

I wasn't able to reproduce myself - like you, not exactly sure what to enter as the url so just browsed the code for evidence of sanitizing urls. You're right that the problem may well be in the urls that are accepted for navigation.

> If we're somehow parsing http://foo.com/some-html-content into a valid URL and
> then end up also injecting that as page content at some point I'd say we need
> to look at the URL parsing and see if that makes sense first. If that URL is
> valid then I'm guessing this would be a problem in other places too?

[Robert Hogan]

Just downloaded rekonq and reproduced the problem there. The url is as quoted in the bug report and can't be reproduced in QtLauncher which simply reports 'host http not found' no matter how you try to mung the html content in the url.

Closing as invalid