Dangers of Client-Side Validation

Validating user input, and controlling what a user can see at a given time can be vital to the functionality of your web application. However simply hiding specific fields, or disabling buttons prior to receiving appropriate input is not necessarily sufficient for ensuring that the data that is being sent to the server is in the correct format.

It is important to perform as much validation and information handling on server side as possible, or else the information you are being passed, or the interface it is being displayed on could be easily manipulated by an attacker.

A good example of this would be a form, such as the one shown below which has a button that appears and enables when both the name and author field have been populated by the user to ensure that no empty fields are submitted to the database.

Opening up the console (in Chrome for example) the end user has the option to edit the HTML which is currently being displayed to them. The user can take advantage of this and easily edit out certain error checking among other things to modify the functionality of your web application

Original HTML

After HTML has Been Edited

As shown below this is the form mentioned before, with the HTML edited to display the Add Comment button prior to fields being populated.

And upon submission you can see (below) that a comment with nothing has been added without any content in either field.

For some web applications, this may not necessarily be a major flaw due to the un-strict functionality, however it is easy to identify that it could be a major vulnerability in your web application specifically to spammers or attackers depending on the nature of the functionality of your web app.

Fail Open Authentication

Fail open Authentication is when an error occurs and instead of defaulting a value to "false" it defaults to "true". An example of this would be during a login, if an error occurred and the system automatically logged the user in opposed to defaulting to not letting the user is, then authentication would not have been very effective.

One way to prevent Fail open Authentication from occurring could be to always assume access is false, opposed to true, then try to prove it true (guilty until proven innocent). Although this isn't necessarily something that may occur as a possibility to a developer, it could be the difference between a secure application and an insecure application.

One potential way to induce an error could be to use software like WebScarab to intercept a server request and delete a username or password variable (or other variable associated with a particular process). This error being thrown could easily lead to a failure in the application which could default to granting access to the application when access should not be granted.

The example above is not exclusively applicable to just logins but other variables which require a specific input to validate a user has permissions to access any material or perform any tasks. This could also apply to server side text input validation, or any other form server side validation of this nature.

Abusing error handling, although not necessarily as prominent as other techniques of attacking a web application, can easily become just as large a threat as SQL Injection or Session Hijacking.

Denial of Service

Denial of service attacks are essentially brute force attacks aimed at completely overwhelming a server, making it too busy to respond to requests from genuine users. A denial of service attack come in many forms and may overwhelm  the processor, hard drive, RAM or use all available bandwidth of a server. This may result in a web application being made unavailable or being slower then normal, for genuine users.

Most successful large scale denial of service attacks are in fact distributed denial of service attacks, which is a denial of service attack perpetrated by more then one individual or by bots.

Bots or bot nets are often used in distributed denial of service attacks. Bots are programs that perform simple tasks over and over again (such as sending a request to a server over and over again). A person performing denial of service attacks may have one bot or many bots (also known as a bot-net). Each bot of a bot-net is often on a separate "zombie" computer and the owner of the computer is often unaware that the bot is there. A bot-net can have thousands of bots or only a few. In recent years their has been a move to more smaller bot-nets, to "fly under the radar" and avoid detection.

Distributed denial of service attacks are often used by 'hacktivists' to target websites for political reasons. A famous example of this is the distributed denial of service attack by Anonymous members that was aimed at the Visa, MasterCard, PayPal and Amazon websites. The reason for the attack was because Anonymous believed these organizations were attempting to censor WikiLeaks.

SQL Injection

SQL Injection can be avoided by using parameterized queries, encoding, among other methods. If an input field within a web application is used in SQL statement without being parameterized, an attacker can terminate the current SQL statement and begin another one which is naturally a vulnerability to any web app.

I constructed a basic web application to demonstrate the risks of creating a web app without using some form of encoding or parameterized query, as shown below:

By running a command such as the following shown below (where 'CommentDescription' would be the value you are inputting into the input field) you could terminate a current sql statement for any insert sql statments being run:

CommentDescription');

After you terminate the SQL statement you can easily run another command that will also take effect upon submitting data into the database. Examples of this could include, dropping an entire table, or deleting records out of tables, amongst other things. This can be an extremely dangerous web vulnerability.

