Message-ID: <CAKzwKJ8-+z96erPwf0e_vNDoxU7w9dk3qiU7orw7HdG2nU7ZVQ@mail.gmail.com>
Date: Wed, 20 Jul 2016 23:38:14 +0300
From: Elar Lang <elarlang@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] Reflected XSS in LinkedIn

Title: Reflected XSS in LinkedIn
Credit: Elar Lang / https://security.elarlang.eu
Vulnerability: Reflected XSS
Vendor: LinkedIn (https://www.linkedin.com/)


# Background

LinkedIn had reflected XSS vulnerability. It was at the end of 2013. I
made fulldisclosure now (middle of 2016) to point out and bring
attention to one frequent finding in pen-test cases: Request URI from
a client (browser) is expected to be always in correct URL encoding on
server side and it is not handled as potentially malicious user input.


# Preconditions

No pre-condition on authentication or on authorization to access this
functionality.

Browser: works only in Internet Explorer
Problem was in presenting Request Uri in HTML document. Most of
browsers automatically URL encode request URLs to correct URL encoding
and it's not possible for attacker to send HTML code to server. But
Internet Explorer URL encodes just space with %20 and nothing more.

More about this in blog post: "Request URI, Query String and URL encoding"
https://security.elarlang.eu/request-uri-query-string-and-url-encoding.html

So, limitations and restrictions in this case:
* Attacker can not use "space" in payload, because it's URL encoded to
%20. Basically, it is quite hard to write HTML - can not use HTML tags
with parameters
* Built in XSS filter in Internet Explorer. It may be possible to
bypass XSS filter, but I just don't know how;
* Some XSS filters in LinkedIn side (I don't remember details anymore)


# Proof-of-Concept

Usual context in HTML for vulnerable input was URL in JavaScript syntax.

Test request:
https://www.linkedin.com/profile/view?id=213160674&goback=123&trk=spm_pic_"></script><script>alert(1)</script>

Output: string "<script>alert(1)</script>" was presented 21 times in
output HTML document (image available in blog).

This payload works well in theory and it's easy to show the problem
using proxy. In practice, it will be blocked by Internet Explorer XSS
filter or URL encoded by other browsers.


# Demo payload for Internet Explorer

Structure for payload:
trk=spm_pic_"></script><myelem>XSS-is-here</myelem><style>myelem{CSS-is-HERE};</style><br"

Explanation:
"> - to end potential tag parameter and tag (not required, just for
better output)
</script> - usually user input ends up in script context. Finished
script to start new element
<myelem> - just random tag name not to fight with WAF and XSS filters
<style>myelem{CSS}</style> - it wasn't possible to use whitespace,
which means it wasn't possible to create style parameter for <myelem>
tag. But it was possible to create style tag and give styles to this
tag.
<br" - again just for better output

PoC URL (404 - this page does not exist anymore on that address):
https://www.linkedin.com/profile/view?id=213160674&goback=123&trk=spm_pic_"></script><myelem>XSS-is-here</myelem><style>myelem{color:red;font-size:40px;background-color:red;padding:30px;width:250px;display:block;color:white;};</style><br"

(Output image available in blog)


# Vulnerability Disclosure Timeline

2013-11-28 | me > LinkedIn | sent information about vulnerability
2013-11-28 | LinkedIn > me | confirmed vulnerability
2014-01-02 | LinkedIn > me | we fixed it, feel free to verify
2014-01-02 | me > LinkedIn | seems ok
2016-07-18 | me | Full Disclosure in blog


# Fixes

Vulnerability is fixed since 2014-01-02


# Blog

More detailed explanation with images available in blog:
https://security.elarlang.eu/reflected-xss-in-linkedin-in-2013.html

--
Elar Lang
Blog @ https://security.elarlang.eu
Pentester, lecturer @ http://www.clarifiedsecurity.com

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists