Here I am going to give a brief write up about PDF XSS.
Amit Klien introduced a third kind of XSS attack-DOM Based XSS in which exploits client side vulnerabilities rather than Server Side flaws.He also observed how the # character can be used to, very conveniently, avoid sending attack payload to the server.DOM-based XSS typically uses JavaScript.Example (taken from Amit’s paper):
<HTML><TITLE>Welcome!</TITLE>Hi <SCRIPT>var pos = ocument.URL.indexOf("name=") + 5; document.write(document.URL.substring(pos,document.URL.length));</SCRIPT></HTML>
Exploiting PDF :Use the same technique using JavaScript it would execute it when a link in the following format is encountered:
http://www.example.com/file.pdf#a=javascript:alert()
Threats:
After a successful attack the code is executed in the context of the site that hosts the PDF file.
The attacker is in full control of the victim’s browser (think session hijacking, request forgery, etc.).
Individual users are fully compromised.System compromise is possible through escalation.
Fixing the problem:
In many ways this is a simple problem to solve.
Just upgrade the client-side software:Adobe Reader 8 not vulnerable.Internet Explorer 7 not vulnerable.
Alternatively, you can configure the browser not to open PDF files at all.But we know many users will not upgrade.
Not possible to detect attack on the server.Therefore our only option is to “protect” all PDF files no matter if they are being attacked or not.Proposed mitigation revolves around three ideas:Moving PDF files to some other domain name.Preventing browsers from recognising PDF files. (Some are very stubborn in this regard.)Forcing browsers to download PDF files.
Comments