In order for a general user to SQL inject a site sometimes they may have to guess table names, field names from certain tables to do what they set out to do, other times they may be able to write general enough SQL that they do not need specifics to perform malicious attacks to your database. However this definitely stresses the importance of not using generic table names - such as 'login' for a login table or 'id' for your primary key.

Here is an example of the code I placed into the input field of the web application I showed above.

CommentDescription');DELETE FROM tblimagescomments WHERE commentId='32';

This line of sql completes the previous statement and then also deletes the contents of the record with the id 32 from the table of comments. Although it always seems unlikely that an attacked would be able to guess your table structure or that they would be able to pinpoint that your application has this vulnerability present, SQL Injection is considered one of the most prominent web security threats out there.

Malicious File Uploads

Files uploads which do not validate input are very dangerous because they run the risk of a user uploading a executable or script file which they could hit on their browser and modify or access confidential data from your web server.

I created a vulnerable upload app to demonstrate the principles or web security through upload vulnerabilities and validation.

Here is a screencap below of the straightforward code required to perform this exercise:

Once you have a server side script on their server the possibilities are practically endless. Your script could be as simple as retrieving the structure of the files on the server and then creating more scripts which specifically target individual scripts which you just learned the names of. Once an attacker knows the name of at least one file on the server, they could have the potential to uncover all credentials and access any database information they wish to. It is important to understand, that just because one file's contents aren't necessarily a priority for you to keep private, it does not mean that you shouldn't take as much precaution with those files as the others because one vulnerability could open up access to the server as a whole.

The application I experimented with (with the code above) which looks like the screenshot below, made it possible for me to pull down any files I wanted from the webspace it was placed on simply due to the lack of validation. And despite the fact that this upload page didn't have any confidential information, many of the other pages included FTP and Database login information that would not be intended for the public's eyes.

One easier way to preventing executable files from being able to be run on your server is to make sure file permissions are set to read and write only and not execute for any scripts that involve uploading content. 

XML Injection

With any interaction between client (web browser) and web servers there is always an opportunity for the data being sent back and forth to be tampered with. An excellent example of this is modifying XML/JSON  when being sent from client side to server side.

By using an application, such as WebScarab, you can intercept and modify information being sent in XML/JSON format from the browser to the server. WebScarab does this by allowing users to edit server request to reflect the information which they want to see sent to the server. This allows the possibility for an attacker to edit not only the information which is already contained within the file on the server, but also the potential to add and remove content from the file as well.

An example where this vulnerability could be exploited would be for a point system where the attacker could modify the number of points they gained or loss within an online reward program of video game. Here is an example of what a changed XML request could look like:

Original
<player>
      <playerId>37</playerId>
      <score>100</score>
</player>

Changed
<player>
      <playerId>37</playerId>
      <score>1000000000</score>
</player>

If the values which are being changed have any relation to money (i.e. points which could be redeemed for product, etc.) then it could be a costly flaw in your web application.

One of the examples I applied this technique to was a picture album I created which sent commenting data across the network using JSON. I intercepted the request and altered it so that a comment on one image would be sent to show up  on a separate image than the one that I initially commented on. This definitely stresses the importance of using as much service sided information handling as possible to make sure any tamper that can be done will not interfere the functionality of your web application. Even though a simple photo album may seem like a silly thing to go to any measures to prevent such an attack on, the thought of what could be considered a much larger scale photo album (Facebook) having information like this manipulated in this nature could easily interfere with their privacy settings.

Session Hijacking

When creating session ids it is important to ensure they do not have a discernible pattern to them. Session hijacking can occur when a developer designs session ids to a have a potentially chronological id pattern.

Examples of predictable id sequences could include having a timestamp present in the id value, which can easily be pinpointed by an attacker and if they hijack someone else's session they can easiy determine a distinct pattern between their own and someone's else's session id. Timestamps are typically one of the first things can attacker would look to identify primarily because they are so easily recognized.

Also having values that increment, or have a clear pattern similar to incrementing, included in your session cookies could be just as easily identified by an attacker and used to perform session hijacking.

There are programs which are dedicated to brute forcing session ids if a hacker can narrow down a range. One example of this software is J-Baah (as shown below) which will increment between set values which could be located anywhere within the session id and then it will send the request to the server to verify it's generated session ids it has created to test it.

Alternatives to simply including an incremented value in a session id or a timestamp could be including a randomly generated number, which would make a brute force attack more difficult, or a username in the id.