Professional ASP.NET Security - Jeff Ferguson

'Security Through Obscurity' is Not Real Security

It is sometimes tempting to think that if we hide something it is secure. For instance, we put some private documents in an unannounced folder on our web site. We only tell those who we wish to access the documents that the folder exists but do not add any additional security. Is this secure? Of course not - anyone who finds or guesses the name of the folder can gain access.

Time and time again, we are shown that obscurity does not provide real security. For example, there have been cases where companies have provided access to 'private' folders through hidden links on web pages. These links, perhaps hidden in a corner on a transparent graphic, may not be obvious to a human reading a web page, but to a search engine 'spidering' the page to collect links, they are just as obvious as any other link. The search engine will then helpfully spider the private folder and add it to its index. Most search engines respect instructions not to index specified pages (for instance, in a robots . txt file) but the fact remains that the information is still open to anyone with the desire to spider it.

It can be argued that all security eventually comes down to obscurity. If someone guesses my password they can access my system. The security of the system is based on the obscurity of my password. The important thing is that my password is not just unannounced, it is chosen from a sufficiently large pool of possible passwords that guessing it is not practicable (especially if we put systems in place to prevent a large number of guesses being made).

The most secure systems (those where we are most confident that gaining access is impracticable) are those that throw obscurity out of the window. Encryption algorithms that are currently considered secure are thought of as such because they have been opened up to scrutiny and attempts to crack them. Even full knowledge of the way that they work is not sufficient to provide a practicable way to crack them. In comparison to using one of these well known, well tested algorithms, using an untested system on the basis that no one knows how it works is very foolish indeed.

Equating obscurity with security is one of the most common security mistakes. Consider whether your application would be just as secure if an attacker knew its inner workings and structure. Would the system be secure if one of its designers or developers were trying to compromise it? If the answer is no, you should consider doing something differently.

Never rely on obscurity of your processes for security - always assume that an attacker has inside knowledge of your system.

The Application is Only as Secure as its Weakest Link

A modern web application is a complex beast, composed of many parts. Insecurity in any of these parts can lead to the whole application being compromised. It is important to remember that attacks can be made against any part of the application. For instance, there is no point working hard to protect your web sever if the database server that supports the application is wide open.

A malicious user looking for a way into your application will not limit themselves to one mode of attack. They will try a range of different techniques until they find one or more that works.

Think carefully about every part of your application and every system that supports it. Every part needs to be protected properly in order for the whole to be secure.

26

Building Secure Web Applications

A good way of visualizing the parts of your system that might come under attack is to draw a diagram of the components that compose the whole system. Remember to include everything, from the client machine with its browser software right through to back-end database servers with their database software. Once you have a diagram, consider each component in turn as a potential weak point. Also think about the connections on the diagram - could the communication between system components be compromised and be the source of a vulnerability?

This weakest link problem means that often the security of the applications we are developing depends on other people outside of the development team. As we discussed earlier, many different roles are involved in ensuring the security of web applications. It is important that these roles communicate well with each other.

Try to consider every part of your system that might come under attack and communicate with the people responsible for systems that the application is dependent on.

Security is Important at Every Stage of Development

Good security needs careful thought and hard work from the early stages of application design right through to deployment and beyond. Mistakes at any stage of the process can make good security difficult to achieve.

During application design, security must be a key consideration. If security is not built into the design from the start, it will involve much more work to add it later. Carefully considered choices must be made about what security features will be implemented. It is important to consider the whole system as well as individual components - sometimes interactions can lead to unexpected ways of compromising the system.

While the application is being developed, code must be carefully checked to ensure that it does not introduce vulnerabilities. Code reviews are a good way of doing this - it is a good idea to have reviews specifically to look at security issues. All code must be checked - a mistake in even an innocuous section of the application could create a vulnerability that exposes the whole application.

Application testing must make identifying security problems one of its objects. Extra effort in security testing can avoid much more work in dealing with a security breach.

Security must be considered when the application is deployed. The final production configuration must be checked to ensure that vulnerabilities are not introduced at this late stage.

Make security a priority rather than an afterthought.

In Security, the Job is Never Done

You work hard to design and build a secure system. You have considered every way that you can think of for unauthorized access to be gained. You've done a good job but you are not finished. If you do not maintain the security of your application, new vulnerabilities could render your hard work pointless.

Security is an ongoing problem and must be treated as such. Applications must be patched as vulnerabilities are discovered and new ways of exploiting them are developed.

O7

Security policies can easily slip after an application 'goes live1. Modifications to an application in order to fix bugs or add new functionality can add new security vulnerabilities. If you are serious about security then plan for regular audits to ensure that security is being maintained.

