[noize]

Cross Site Scripting

XSS (Cross Site Scripting) is a form of code injection, i.e. the introduction of code in an already built application.

Let's pretend a page's source code is:

PHP Code:

<form method="post" action=""> Enter your name: <input type="text" name="text" /><br> <input type="submit" name="submit" /> </form> <br><br> <?php echo $_POST['text']; ?>

This script would just take the input from a textbox and output it. If there is no control on the user input, the user could enter:

Code:

<span style="color: red;">red text</span>

This way, the script wouldn't just return "red text", but "red text" instead.

This way, we're introducing our own codes in the page. But we're just changing the color of two words, if correctly exploited this vulnerability might take to even great damage for the website (i.e. defacement, redirection, users infection).

There are two main categories of XSS:
- persistent (or stored, sometimes called also passive);
- non persistent (and reflected, also called active).

Persistent XSS vulnerabilities are the less common and the most remarkable. Let's say we have a comment page, comment.php, which shows all comments by all guests and lets you enter your own. You might enter:

Code:

<script>alert('Yet visited www.hackcommunity.com today?')</script>

and anyone who visited comment.php would have found a message box shouting "Yet visited www.hackcommunity.com today?".

We could redirect anyone visiting the page to http://www.example.com with this code:

Code:

<script>document.location("http://www.example.com")</script>

If http://example.com/ was a drive-by page, many of the users who accessed it would have downloaded a file they didn't want to download, and in the case the file was malicious, they'd have got infected.

* Note: Java drive-by download: a download where the user is either unconscious of being downloading a file or unconscious of what he's downloading, i.e. a forced download.

Let's take the example of a search engine instead. Our page is search.php and when we search for something we get redirected to search.php?for%20something. We might enter:

Code:

<script>alert('xss')</script>

and get a message box saying "xss". However, anyone visiting search.php will not read "xss" as long as it has not been stored like in a guestbook or comment page. In fact, to find it we need to visit search.php?<script>alert('xss')</script>.

Now what is reflected XSS? Some people consider only reflected XSS as non-persistent XSS and, thus, they consider them the same thing. Actually, the example of non-persistent XSS we've just seen didn't show "xss" to anyone else than us, but what if we sent to Little Bobby Tables a link red'ing to website.com/search.php?<script>alert('xss')</script> ? Then, Bobby would see a message box right from the website. This is called reflected XSS.

The reason why most do not even consider non-reflected non-persistent XSS is that only the one found it can see it, and hence it is worthless.

How to prevent XSS?

In PHP, there are in-built functions like htmlentities() or htmlspecialchars(). Let's hand back the same vulnerable script as above using htmlentities():

PHP Code:

<form method="post" action=""> Enter your name: <input type="text" name="text" /><br> <input type="submit" name="submit" /> </form> <br><br> <?php echo htmlentities($_POST['text']); ?>

htmlentities() translates special HTML characters into HTML entities. For instance, the left angle bracket (<) gets translated into &lt;. When we output this HTML entity, it appears as "<". Now, let's say the user entered:

Code:

<script>alert('xss')</script>

On the screen, he would have seen "<script>alert('xss')</script>".

Cross Site Request Forgery

CSRF (pronounced as C-surf (see-surf) or even C-S-R-F (see-as-ar-ef), sometimes also XSRF) stands for Cross Site Request Forgery. It is basically the forgery of a URL based upon the fact that, when the victim will follow it, he will request something to the server even if not willing to.

Let's take a simple example of CSRF. Most dynamical websites have a logout.php page, which destroys cookies, sessions and logs out the user without asking any further input, supposing that the user has clicked some "logout" link. This won't cause any remarkable trouble, as, even in the case this gets used in a CSRF attack, it won't do any damage but merely log out the user.

A practical example: you give a user a link taking to http://facebook.com/logout.php . Willing or not, the user would be logged out of Facebook when he follows it.

This is not a damageful example of CSRF'ing, but let's take the case of a bank (http://mybank.com/). When you choose to transfer money to another account, e.g. Maggie's account, you get redirected to http://mybank.com/donate.php?account=maggie&money=100 . You just donated 100 dollars to Maggie. Maggie, though, is not satisfied yet, and she gives you a link redirecting to http://mybank.com/donate.php?account=maggie&money=100 . Maggie just stole from you 100 dollars.

CSRF might be very dangerous (e.g. cookie-stealing) as well as XSS (e.g. cookie stealing, malware spreading, phishing).

* Didn't you want to know? You could steal login credentials by either stealing cookies, phishing or spreading malware.

CSRF is preventable by applying strict checks on user input, maybe asking for the password before accesing or changing important data and avoiding GET methods for such actions as the aforementioned.

POST methods are not enough safe either, anyway. You could easily upload an HTML page sending a POST request to the URL you want and give the URL to this page to the victim. When the victim follows it, he will send a request to the target webserver like if it was sent from his account (in case he is currently logged in).

[Solixious]

It is a nice thread. I could suggest a little more details in CSRF section and addition of ways of preventing XSS and CSRF attacks.
Cheers

[noize]

It is a nice thread. I could suggest a little more details in CSRF section and addition of ways of preventing XSS and CSRF attacks.
Cheers

Thanks, I will be adding that in a few days.

Edit: update: added more about CSRF and how to prevent both. Will be adding more.

[OctopusPopsicles]

Thank you for the post. Good basics about XSS and CSRF.

[OctopusPopsicles]

Thank you for the post. Good basics about XSS and CSRF.

[deb0and]

To prevent just add a pseudorandom value and set it as a cookie on the user's machine. Every form submission should include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value.

[deb0and]

To prevent just add a pseudorandom value and set it as a cookie on the user's machine. Every form submission should include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value.

[noize]

To prevent just add a pseudorandom value and set it as a cookie on the user's machine. Every form submission should include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value.

I'm sorry to say no.

[noize]

To prevent just add a pseudorandom value and set it as a cookie on the user's machine. Every form submission should include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value.

I'm sorry to say no.