1 / 10

XSS Without the Browser

Toorcon Seattle, 2011. XSS Without the Browser. Wait, what?. # whoami. Kyle Osborn…. Many know me as Kos. http:// kyleosborn.com / http:// kos.io / @ theKos Application Security Specialist at WhiteHat Security. HTML Rendering Engines. Trident – Windows (Internet Explorer)

Télécharger la présentation

XSS Without the Browser

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Toorcon Seattle, 2011 XSS Without the Browser Wait, what?

  2. # whoami • Kyle Osborn…. Many know me as Kos. • http://kyleosborn.com/ • http://kos.io/ • @theKos • Application Security Specialist at WhiteHat Security

  3. HTML Rendering Engines • Trident – Windows (Internet Explorer) • Webkit – OS X (Safari) • Easily embedded. • Easy to update, add features, style, and include advanced user interaction with HTML, JavaScript and CSS. • HTML5 features offer a more seamless desktop interface. • Very Cheap! HTML/JavaScript/CSS are simple.

  4. What does this mean? Web vulnerabilities…In Desktop Applications Conventional web vulnerabilities can now become desktop vulnerabilities. Forget shellcode, my payload is JavaScript! My exploit isn’t a buffer overflow, it’s double-quotes! Binary foo? More like “I once made a website for Grandma’s knitting company”-foo. Fixed in latest versions of Skype >= 5.0.922

  5. So what, it’s just a little JavaScript! Same Origin Policy But…. The Same Origin Policy is based on an Origin. What is the “origin” inside desktop applications? No protocol No hostname No Port So… • Dictates that JavaScript can not reach content in another context. • Origin based on: • Protocol (http, https) • Hostname (google.com) • Port (:80) • protocol://hostname:port/

  6. Demo #1 (or video…) [picking on Skype] • Payload: • Injects an iframe with Google into the chat DOM. • Injects <imgsrc=x onerror=alert(document.domain)> into the iframe. • Uses Safari cookies and sessions in requests.

  7. Demo #2 (or video…) [picking on Skype] • Payload: • XmlHttpRequest opens file:///etc/passwdand then alerts it • Can access any files on the local filesystem that the user has permission to read. • Also works for https://mail.google.com/ • Can be used to bypass CSRF tokens and requests can be crafted to essentially do anything.

  8. Basically… If Origin = null… then BAD • If the “origin” doesn’t exist, what is there to compare to? • Since http://www.google.com:80/ === null JavaScript isn’t really breaking an rules • As far as I can tell, just a misconfiguration on the developers side. My point is: The outcome can be very bad, applications like this should be tested.

  9. Where to look OS X Windows/Linux gwibber(Linux twitter client) AIM …there has got to be more • Adium • iChat • Twitter.app • Skype • …..

  10. Information • Talk to me later. I’ll be around for the parties, and Black Lodge tomorrow. • http://kos.io/skype (will be updated with slides and more info) • Twitter @theKos • Blog coming soon @ http://blog.whitehatsec.com

More Related