Plan for ongoing work to maintain security.

Over Restrictive Security Can be Counter-Productive

Sometimes too much security can be a bad thing. If security systems become restrictive for users, they may fall out of use or be circumvented. For instance, if we insist on our users choosing 24 character passwords that contain at least 6 numerical digits, 6 capital letters and 6 symbols, it is unlikely that they will successfully remember them. They will, quite naturally, record their passwords to help them recall them. This could lead to worse security, as it is then possible to steal the passwords.

Security needs to be well thought out so that it does not stop users of the application from successfully using it. If we create a security scheme that prevents users from making use of the application, we might as well turn off our servers and lock them in a safe.

Think carefully about how the security systems that you implement will be used and how they will affect users who access the application. A compromise needs to be found that provides acceptable levels of security and usability.

Give consideration to how security systems will be treated by day-to-day users of the system.

Security is Not Just About Technology

There is no magic technology answer to the problem of security. Security has to be addressed from a wide variety of angles, of which technology is only one.

Users need to be educated about security to make sure that they are not the weakest link in the system. This is important as users are very often the source of vulnerabilities. Social engineering attacks, where users are tricked into compromising the security of a system, are becoming one of the most successful ways to bypass the security of systems.

Everyday business processes should be examined to ensure they do not introduce vulnerabilities. If security is not made a priority, it is easy for best practices to slip, and for security systems to become irrelevant. Being serious about security means making it a core part of the business rather than just a technology issue.

Make security a key consideration in every aspect of the business.

28

Building Secure Web Applications

We Can't Rely on Users to Maintain Security

It is a sad fact that the majority of computer users do not fully appreciate the need for them to take an active role in ensuring the security of web applications. Most users assume that security will be taken care of by the developers and administrators of the system so that they do not need to worry about it.

In many ways, it is fair for users to expect that developers and administrators should take the lead in ensuring security. Users should not have to concern themselves with the mechanics of the systems they access. It is our responsibility to create security systems that are as transparent as possible to the users while providing an acceptable level of security.

It is important to remember that, given the chance, a reasonable sized pool of users will find a wealth of ways to weaken the security of a system in order to make their use of it easier.

For example, imagine that we recommend that users choose passwords that are at least 7 characters long and contain a mix of letters and numbers. If we do not do anything more than make a recommendation, some users will ignore our advice and choose shorter passwords that are easier to remember. If we want to ensure that the passwords in use on our system are secure, we need to make it impossible for a user to choose an insecure one. This could be done by checking new passwords for the features we want before they are accepted.

A general rule worth bearing in mind is that the safest thing to assume is that, when given a decision to make, a user will make the least secure decision they possibly can. We need to ensure that every option the user has is a secure option.

Assume the worst when presenting users with choices: if an insecure option is present, some users will take it.

Summary

We've taken a quick look at why security is important to us in web applications. We looked at some of the ways that malicious users can gain unauthorized access, but we also noted that security isn't just about keeping the bad guys out - identifying and controlling the access of users is very important in modern web applications.

We also looked at some key security points that are worth remembering and gave the following advice:

maintain security.

29

Treating the Client with Caution

I'd like to start this chapter with a quote from the book Art of War by Sun Tzu:

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.

In a sense, security is a kind of a war that we have to fight each and every day, regardless of the time of day or year. In the next few chapters, we'll investigate various types of common vulnerabilities, and how to avoid them by writing secure code.

Many software security vulnerabilities are created by developers who have little knowledge about security issues or security threats, and how vulnerable their code is. Developing a secure system begins with understanding the nature of security threats. In this chapter, we will begin our investigation of common vulnerabilities by looking at the ways in which the client can pose a threat to our application.

Companies are increasingly deploying web applications to manage their business and attract new customers over the Internet, and this is a successful business model for many. An added advantage of web-based business is that we can reach people all around the world with minimal infrastructure. The down side to this is that we don't know who is accessing our site. Our visitors could be genuine users, or malicious users.

Almost all web applications accept user inputs in one way or another, process this input, and produce results. For example, an application could expose a simple search form, in which a user may enter a search phrase, and the application will search for the results in the data store and display a result. This is very common functionality that can be found on any web application. When the user enters the search phrase, they might mistype a word. However, if the user is malicious, then they could enter a search phrase that could tamper with the stability and security of the web application. Even though we might have deployed an excellent security infrastructure, such as a firewall that blocks all attacks, if we don't validate the user input, our web application is as vulnerable as it would be without any security infrastructure.

