Some Vulnerabilities for Consideration (not exhaustive)

The “Head-in-Bucket” fallacy

This fallacy occurs when the application authenticates the user, determines the user’s role(s), and then hides / disables links or buttons to functionality. And stops there.

This is a failure to actually authenticate and/or authorize a request. A person can simply access the “hidden” urls directly.

Instead, every request must be checked for both authentication and authorization, at the server level. An authentication token is typically issued (usually in the form of a cookie for web applications) so that the user does not need to continuously enter their credentials.

The “Session == Authentication” fallacy

In ASP.NET applications, the default forms authentication is controlled by a separate cookie from the session cookie. And these two “tokens” can have different lifetimes. If not handled correctly, this could lead to one user seeing another user’s data when they log in. Typically this would only occur if the users sat down at the same computer.

The “If I use stored procedures, I am immune to sql injection” fallacy.

What protects from sql injection is parameterization (though see wildcard injection). A stored procedure that uses dynamic sql to concatenate a parameter directly into a sql clause is still vulnerable to sql injection.

Similarly, constructing a string to execute the stored procedure by simply concatenating user input is also still vulnerable to sql injection.

Key Splitting

This vulnerability occurs when you have a compound key to a piece of data where each component gets set and validated in separate processes (e.g. set into the session in different web requests). This can lead to scenarios where although each of the individual components is “correct” the combination allows access to unintended data.

Exposing Temporary Files to the web

This occurs when you create a temporary file that contains sensitive data within the web application. Typically, this will end up being in the IIS directory, and unless special care has been taken, IIS will happily serve the file to whoever requests it. It may not be intended to be served at all, or it may be intended to be served to only a single user - but regardless of intent, anyone can access it.

The solution is to ensure that temporary files are in a location not served by IIS, or that IIS has been configured to otherwise not serve those files.

Better yet, you can typically avoid creating the temporary files in the first place by doing all your processing in memory from the request stream (for incoming files) or doing a Response.BinaryWrite or, for an MVC application, simply returning a FileResult from your action method.

Exception Paths

Exceptions can cause alternate paths through the code to be executed, with possibly unintended side effects. This is most likely to be a problem when an exception occurs while operating on some sort of “Persistent” data, such as a database or Session variable. For databases, the solution is to use proper transaction boundaries (which you should be doing for more reasons than just security!) which rollback with the exception. For Session variables, care needs to be taken that data does not get set in a “dangerous” way, the specifics of which will vary from application to application.

Priviledge Escalation

This is a class of attack whereby a (even authenticated) user is able to gain more priviledges than they have been granted.

An example of this would be storing user-roles in a cookie. After logging in, the server issues the cookie. The user then modifies the cookie to include additional roles.

The ASP.NET Membership API by default will store the user’s granted roles in a cookie. It prevents priviledge escalation in this case by default - because it encrypts and cryptographically signs the cookie to prevent tampering.

For practice: What are the assumptions here?

Side-channel attacks

These are attacks that exploit a particular physical characteristic of an implementation.

For example, it has been demonstrated (though not “usefully”) that digital information can be leaked by monitoring the temperature of a server CPU (citation needed).

A more common example is where a cryptographic key can be broken because an implementation takes longer to perform some oprations than others.

Replay attacks

A Replay attack is where information is captured, and then resent to the server to get it to perform some operation.

Encryption and Digital signatures do not prevent this type of attack, because it is not necessary to decrypt or tamper with the payload.

Replay attacks are typically prevented using a Nonce.

Some ASP.NET MVC / Sql Server Vulnerabilities and Mitigations Examples:

Sql Injection / Wildcard Injection

This is an example of Code and Data Confusion.

Cross-Site Request Forgery (CSRF)

This is a particular instance of the larger class of vulnerabilities known as Confused Deputy

This is a “targeted” vulnerability, in that it must attack a specific web application. However, it completely bypasses all firewalls, and enables the attacker to take any action of the currently logged in user.

Cross-Site Scripting (typically Javascript Injection)

This is an example of “Code and Data Confusion”, and “What is data in one context may be code in another”.

Note that this vulnerability undermines the protection against CSRF, because the attacker could inject javascript that would report the antiforgerytoken cookie back to the attacker.

Modifying Http Request Variables for ModelBinding

An example of “Abstractions are Leaky”, “All user modifiable input is evil”

Models will bind from POST parameters, Url parameters, and cookie variables (I think - never actually done it). There is a priority - (TODO find the reference!)

The model binder only knows what it sees from the http request - thus a user can tweak the http request to control what values get passed to the model - even if you do not provide UI elements in your page to do so. So you need to treat the entire model as an example of “All user modifiable input is evil”.

The code example in the repository does not actually demonstrate a vulnerability (currently), but it can be used to prove to yourself how model binding can be tampered with. A useful tool for that endeavor is the TamperData FireFox addon.

External Resources

OWASP

The Open Web Application Security Project commonly known is a rich resource for security information in general. In particular, it also maintains its OWASP Top Ten list of the what is currently being most exploited (updated yearly).

National Vulnerability Database

The National Vulnerability Database is sponsored by the U.S. Government. It now includes cross-referecnces with the Common Weakness Enumeration.

Common Weakness Enumeration

The Common Weakness Enumeration is a community source for vulnerability information.

IEEE

IEEE Computer society publishes Security and Privacy a magazine dedicated to security issues.