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.