So it is very important that each and every user input should be treated as un-trusted data until it is proven to be safe. Hackers know how applications use input, and how this input can be used to exploit security vulnerabilities in the application. The best way to get out of this kind of trouble is to validate all input. Validating user input can add a performance hit to the application, but it is worth it.

Un-trusted data can come from several sources, including:

O URL query strings

Q HTML Form fields

Q Cookies

Q Data queried from a database or any other data source

The query strings, form fields, or cookies, can be validated before processing data. Sometimes the data that is imported from an external source - such as data from your vendors, partners, or supplies - could also be unsafe. It is therefore very important to validate each piece of data before processing it or presenting it.

Let's start by exploring some of the possible effects that could be accomplished by non-validated input.

Script Injection

A script injection attack occurs when malicious tags and/or script code is inserted via the web browser by using a user input box. This user input will be stored in a data store such as a database or cookie. Such code could be designed to have any of a number of different effects, and may affect the operation of an Internet application or site for all users.

When a client with scripts enabled in their browser reads this message, the malicious code may be executed unexpectedly. Scripting tags that can be embedded in this way include <script>, <object>, <applet>, and <embed>.

Let's see an example of this type of attack. Let's assume that we have a web page that displays author's names, on which we can enter new author names. We have used this simple example for illustrative purposes, but it is essentially the same as the type of situation, for instance, where a search textbox accepts a search sting from a user, and displays the search string with the search results.

What would happen if the user were to enter something like <script>alert ( ' Script Injection' ) ; </script> as the author name.

34

Treating the Client with Caution

I 3 htlp: /localhost/chl2/Addfluthor_CS.AspK - Microsoft Internet Explorer jmjmj

Script Injection

1Srinivasa Sivakumar Author Name: |<script>alert('ScfJpt Injection^), </script>

2Russ Basiura

If we don't validate the user input, we'll insert the JavaScript code author name into the database, and every time the data grid is displayed, it will execute the JavaScript code (which it thinks is the name of an author).

Cmd.ExecuteNonQuery();

catch (Exception Exp)

//Handle the exception IblExc.Text = Exp.ToString();

Conn.Close();

Address |^Jhttp://localho;t/chl2/AddAulhor_C5.Aspx _^J {*6o ( Links

If we look at how this is happening, we will notice that the inserted script is not modifying the source on the server side. Rather, it modifies the dynamic content generated for the client. Although this scripting is not modifying the server-side code, it is still dangerous, since the un-trusted malicious script inserted by the user runs as if it were from your site. The script code entered by the hacker doesn't just affect a single user, rather it affects all the users who visit the page.

In the same way, the user can enter any malicious JavaScript into the textbox. For example, the user can enter something like <script>location.href = 'Malicious .html' ; </script> as the user's name.

When theJavaScript <script>location.href = 'Malicious.html' ;</script> is inserted into the database as the author name, this will transfer the control of the browser to the Malocious . Html page, whenever the AddAuthor_CS. aspx file is loaded in a browser.

Remember the location tag could point to an absolute URL, which will transfer the users to a different domain.

a http: /localhost/chlZ/Malicious.html - Microsoft Internet Explorer

Malicious Script Injection Attack

Using the Script Injection, you've been redirected to this page.</Malicious Attacker>

|^ Local intranet

36

Treating the Client with Caution

In the Malocious .html page the hacker can do virtually anything: the possibilities are endless. For example, the hacker could download a malicious ActiveX control or JavaScript code and execute it, or could open a couple of new browser windows and redirect users to ten different sites.

Cross-Site Scripting

A cross-site scripting attack is very similar to the Script Injection attack, and occurs when malicious script code is inserted into the web browser via another site's dynamically generated web pages. In this kind of attack, a hacker's target is not our web site, but our users. Let's suppose our site accepts search strings using the QueryString collection via the HTTP GET method, and that other sites can pass the search string in the Search query string.

YourSi te . com?Search=ASP . NET

Our ASP.NET search page will read the query string information in the Page_Load event, and will search for the information in the data store, displaying the result. If it can't find any information in the data store, then it will display a message letting the user know that the search string could not be found. Our search page is constructed in the following way:

if (qStrAryti] == "Search") {

StringU qStrAryVal = colQstr .GetValues (i) ;

for (int j = 0; j<=qStrAryVal .GetUpperBound(O) ; j++)

{

sSearchStr=qStrAryVal[j];break;

if (sSearchStr .Trim( ) != "")

{

if (SearchDataStore (sSearchStr ) == false )

IblResult.Text = "The search keyword " + sSearchStr " did not produce any results. Please try again.";

bool SearchDataStore (String sSearchStr) {

/*Perform the search against the datastore and display the result. If there are no results then return false.*/

return false;

37