Larry Steinle

March 14, 2011

Strategies to Reduce the Risk of Code Injection Attacks

Filed under: Security,VS.Net,Web — Larry Steinle @ 12:22 am

In 2007 Symantec reported that 80% of web hacks utilized a variant of the cross-site attack. Hackers use a cross-site attack to run their own code in another website that is trusted by the unsuspecting user. The cross-site attack is a type of code injection attack. In today’s post we will review the various types of code injection attacks and discuss multiple strategies to mitigate the risk of unintentionally becoming the host for the attack or the target of the attack.

Code Injection Attacks

There are several types of code injection attacks:

  • Cross-application attack where the hacker attempts to access information from the software system by injecting code into a desktop application.
  • Cross-site attack where the hacker attempts to inject html and/or JavaScript into another website to gain access to personal information.
  • SQL Code Injection attack where the hacker attempts to inject sql code into the system in order to gain access to information in the site’s database.
  • Unauthorized file access attack where the hacker attempts to gain access to another user’s folder or another website altogether that is hosted on the same machine as the attacked site.

Cross-Application Attack

In a cross-application attack the hacker attempts to take advantage of a macro to trick the application into running his own malicious code base under the security context of the attacked application thereby gaining access to sensitive information.

Cross-Site Attack

The cross-site attack may be as simple as injecting an html link into a web page or as complex as client-side JavaScript. The objective is to trick the client into supplying sensitive information that is sent to the attacker’s website instead of the intended trusted site. Or, the injected code may be able to access user information in cookies or hidden variables without any user interaction which could provide the attacker with the necessary information to log in to the trusted site as the user thereby gaining access to the users personal information.

SQL Code Injection

We already covered how SQL Injection attacks work and a strategy to mitigate this risk in the post, Use Regular Expressions to Detect SQL Code Injection. In that article we checked any input for SQL Statements and threw an error if there were multiple statements or unauthorized statements. However there are additional strategies that could be used to further mitigate the risk which we will cover in today’s post.

Unauthorized File Access Attack

With the unauthorized file access attack the hacker attempts to access system resources by entering a folder path in addition to a name in the application. If the targeted application fails to check the path it is possible that the application can serve the results of the unauthorized file path.

Mitigation Strategies

Careful thought must be put into the design of a web site. The url, query string, hidden input values and controls all can be used to inject code into the system. In this section we will review various strategies that can be used to help mitigate the risk of becoming a target of a code injection attack.

Validate Request

ASP.Net offers a very nice page directive called ValidateRequest. This option causes the ASP.Net parser to check for html statements inside control values. If any tags are found in any controls ASP.Net throws an HttpRequestValidationException.

Argument Validation

Always validate input. In a previous post titled, Argument Validation, we learned the importance of validating arguments to create meaningful error messages to make code libraries more intuitive to implement and easier to support. Well thought out argument validation has the added benefit of reducing the risk of code injection.

Things to look for when validating input data or arguments passed into a routine:

  • Is the value the correct type? Did the user enter a string value instead of an integer?
  • Is the value the correct length? Did the user enter more than ten characters of text?
  • Does the value fall within the correct range? Did the integer value fall outside the permitted bounds?
  • Is the value formatted correctly? When expecting a phone number is the value formatted like a phone number?
  • If the input is for a file name does the value refer to an authorized path?
  • Were any url’s in the page modified?
  • Was the requested url modified?

All of these checks can be performed with the ASP.Net Validator controls or the routines provided in the Argument Validator post or the CommandTextValidator class from the Use Regular Expressions to Detect SQL Code Injection post.

When working with paths take advantage of Request.MapPath to ensure that the file is saved within the context of the site. Use the System.IO.Path object to verify that the path is acceptable or that the filename is all that is pulled from the value. Basically, verify that the path provided will give access to the intended folder.

Give special attention to the requested url when using the Model-View-Controller pattern or a variant thereof. Any website using url rewriting techniques is at additional risk of sql code injection. Some site statistic systems rely on the QueryString to track url redirects. While this strategy helps with statistics it does expose a potential doorway for a hacker to redirect the user to an unsecure site as part of a phishing scheme. When using dynamic url addresses take extra precautions to secure the system.

Data Sanitization

Data sanitization refers to the action of removing known keywords so that any injected code is rendered useless.

Anytime content is to be rendered to the screen use the Server.HtmlEncode method. This will ensure that any injected html tags and inline JavaScript statements are displayed as text instead of as html tags. While it is undesirable to show the html tags and scripts to the user and reveal that an attack was attempted it is better than giving the attacker access to the user!

Before saving the value to the database remove any sql keywords like drop, delete, insert, update, select, etc. or add special characters to the words to make them invalid.

Security Model

Use code access security to restrict access to resources. Ensure that user security and role security provides least privileges required to support the features required by each user.

Stored Procedures

Stored procedures make it impossible to run sql code (unless the string value is passed into an execute statement). Avoid the use of inline sql statements. Use stored procedures as often as possible.

Planned Error Messages

Never return the error message with its details to the user. The error message may contain connection string information or user name information that could assist the hacker with finding the weak spot.

Today most login systems don’t even tell the user what they did wrong during login. If the system told the user they entered an invalid password then the hacker has confirmation that they found a valid user name. May not be much but the web site just saved the hacker time figuring out if the problem was the user name or the password.

Use Hash Codes to Detect Data Tampering

This technique can be used when the value shouldn’t be changed by the user. Query string values or hidden input values that should remain unchanged between post backs are common examples of data that can be protected with a hash algorithm.

The hash algorithm produces a unique key value based on the plain text value passed into the algorithm. The key produced by the algorithm is kept with the plain text value. When the page returns the value is once again encrypted and the new key is compared to the original key. If the keys are the same it is assumed that the data wasn’t modified. However, if the keys no longer match then we know the data was modified and the page cannot be trusted any longer.

4 Guys From Rolla have an excellent article titled, Passing Tamper-Proof QueryString Parameters, that demonstrates how to ensure that values can be trusted.

Summary

Mitigating the risk of code injection attacks isn’t difficult. It merely requires a little planning and some fairly simple due-diligence code. While there is no perfect strategy to eliminate the risk of code injection attacks any effort is better than none. Utilizing multiple strategies at the same time makes it more difficult for the hacker to use your site to gain access to unauthorized information.

References

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: