Last week, I was asked to do a code review of a Single Page App built using the ASP.NET Web API, Durandal, and Knockout (good stuff!). In particular, I was asked to investigate whether there any special security issues associated with building a Single Page App which are not present in the case of a traditional server-side ASP.NET application.
In this blog entry, I discuss two areas in which you need to exercise extra caution when building a Single Page App. I discuss how Single Page Apps are extra vulnerable to both Cross-Site Scripting (XSS) attacks and Cross-Site Request Forgery (CSRF) attacks.
This goal of this blog post is NOT to persuade you to avoid writing Single Page Apps. I’m a big fan of Single Page Apps. Instead, the goal is to ensure that you are fully aware of some of the security issues related to Single Page Apps and ensure that you know how to guard against them.
Cross-Site Scripting (XSS) Attacks
According to WhiteHat Security, over 65% of public websites are open to XSS attacks. That’s bad. By taking advantage of XSS holes in a website, a hacker can steal your credit cards, passwords, or bank account information.
Any website that redisplays untrusted information is open to XSS attacks. Let me give you a simple example.
Imagine that you want to display the name of the current user on a page. To do this, you create the following server-side ASP.NET page located at http://MajorBank.com/SomePage.aspx:
<%@Page Language="C#" %>
<html>
<head>
<title>Some Page</title>
</head>
<body>
Welcome <%= Request["username"] %>
</body>
</html>
Nothing fancy here. Notice that the page displays the current username by using Request[“username”]. Using Request[“username”] displays the username regardless of whether the username is present in a cookie, a form field, or a query string variable.
Unfortunately, by using Request[“username”] to redisplay untrusted information, you have now opened your website to XSS attacks. Here’s how.
Imagine that an evil hacker creates the following link on another website (hackers.com):
<a href="/SomePage.aspx?username=<script src=Evil.js></script>">Visit MajorBank</a>
Notice that the link includes a query string variable named username and the value of the username variable is an HTML <SCRIPT> tag which points to a JavaScript file named Evil.js. When anyone clicks on the link, the <SCRIPT> tag will be injected into SomePage.aspx and the Evil.js script will be loaded and executed.
What can a hacker do in the Evil.js script? Anything the hacker wants. For example, the hacker could display a popup dialog on the MajorBank.com site which asks the user to enter their password. The script could then post the password back to hackers.com and now the evil hacker has your secret password.
ASP.NET Web Forms and ASP.NET MVC have two automatic safeguards against this type of attack: Request
Validation and Automatic HTML Encoding.
Protecting Coming In (Request Validation)
In a server-side ASP.NET app, you are protected against the XSS attack described above by a feature named Request
Validation. If you attempt to submit “potentially dangerous” content — such as a JavaScript <SCRIPT> tag — in a form field or query string variable then you get an exception.
Unfortunately, Request
Validation only applies to server-side apps. Request
Validation does not help in the case of a Single Page App. In particular, the ASP.NET Web API does not pay attention to Request
Validation. You can post any content you want – including <SCRIPT> tags – to an ASP.NET Web API action.
For example, the following HTML page contains a form. When you submit the form, the form data is submitted to an ASP.NET Web API controller on the server using an Ajax request:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<form data-bind="submit:submit">
<div>
<label>
User Name:
<input data-bind="value:user.userName" />
</label>
</div>
<div>
<label>
Email:
<input data-bind="value:user.
email" />
</label>
</div>
<div>
<input type="submit" value="Submit" />
</div>
</form>
<script src="Scripts/jquery-1.7.1.js"></script>
<script src="Scripts/knockout-2.1.0.js"></script>
<script>
var viewModel = {
user: {
userName: ko.observable(),
email: ko.observable()
},
submit: function () {
$.post("/api/users", ko.toJS(this.user));
}
};
ko.applyBindings(viewModel);
</script>
</body>
</html>
The form above is using Knockout to bind the form fields to a view model. When you submit the form, the view model is submitted to an ASP.NET Web API action on the server.
Here’s the server-side ASP.NET Web API controller and model class:
public class UsersController : ApiController
{
public HttpResponseMessage Post(UserViewModel user) {
var userName = user.UserName;
return Request.CreateResponse(HttpStatusCode.OK);
}
}
public class UserViewModel {
public string UserName { get; set; }
public string
Email { get; set; }
}
If you submit the HTML form, you don’t get an error. The “potentially dangerous” content is passed to the server without any exception being thrown. In the screenshot below, you can see that I was able to post a username form field with the value “<script>alert(‘boo’)</script”.
So what this means is that you do not get automatic Request
Validation in the case of a Single Page App. You need to be extra careful in a Single Page App about ensuring that you do not display untrusted content because you don’t have the Request
Validation safety net which you have in a traditional server-side ASP.NET app.
Protecting Going Out (Automatic HTML Encoding)
Server-side ASP.NET also protects you from XSS attacks when you render content. By default, all content rendered by the razor view engine is HTML encoded. For example, the following razor view displays the text “<b>Hello!</b>” instead of the text “Hello!” in bold:
@{
var message = "<b>Hello!</b>";
}
@message
If you don’t want to render content as HTML encoded in razor then you need to take the extra step of using the @Html.Raw() helper.
In a Web Form page, if you use <%: %> instead of <%= %> then you get automatic HTML Encoding:
<%@ Page Language="C#" %>
<%
var message = "<b>Hello!</b>";
%>
<%: message %>
This automatic HTML Encoding will prevent many types of XSS attacks. It prevents <script> tags from being rendered and only allows <script> tags to be rendered which are useless for executing JavaScript.
(This automatic HTML encoding does not protect you from all forms of XSS attacks. For example, you can assign the value “javascript:alert(‘evil’)” to the Hyperlink control’s NavigateUrl property and execute the JavaScript).
The situation with Knockout is more complicated. If you use the Knockout TEXT binding then you get HTML encoded content. On the other hand, if you use the HTML binding then you do not:
<!-- This JavaScript DOES NOT execute -->
<div data-bind="text:someProp"></div>
<!-- This Javacript DOES execute -->
<div data-bind="html:someProp"></div>
<script src="Scripts/jquery-1.7.1.js"></script>
<script src="Scripts/knockout-2.1.0.js"></script>
<script>
var viewModel = {
someProp : "<script>alert('Evil!')<" + "/script>"
};
ko.applyBindings(viewModel);
</script>
So, in the page above, the DIV element which uses the TEXT binding is safe from XSS attacks. According to the Knockout documentation:
“Since this binding sets your text value using a text node, it’s safe to set any string value without risking HTML or script injection.”
Just like server-side HTML encoding, Knockout does not protect you from all types of XSS attacks. For example, there is nothing in Knockout which prevents you from binding JavaScript to a hyperlink like this:
<a data-bind="attr:{href:homePageUrl}">Go</a>
<script src="Scripts/jquery-1.7.1.min.js"></script>
<script src="Scripts/knockout-2.1.0.js"></script>
<script>
var viewModel = {
homePageUrl: "javascript:alert('evil!')"
};
ko.applyBindings(viewModel);
</script>
In the page above, the value “javascript:alert(‘evil’)” is bound to the HREF attribute using Knockout. When you click the link, the JavaScript executes.
Cross-Site Request Forgery (CSRF) Attacks
Cross-Site Request Forgery (CSRF) attacks rely on the fact that a session cookie does not expire until you close your browser. In particular, if you visit and login to MajorBank.com and then you navigate to Hackers.com then you will still be authenticated against MajorBank.com even after you navigate to Hackers.com.
Because MajorBank.com cannot tell whether a request is coming from MajorBank.com or Hackers.com, Hackers.com can submit requests to MajorBank.com pretending to be you. For example, Hackers.com can post an HTML form from Hackers.com to MajorBank.com and change your
email address at MajorBank.com. Hackers.com can post a form to MajorBank.com using your authentication cookie.
After your
email address has been changed, by using a password reset page at MajorBank.com, a hacker can access your bank account.
To prevent CSRF attacks, you need some mechanism for detecting whether a request is coming from a page loaded from your website or whether the request is coming from some other website. The recommended way of preventing Cross-Site Request Forgery attacks is to use the “Synchronizer Token Pattern” as described here:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
When using the Synchronizer Token Pattern, you include a hidden input field which contains a random token whenever you display an HTML form. When the user opens the form, you add a cookie to the user’s browser with the same random token. When the user posts the form, you verify that the hidden form token and the cookie token match.
Preventing Cross-Site Request Forgery Attacks with ASP.NET MVC
ASP.NET gives you a helper and an action filter which you can use to thwart Cross-Site Request Forgery attacks. For example, the following razor form for creating a product shows how you use the @Html.AntiForgeryToken() helper:
@model MvcApplication2.Models.Product
<h2>Create Product</h2>
@using (Html.BeginForm()) {
@Html.AntiForgeryToken();
<div>
@Html.LabelFor( p => p.Name, "Product Name:")
@Html.TextBoxFor( p => p.Name)
</div>
<div>
@Html.LabelFor( p => p.Price, "Product Price:")
@Html.TextBoxFor( p => p.Price)
</div>
<input type="submit" />
}
The @Html.AntiForgeryToken() helper generates a random token and assigns a serialized version of the same random token to both a cookie and a hidden form field. (Actually, if you dive into the source code, the AntiForgeryToken() does something a little more complex because it takes advantage of a user’s identity when generating the token).
Here’s what the hidden form field looks like:
<input name=”__RequestVerificationToken” type=”hidden” value=”NqqZGAmlDHh6fPTNR_mti3nYGUDgpIkCiJHnEEL59S7FNToyyeSo7v4AfzF2i67Cv0qTB1TgmZcqiVtgdkW2NnXgEcBc-iBts0x6WAIShtM1″ />
And here’s what the cookie looks like using the Google Chrome developer toolbar:
You use the [ValidateAntiForgeryToken] action filter on the controller action which is the recipient of the form post to validate that the token in the hidden form field matches the token in the cookie. If the tokens don’t match then
validation fails and you can’t post the form:
public ActionResult Create() {
return View();
}
[ValidateAntiForgeryToken]
[HttpPost]
public ActionResult Create(Product productToCreate) {
if (ModelState.IsValid) {
// save product to db
return RedirectToAction("Index");
}
return View();
}
How does this all work? Let’s imagine that a hacker has copied the Create Product page from MajorBank.com to Hackers.com – the hacker grabs the HTML source and places it at Hackers.com. Now, imagine that the hacker trick you into submitting the Create Product form from Hackers.com to MajorBank.com. You’ll get the following exception:
The Cross-Site Request Forgery attack is blocked because the anti-forgery token included in the Create Product form at Hackers.com won’t match the anti-forgery token stored in the cookie in your browser. The tokens were generated at different times for different users so the attack fails.
Preventing Cross-Site Request Forgery Attacks with a Single Page App
In a Single Page App, you can’t prevent Cross-Site Request Forgery attacks using the same method as a server-side ASP.NET MVC app. In a Single Page App, HTML forms are not generated on the server. Instead, in a Single Page App, forms are loaded dynamically in the browser.
Phil Haack has a blog post on this topic where he discusses passing the anti-forgery token in an Ajax header instead of a hidden form field. He also describes how you can create a custom anti-forgery token attribute to compare the token in the Ajax header and the token in the cookie. See:
http://haacked.com/archive/2011/10/10/preventing-csrf-with-ajax.aspx
Also, take a look at Johan’s update to Phil Haack’s original post:
http://johan.driessen.se/posts/Updated-Anti-XSRF-Validation-for-ASP.NET-MVC-4-RC
(Other server frameworks such as Rails and Django do something similar. For example, Rails uses an X-CSRF-Token to prevent CSRF attacks which you generate on the server – see http://excid3.com/blog/rails-tip-2-include-csrf-token-with-every-ajax-request/#.UTFtgDDkvL8 ).
For example, if you are creating a Durandal app, then you can use the following razor view for your one and only server-side page:
@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<title>Index</title>
</head>
<body>
@Html.AntiForgeryToken()
<div id="applicationHost">
Loading app....
</div>
@Scripts.Render("~/scripts/vendor")
<script type="text/javascript" src="~/App/durandal/amd/require.js"
data-main="/App/main"></script>
</body>
</html>
Notice that this page includes a call to @Html.AntiForgeryToken() to generate the anti-forgery token.
Then, whenever you make an Ajax request in the Durandal app, you can retrieve the anti-forgery token from the razor view and pass the token as a header:
var csrfToken = $("input[name='__RequestVerificationToken']").val();
$.ajax({
headers: { __RequestVerificationToken: csrfToken },
type: "POST",
dataType: "json",
contentType: 'application/json; charset=utf-8',
url: "/api/products",
data: JSON.stringify({ name: "Milk", price: 2.33 }),
statusCode: {
200: function () {
alert("Success!");
}
}
});
Use the following code to create an action filter which you can use to match the header and cookie tokens:
using System.Linq;
using System.Net.Http;
using System.Web.Helpers;
using System.Web.Http.Controllers;
namespace MvcApplication2.Infrastructure {
public class ValidateAjaxAntiForgeryToken : System.Web.Http.AuthorizeAttribute {
protected override bool IsAuthorized(HttpActionContext actionContext) {
var headerToken = actionContext
.Request
.Headers
.GetValues("__RequestVerificationToken")
.FirstOrDefault(); ;
var cookieToken = actionContext
.Request
.Headers
.GetCookies()
.Select(c => c[AntiForgeryConfig.CookieName])
.FirstOrDefault();
// check for missing cookie or header
if (cookieToken == null || headerToken == null) {
return false;
}
// ensure that the cookie matches the header
try {
AntiForgery.Validate(cookieToken.Value, headerToken);
} catch {
return false;
}
return base.IsAuthorized(actionContext);
}
}
}
Notice that the action filter derives from the base AuthorizeAttribute. The ValidateAjaxAntiForgeryToken only works when the user is authenticated and it will not work for anonymous requests.
Add the action filter to your ASP.NET Web API controller actions like this:
[ValidateAjaxAntiForgeryToken]
public HttpResponseMessage PostProduct(Product productToCreate) {
// add product to db
return Request.CreateResponse(HttpStatusCode.OK);
}
After you complete these steps, it won’t be possible for a hacker to pretend to be you at Hackers.com and submit a form to MajorBank.com. The header token used in the Ajax request won’t travel to Hackers.com.
This approach works, but I am not entirely happy with it. The one thing that I don’t like about this approach is that it creates a hard dependency on using razor. Your single page in your Single Page App must be generated from a server-side razor view. A better solution would be to generate the anti-forgery token in JavaScript.
Unfortunately, until all browsers support a way to generate cryptographically strong random numbers – for example, by supporting the window.crypto.getRandomValues() method — there is no good way to generate anti-forgery tokens in JavaScript. So, at least right now, the best solution for generating the tokens is the server-side solution with the (regrettable) dependency on razor.
Conclusion
The goal of this blog entry was to explore some ways in which you need to handle security differently in the case of a Single Page App than in the case of a traditional server app. In particular, I focused on how to prevent Cross-Site Scripting and Cross-Site Request Forgery attacks in the case of a Single Page App.
I want to emphasize that I am not suggesting that Single Page Apps are inherently less secure than server-side apps. Whatever type of web application you build – regardless of whether it is a Single Page App, an ASP.NET MVC app, an ASP.NET Web Forms app, or a Rails app – you must constantly guard against security vulnerabilities.
