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/