This documentation is archived and is not being maintained.

Overview of Web Application Security Threats

Visual Studio .NET 2003

Someone is going to try to hack your Web application. That is, if unknown users can get to your Web application, the odds are almost certain that someone will try to do something unauthorized or even malicious to your application. Most servers that are accessible to the public on the Internet are typically probed for vulnerabilities at least four or five times a day.

Therefore, no matter what your Web application is, you should build security into it. You should think about security the same way that you do about backup. Although you might not think that you will ever have a problem, it is always safest to assume that you will and to take precautions, just in case.

Perfect Security is Impossible

The first lesson about Web application security is that there is no such thing as perfect security. Even in secure systems, malicious users can wield sophisticated tools to try to get into your system. Fortunately, most attacks come from relatively unsophisticated users who simply look for sites that are easy to break in to.

Your initial goal should be to protect your site from the common and redundant exploits that comprise the vast majority of attacks.

Security Technology Is Only Part of the Solution

Implementing security is only part of the solution. Another important part is vigilance. Even if your system has many security safeguards, you need to watch it closely in these ways:

  • Monitor your system's event logs. Watch for repeated attempts to log into your system or for a very high number of requests against your Web server.
  • Learn about and install the latest security patches from Microsoft and other vendors. For example, the Microsoft security site (www.microsoft.com/security) has a list of the latest security bulletins for all Microsoft products. Other vendors have similar sites.

Threat Modeling

An important part of building a secure application is to understand the threats to it. Microsoft has developed a way to categorize threats that goes by the acronym STRIDE (Spoofing-Tampering-Repudiation-Information disclosure-Denial of service-Elevation of privilege). The sections below briefly describe these threats and how they apply to Web applications. For more information, see Designing for Securability.

Spoofing

To spoof is to impersonate a user or process in an unauthorized way. At its simplest, spoofing can mean typing in a different user's credentials. A malicious user might also change the contents of a cookie to pretend that he is a different user or that the cookie comes from a different server.

In general, you can prevent spoofing by using stringent authentication. Any time someone requests access to non-public information, make sure they are who they say they are. You can also defend against spoofing by keeping credential information safe. For example, do not keep a user name (or worse, a password) in a cookie, where a malicious user can easily find or modify it.

Tampering

Tampering means changing or deleting a resource without authorization. One example is defacing a Web page, where the malicious user gets into your site and changes files. An indirect way to tamper is using a script exploit. A malicious user manages to get code (script) to execute by masking it as user input from a form or as a link.

A primary defense against tampering is to use Windows security to lock down files, directories, and other Windows resources. The application should also run with the minimum privileges it can. You guard against script exploits by being extremely distrustful of any information that comes from a user or even from a database. Whenever you get information from an untrusted source, sanitize it by making sure it does not contain any executable code.

Repudiation

A repudiation threat is to hide evidence of an attack. In a Web application, this can mean impersonating an innocent user's credentials. You can guard against repudiation by, again, using stringent authentication. In addition, use the logging features of Windows to keep an audit trail of any activity on the server. For details, see Event Logging in the Platform SDK documentation.

Information Disclosure

Information disclosure simply means stealing or revealing information that is supposed to be private. A classic example is stealing passwords, but it can involve access to any file or resource on the server.

The best defense against information disclosure is to have no information to disclose. For example, if you avoid storing passwords, malicious users cannot steal them. (An alternative to storing passwords is to store only a hash of the password. When a user presents credentials, you can hash the user's password and compare only the hashes of the two.) If you do store secrets, use Windows security to secure it. As always, you should use authentication to be sure that only authorized users get access to restricted information. You can also encrypt information to help keep it secret.

Denial of Service

A denial of service attack is to deliberately cause an application to be less available than it should be. A typical example is to overload a Web application so that it cannot serve ordinary users. Alternatively, malicious users might try to simply crash your server.

IIS allows you to throttle applications, which means that it limits the number of requests it will serve. You might be able to deny access to users or IP addresses known to be malicious. Protecting against crashes is a matter of running robust code. You should test your application thoroughly and recover gracefully from error conditions, if possible.

Elevation of Privilege

An elevation of privilege is to use malicious means to get more permissions than normally assigned. For example, in a successful elevation of privilege attack, a malicious user manages to get administrative privileges to your Web server, giving themselves a free hand to wreak havoc.

To protect against elevation of privilege, run the application in a least-privilege context if practical. For example, it is recommended that you do not run ASP.NET applications as the SYSTEM (administrative) user.

See Also

Security Portal | Securability | Best Practices for Securability | Introduction to Web Application Security | ASP.NET Web Application Security | Security Bibliography

Show: