Pasar al contenido principal

2013-003: XSS vulnerability in LinkedIn

2013-003: XSS vulnerability in LinkedIn

Original release date: March 3rd, 2013
Last revised:
March 10th, 2013
Discovered by:
Vicente Aguilera Diaz
4.3/10 (CVSSv2 Base Score)


LinkedIn is a social networking service and website ( for professionals. The site officially launched on May 5, 2003. As of September 30, 2012 (the end of the third quarter), professionals are signing up to join LinkedIn at a rate of approximately two new members per second.

Actually, Over 200 million professionals use LinkedIn to exchange information, ideas and opportunities.
More info:


Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites.

Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

LinkedIn is vulnerable to XSS attacks during a DWR (Direct Web Remoting, a Java open source library) call through the "c0-id" parameter.

There are several instances of this issue:


Next, we show a typical request to the "/ads/dwr/exec/SasAjax.validateCreative.dwr" resource:

     POST /ads/dwr/exec/SasAjax.validateCreative.dwr HTTP/1.1


Some parameters are not used/validated by the application, so we can remove these parameters from the request. The only parameters that are required by the application are:

     - callCount
     - JSESSIONID <== can have anything value, but must match the JSESSIONID
     - c0-id <== vulnerable parameter (we can inject HTML/script code through this parameter)
     - xml <== we need to change the value from "true" (default value) to "false" to make possible the script code injection

Also, we can use HTTP GET method instead the HTTP POST method used at this request. This makes it more easy the exploitation of the XSS vulnerability. For example, we can inject script code to show an alert popup with the "document.cookie" value:


So, finally, this HTTP request provoke the XSS exploitation:');<!--&xml=false


A malicious user can access to the information stored in the cookie on other users, so the attacker can spoof they identity and access to these user accounts.





March 3, 2013: Initial release


  • March 3, 2013: Vulnerability acquired by Internet Security Auditors.
  • March 11, 2013: Sent to Sec Team.
  • July 4, 2013: Initial vendor notification sent.
  • July 9, 2013: No update yet.
  • July 11, 2013: All issues reported should be resolved.


The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.


Internet Security Auditors is a Spain and Colombia based company leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.