Insecure Web

When writing a web application, many times developers will focus more on features and usability than anything else Security is often an afterthought. Usually, security is only a concern once a vulnerability has been not only discovered, but exploited. As developers, designers and software architects, we must ensure that the security of our application is rock solid straight from conception. This is often easier said than done.

Building secure applications means that you must really understand a variety of web attack vectors. Your security is only as strong as its weakest point. In most of my research, I have found that many web apps protect themselves from some of the more commonly known, and easier to exploit, attacks. Protecting from these basic attacks is a good start, but certainly not good enough. Even a moderately experienced attacker can exploit these apps.

In most cases, building secure web apps is more of a methodology and set of concepts than a right or wrong approach. As we will find out, all of the top websites on the web today have all implemented some sort of security, but none of them are identical. How you build security into your application depends entirely on your application’s design. You goal is to make your app secure, but how you get there is up to you. I’ll tell you what needs to be done and you need to figure out how to fit it into your code.

As I mentioned, there are a variety of web attacks that you must protect your application against. Most web application attacks are designed to execute scripts on the visitors browser, but there are several others that are more sophisticated and malicious. In this post, I will only very briefly describe a few of them and later posts will talk about these and others in more detail.

1. Inserting scripts in User Generated Content

So called Web 2.0 websites rely on User Generated Content to power and fill their sites with content. Typically, these sites allow virtually anyone to post content in one form or another. For example, websites such as Facebook, MySpace, Digg, Bebo, and many others allow people to create profiles, upload videos, photos, music, write blogs, and leave comments. When creating any of these content types, the user is presented with a number of options – title, description, location, etc.

If these sites do not protect themselves, then there is nothing that prevents the user from putting a script tag inside of any of those fields. If the user is allowed to save a script tag in the field, then the browser will automatically execute that script once a visitor views the content. These scripts, like any other, can do nearly anything they want to a web page.

In a later post, I will discuss some specific attacks, how to protect against them, and what could happen if JavaScript is allowed to execute on a page.
2. Manipulating request parameters

Manipulating request parameters is another attack vector that an attacker will use in an attempt to run scripts on an unsuspecting visitors browser. Using freely available tools, an attacker can see the raw request that your browser sends to a server. Once the attacker sees the raw request, he will know what parameters are being sent from the browser to the server, and from the server back to the browser. Knowing the parameters and corresponding values that are being sent back and forth gives the attacker a glimpse into the backend of the application.

What we will find is that submitting a form on a web page will often send one or more hidden values, that the visitor typically does not see and can not change. Often, an uninformed application developer will only sanitize the values that he or she believes are vulnerable – those that are visible to a visitor. Using the same tools as above, an attacker can change those hidden values on the fly. If the application developer has not taken this into consideration, it is possible that the attacker can use that flaw to insert script tags into the content.

In a later post, I will discuss how an attacker can craft a special URL to dynamically insert script tags into a web page, and how this attack vector could used.
3. Manipulating request methods

The HTTP specification defines several methods (http://www.w3.org/Protocols/HTTP/Methods.html) that may be used to transport data to and from a server. The web, however, is powered mainly by two methods – GET and POST.

The GET method should only be used for retrieving data from the server. Displaying a member profile, querying a database for a search term, or displaying a photo or blog are examples of what would typically be requested with the GET method. Any URL that you enter into your browser, either by manually typing it or by clicking on a link in an email or other web page, is a GET request. GET requests have the unique ability to be copied and pasted in an email, instant message, or other web page because the parameters associated with the request are always a part of the URL itself.

Take a Google search for example – if you type “hackers” in the search box and press “Google Search” your browser will be taken to a new URL.

• http://www.google.com/search?hl=en&q=hackers

This new URL will have a series of parameters that specify the language you are searching in (hl=en) and the search query itself (q=hackers). You can copy this URL and send it to another person and they can see the exact same search results as you do.

The POST method can also retrieve data from a server but should be the only option when a request will change anything in your database – whether it is a adding a new record, changing a record, or deleting one. When a POST request is sent, the corresponding parameters are not sent as part of the URL. Instead, they are sent as a separate payload to the server. They are never visible to the visitor.

What I see many times are web applications that allow parameters to be specified in either a POST or a GET request, when they should only accept one or the other. For example, lets imagine that we have a web application that allows you to create and delete a blog entry. Both of these actions should be POST only because they both alter the database in some fashion.

If the back-end code for the delete blog action accepts the parameters in both a POST as well as a GET request, there is a serious security issue. An attacker can change the POST request into a GET request and a seemingly secure blog delete form turns into this

• http://www.example.com/admin/deleteBlog.php?blogId=1234

Now the attacker can copy and paste that URL to the owner of the blog. If the owner is not careful, they may click on this URL essentially causing the server to execute the delete blog action without any warning.

This is a basic example and this concept can be much more advanced and complicated.

What’s next?

The above three security issues are just the beginning. What I have described here are some of the most basic attacks, but they can become much more elaborate. In future posts, I’ll be explaining each of these, as well as several others, in much more detail. I will also be describing some of the tools that we can use to analyze and assess the security of a website.

Bryan Migliorisi Web Security introduction, web application security