Different applications have different artifacts that need protection, but all applications share something that needs protection. If you have a database in your application, that is the most important item to protect. If your application is a server-based application, the server should rate fairly high when you're determining what to protect.

Even if your program is just a little single-user application, the software should do no wrong — an outsider shouldn't be able to use the application to break into the user's computer.

If you think this section's title sounds similar to part of the design process, you're right. A lot of threat modeling is just understanding how the application works and describing it well.

First, describe what the application does. This description becomes a functional overview. If you follow the commonly accepted Software Development Life Cycle (SDLC), and then the use cases, requirements, or user stories document (depending on your personal methodology) should give you a good starting point.

Next, describe how the application accomplishes all those tasks at the highest level. A Software Architecture Overview (SAO) diagram is a useful way to do it. This diagram shows which machines and services do what in your software.

Sometimes the SAO is a simple diagram — if you have a standalone Windows Forms program like a game, that's all there is! A standalone program has no network connection, and no communication between software parts. Therefore, the software architecture diagram contains only one instance.

After you create a document that describes what the software is doing and how, you need to break out the individual functional pieces of the software. If you have set up your software in a component fashion, the classes and methods show the functional decomposition. It's simpler than it sounds.

The end result of breaking the software into individual pieces is having a decent matrix of which components need to be protected, which parts of the software interact with each component, which parts of the network and hardware system interact with each component, and which functions of the software do what with each component.

After you create the list of components that you need to protect, you tackle the tough part: Put two and two together. Identifying threats is the process that gets the security consultants the big bucks, and it's almost entirely a factor of experience.

For instance, if your application connects to a database, you have to imagine that the connection could be intercepted by a third party. If you use a file to store sensitive information, the file could, theoretically, be compromised.

To create a threat model, you need to categorize the potential threats to your software. An easy way to remember the different categories of threats is as the acronym STRIDE:

All these threats must be documented in an outline under the functions that expose the threat. This strategy not only gives you a good, discrete list of threats but also focuses your security hardening on those parts of the application that pose the greatest security risk.

The final step in the process is to rate the risks. Microsoft uses the DREAD model to assess risk to its applications. The acronym DREAD represents five key attributes used to measure each vulnerability:

You can research the DREAD model at msdn.microsoft.com/security, or position your threat model to consider those attributes. The key is to determine which threats are most likely to cause problems and then mitigate them.

To be straightforward, the best way for an application to authorize a user is to make use of the Windows login. A host of arguments take place about this strategy and others, but the key is simplicity: Simple things are more secure.

For much of the software developed with Visual Studio, the application will be used in an office by users who have different roles in the company; for example, some users might be in the Sales or Accounting department. In many environments, the most privileged users are managers or administrators — yet another set of roles. In most offices, each employee has her own user account, and each user is assigned to the Windows groups that are appropriate for the roles she plays in the company.

Building a Windows application to take advantage of Windows security is straightforward. The goal is to check to see who is logged on (authentication) and then check that user's role (authorization).

The following steps show you how to create an application that protects the menu system for each user by showing and hiding buttons:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Security.Principal;

namespace WindowsSecurity
{
    public partial class Form1 : Form
    {

        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            WindowsIdentity myIdentity = WindowsIdentity.GetCurrent();
            WindowsPrincipal myPrincipal = new WindowsPrincipal(myIdentity);
            if(myPrincipal.IsInRole("Accounting"))
            {
                AccountingButton.Visible=true;
            }
            else if (myPrincipal.IsInRole("Sales"))
            {

SalesButton.Visible = true;
            }
            else if (myPrincipal.IsInRole("Management"))
            {
                ManagerButton.Visible = true;
            }
        }
    }
}

To successfully run this code, you must have an environment that has Accounting, Sales, and Management NT user groups.

In some cases, you don't need this kind of role diversification. Sometimes you just need to know whether the user is in a standard role, which System.Security provides for. Using the WindowsBuiltInRole enumerator, you describe actions that should take place when, for example, the administrator is logged on:

if (myPrincipal.IsInRole(WindowsBuiltInRole.Administrator))
      {
          //Do something
      }

Encryption is, at its core, an insanely sophisticated process. Five namespaces are devoted to different algorithms. Because encryption is so complex, I don't get into the details in this book.

Nonetheless, it is important that you understand one cryptographic element for a key element of security — encrypting files. When you work with a file in a Windows Forms application, you risk someone loading it up in a text editor and looking at it, unless you have encrypted the program.

The common encryption scheme Data Encryption Standard (DES) is implemented in .NET. It isn't the strongest encryption in these days of 64-bit desktop machines, but it's strong enough to encrypt the data files for a Windows application. You can find the methods to encrypt for DES in the DESCryptoServiceProvider in the System.Security.Cryptography namespace.

If you deploy your application using ClickOnce, you need to define the access to the PC that the application will request. ClickOnce is a Web server–based deployment strategy that allows users to run Windows Forms applications from a Web browser by using the WindowsSecurity tab in the My Project configuration file, shown in Figure 1-2.

Figure 1-2. The WindowsSecurity tab of the My Project configuration file.

Getting to the My Project configuration file is straightforward:

Here, you can define the features that your application uses, so that the user installing it receives a warning at installation rather than a security error when running the application.

A SQL Injection attack happens when a hacker enters a line of SQL code into an input field used to query a database in a form on a Web page (such as the username and password text boxes in a login form). Malicious SQL code causes the database to act in an unexpected way or to allow the hacker to gain access to, alter, or damage the database.

//Get productId from user
string ProductId = TextBox1.Text;
//Get information from the database
string SelectString = "SELECT * FROM Items WHERE ProductId =
   '" + ProductId + "';";
SqlCommand cmd = new SqlCommand(SelectString, conn);
conn.Open();
SqlDataReader myReader = cmd.ExecuteReader();
//Process results
myReader.Close();
conn.Close();

"FOOBAR';DELETE FROM Items;--"

SELECT * FROM Items WHERE ProductID = 'FOOBAR';DELETE FROM
   Items;--'

A script exploit is a security flaw that takes advantage of the JavaScript engine in a user's Web browser. Script exploits take advantage of one of the more common features of public Web Forms applications — enabling interaction among users. For instance, a Web Forms application may enable a user to post a comment that other users of the site can view, or it may allow a user to fill out an online profile.

Preventing script exploits

Fortunately, ASP.NET prevents users from typing most script code into a form field and posting it to the server. Try it with a basic Web Forms project by following these steps (you see the error shown in Figure 1-3):

1. Create a new Web Forms project.

2. Add a text box and a button to the default page.

3. Run the project.

4. Type <script>msgbox()</script> into the text box.

5. Click the button.

Tip

Additionally, you can use the Server.HTMLEncode method to encode anything that the Web Forms application sends to the screen — this will make script code appear in real text rather than in HTML.

Figure 1-3. Script exploits are blocked by default.

Aside from make sure that your Web Forms application will prevent SQL Injection attacks and script exploits, you should keep in mind some good practices for securing your Web applications.

The following list runs down some of the most important practices for securing your Web applications: