Future Web Service Security Technologies

Common Security Mistakes

To build a Web service that can withstand attack, you cannot simply scatter security features here and there. As I stated earlier, you must design your application with security in mind.

Here are the three most serious security mistakes that developers (including Web service developers) make:

• Storing secret data insecurely

• Connecting to SQL Server incorrectly

• Building insecure SQL strings

While the .NET common language runtime and the .NET Framework help mitigate many current security threats, such as buffer overruns, they cannot counter bad design decisions. (In fact, all three types of mistakes apply to all programming environments and operating systems.)

Let's look at each type of mistake in detail.

Mistake #1: Storing Secret Data Insecurely

Storing secret data securely is impossible in software—you can only make it more difficult for an attacker to get at your data. Secure data storage is somewhat easier at the server because the attacker does not have physical access to your software. However, storing secrets in client code is truly impossible. This makes things difficult if you think you can perform a secret handshake or perform a secret transaction based on a secret embedded in your client application. Attackers can easily reverse-engineer the client application to determine the secret.

Secret data includes private or personal data such as passwords, encryption keys, identification numbers, sales figures, and credit card numbers. When you store data, you should consider what the ramifications would be to you, your business, and your clients if the data were exposed to unscrupulous users (I in the STRIDE model) or tampered with by an attacker (T). (If you are having problems coming to grips with these issues, imagine that it is your personal data being stored!)

Information disclosure threats are easy to take care of—you simply do not store the data in the first place. I'm quite serious: in some situations, it is quite valid to give users the option of having you store the data for them, but let it be an opt-in situation. Users might get added ease of use when you store the data for them, but they might blame you if the data is not adequately protected against attackers.

In addition, some data does not require storage; it is simply used to validate that the user knows the data. One example is a password—you can determine whether a user knows a password without storing the password itself. You do this by hashing the data and storing only the hash, and then when the user provides the password, your code hashes the data and compares the hashes. If the two are the same, the user knows the password.

The following sample code shows how you can gather a password from a user and compare it to another hash:

public bool ComparePasswordHash(string password, byte[] hash) {     SHA1Managed h = new SHA1Managed();     UTF8Encoding e = new UTF8Encoding();     byte[] p = e.GetBytes(password);     h.ComputeHash(p);     byte[] hr = h.Hash;     bool same = true;     for (int i =0; i < hr.Length; i++) {         if (hr[i] != hash[i]) {             same = false;             break;         }     }     return same; }

But what if you have to use secret data such as a password? Where should you store it, and how can you secure it? One place you can store the data is in the web.config file; however, if an attacker can access the configuration file directly, he can read the data. The same applies to storing the data in an .aspx or .asmx file. Deployment issues aside, you should avoid storing sensitive data in any of these files; instead, store it outside the Web space. This might mean storing the data in the file system but outside the root of the Web file system space or storing it in a location not in the file system, such as the system registry.

Mistake #2: Connecting to SQL Server Incorrectly

Many developers incorrectly connect to SQL databases, including SQL Server, using the sysadmin account. They do this because testing is easier—everything works. Unfortunately, this might also mean that everything will work for attackers, too.

The SQL Server sysadmin account, sa, is the most capable and privileged account available to SQL Server. The account can do anything to a SQL Server database. If you must use SQL authentication (rather than Windows authentication), you should connect using an account that has only the permissions it requires in the SQL Server database and has no access to any other objects in the database.

Also, make sure the account has a very strong password.

Mistake #3: Building Insecure SQL Strings

Go on, admit it: you have constructed SQL strings like this:

string sql = "select * from table where name = '" + name + "'";

The variable name is provided by the user. The problem with this SQL string is that the attacker can piggyback SQL statements in the name variable.

Imagine the following input, where name = "Blake", which builds this totally benign SQL statement:

select * from table  where name = 'Blake'

But what if an attacker enters name = "Blake' delete from table where name = 'Lynne' --", which builds the following malicious statement?

select * from table  where name = 'Blake'  delete from table where name='Lynne' -–'

This statement will return all the data in the table where the name is Blake, and then it will delete all the rows where the name is Lynne! Believe me, many attacks are more insidious than this. How can they happen? Because the SQL connection is made using the sysadmin account, which can do anything to the database, including delete any data. Note the use of the ' --' sequence—it is a comment operator, which makes the attack much easier to pull off.

Now let's look at an example and some remedies.