This is my take on CSRF and XSS.
Web search will find definitions like these:
CSRF : Exploits the website's trust of the user
XSS : Exploits the user's trust of the web application.
What does it actually mean? You will find more explanations but they are all vague. So here is my take on these two, do let me know if they make sense:
CSRF: Cross Site Request Forgery.
Before we actually talk about CSRF let’s talk a little background. Websites track their users by providing them with session ids in the form of cookies, special form fields or or some value in the urls. These uniquely identify each user to the web application, this is important for the following two reasons:
1- HTTP is a state less protocol - meaning each transaction is discreet and complete after which HTTP session is terminated - if unsure use wireshark to capture your HTTP traffic - actually I recommend that you do that. This means that when you request a page and you see "done" or 100 % somewhere on the status bar in your browser, indicating all data was transferred and all HTTP sessions were terminated. Thus there is no way for a web application to keep track of who made what request.
2 - However web applications want to provide you with the content you requested and in the context you requested(to overcome short coming of stateless HTTP). Meaning if you are an anonymous user so don’t get to see the privileged pages, if you are an authenticated user you get to see more and if you are an administrative user you get a lot more. So all this is tied to the session ids or cookies which track you and essentially establishes different levels of trust between you(or your browser) and the web application. Anonymous user no trust, normal authenticated user, some trust and administrative user, complete trust, etc, etc.
For the sake of simplicity I will keep my discussions to cookies as session identifiers. However as I have noted before they are not the only way a website can track user but they are most definitely the most common.
Now on the client side - your browser takes cares of cookie management, making sure that the correct session ids are passed to the correct websites. So that you can surf in peace, harmony and security, browsers work off the same origin policy - meaning if the request is originated from the same browser to a website(domain) for which it has the session id it will automatically append the relevant session cookies.
You want to see it work - for most application without any CSRF protection - if you copy a trusted link and open it another tab or windows of the same browser, it will take you to the original webpage(however this not always true - just an example). I am pretty sure you have done this a few times. If you are in an authenticated section of some website right click a protected link and select open in a new window. When you do this the browser automatically appends all the correct session data to the new window, because the new window has all the correct cookies the web application trusts the new window and displays the content. The web application notes that a browser with all the right session identifiers(cookies) is making a request. It has no way of knowing that the request is coming from two different browser windows (remember HTTP is stateless).
Attack Scenario: An attacker wants to gain access to a users profile. He deems that it can done by changing the users password on a site by first changing the secondary email in the profile tab - this is a very common security feature where by you can request a change of password by following the forgotten password link and entering the alternate email address which is already present in profile, where by receiving an alternate temporary password on the entered email address.
The attacker - who by way goes by the name of Dalek knows that this particular website feature is vulnerable to CSRF. To exploit that, the attacker uses a proxy to capture all the traffic the browser is sending out. Proxies are the first and the most important tool you will need if you thinking of testing web applications, Proxy essentially sits between your browser and the websites - all traffic goes through the proxy to the website and you have the ability to intercept and edit traffic on the fly.
We assume that the attacker also has access to the same website, pretty common - example webmail, social networking sites etc - all users have the same access rights more or less. To generate an actual attack page, the attacker changes his email and sends that request - but instead, catches the request in the proxy. He then looks at the request and I convert the request into an HTML page that would generate the request - fairly straight forward process if you know what you are doing - I wrote a script to do that - more on this later. The attacker then edits the page so as to include the target email.
Dalek - the attacker hosts this page somewhere - inviting a victim by suggesting that they visit the website to get coupons for chocolate covered marzipan. We assume that the victim is logged on to the vulnerable site when she receives this request from the attacker and she being a suckers for good marzipan clicks the evil link.
Since she is logged in to the vulnerable website, on clicking the link the will generate a request to change the email on the users profile. Browser will see that the request is generated for the vulnerable site and since victim - Rose is already logged, will perform this action, by automatically appending all the correct session information to the request and forwarding that request to vulnerable application and that’s about it - she just got CSRFed. So Rose unwilling perfomed an action in her context(websites trust).
Let us revisit the CSRF definition. Exploits the website’s trust of the user. Trust is established through session ids - The application trusts the session ids from the browser and that is how the attack works.
Mitigation - Use unique ephemeral tokens for each sensitive function on your web application.
Cross Site Scripting(XSS) ..... will have to wait for now.