Web Application Hacking — Bypassing Client Side Controls

Hey guys, Welcome back. This is the continuation of the series on web application hacking. Today we are gonna see, the controls and validations placed on the client side and how we bypass it.

Lets get this started.

The fundamental security flaw in a Client-Server architecture is the server has no control over the client. And the first lesson in web-application security or building web applications in general is never trust user input.

Transmitting data via the client

The most general assumption of a developer is that a user is confined to input that is restricted in the UI. This assumption makes the development process easier and reduces the amount of work needed to be done on the server side. This would make the work of even a beginner to get the way into an application. Lets see what are the ways data is transmitted to the server from the client.

Hidden form fields

This is a most common way to transmit data from the client in traditional web applications.

Quantity: <input type=”text” name=”quantity”> (Maximum quantity is 50) <br/>
<input type=”hidden” name=”price” value=”449”>

Hidden fields are not rendered in the UI / displayed on the screen. But when the form is submitted, the following request will be made

POST /shop/28/Shop.aspx?prod=1 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
quantity=1&price=449

Try submitting negative values in fields like these, as they may have not been validated in the server. This may give us a win-win situation.

HTTP Cookies

Cookies are the next common way to transmit data from the client. A Normal user, cannot modify the cookies directly. With an intercepting proxy, this can be done with ease.
1. Intercept the response from the server when the cookie is set.
2. Modify the request when sent to the server.
Consider the example

HTTP/1.1 200 OK
Set-Cookie: DiscountAgreed=25
Content-Length: 1530

The corresponding request is made when we submit any further requests, we can get arbitrary discount by modifying the DiscountAgreed cookie.

POST /shop/92/Shop.aspx?prod=3 HTTP/1.1
Host: example.com
Cookie: DiscountAgreed=100
Content-Length: 10
 
quantity=1

URL Parameters

Data is transmitted in URL in the form, ?variable=value, depending on the nature of the application.

A simple example,
http://example.com/shop/?prod=3&pricecode=32

If these are in the browser’s address bar, we can easily modify it.There are some places, where we cannot modify the URL directly from a browser. Embedded images, embedded iframes, forms with preset parameters, application using some means to conceal address bar.
In these situations, we may use an intercepting proxy.

Referer Header

Referer header tells where the request originates from. Some applications may process these to allow allow a requested action.

For example, consider a request for password reset.

GET /auth/472/CreateUser.ashx HTTP/1.1
Host: example.com
Referer: https://example.com/auth/472/Admin.ashx 

If the server allows the reset action based on the header, we may end up resetting the password for an admin user.

The referer header is completely optional and using it control an application’s behaviour is a simple hack but other security controls too should be in place.

Opaque Data

Sometimes, data may not be in plaintext form, it may be encrypted or encoded using some algorithm. This implies that, the application performs additional checks on the input data. This may bring bugs on its own.

Consider the example,

<input type=”hidden” name=”pricing_token” value=”E76D213D291B8F216D694A34383150265C989229”>

Capturing User Data

Length Limits

The browsers may restrict users from entering long data with the maxlength attribute.

Quantity: <input type=”text” name=”quantity” maxlength=”1”> <br/>

To circumvent this, simply intercept the response and remove the attribute.

Script Based Validations

Validations available in HTML are simple. So we get into javascript to perform those validations.

Consider the example, where the function is called when the submit button is clicked.

<script>
 function validateForm(theForm)
 {
   var isInteger = /^\d+$/;
   var valid = isInteger.test(quantity) &&
   quantity > 0 && quantity <= 50;
   if (!valid)
    alert(’Please enter a valid quantity’);
   return valid;
  }
</script>

Simple validations like these can be circumvented easily,
1. Disable Javascript in the browser.
2. Intercept the request and change the values.
3. Intercept the response and modify the function to always return true.

Disabled Fields

Disabled fields appear to be grayed out and cannot be edited. This is also not sent to the server. There may be a case, where these fields may have been used in the development process. So it is a must to test the field out to see if the server still processes the given field.

Price: <input type=”text” disabled=”true” name=”price” value=”299”>

Handling the Client Side Data — Prevention

1. Never transmit important data from the client. Have a reference in the server and use data available on the server side.
2. If there is no other way, obfuscation / encryption is must.
   If Encryption is used, there may be replay attacks. So while encryption, use data related to the item. Example, if a product’s prize is encrypted, perform encryption along with the unique product code.
3. If things specific to a profile is issued like discount, save it in their profile or use the session objects.
4. Data from the client side cannot be validated in client side itself.
5. Using obfuscations or extensions may slow down an attacker, but not stop him.
6. Always replicate each and every client side validations on the server too.

Exploitation

Here is what you need to do as an attacker,

Transmitting Data Via Client

1. Locate all instances where data is transmitted via the client.(hidden fields, url params, cookies, headers etc..)
2. Guess the role that the specific item plays in the application.
3. Modify the item to affect the behaviour of the application. So we can find if any vulnerabilities are exposed.

Opaque Data

1. Attempt to decipher the data, if you know the plaintext.
2. Use functions else-where in the application to de-obfuscate the data. See Extrapolating behaviour
3. Try replaying. Example, if price is obfuscated, send the token of a low price item for the expensive ones.
4. If nothing works, attack the logic, submit overlong data, modified data, different character sets etc.,

Capturing Input

1. Identify places where client-side validations are in place.
2. Try submitting values, that would have failed the client side validation. Using an intercepting proxy.
3. Ascertain if the client side validations are replicated on the server. If not further attacks can be carried out.
4. If there are multiple fields validated in the client, try out each field seperately.

We may use the features of Burp Suite on our way to explore and ease the process.

With the increase in SPAs and JavaScript heavy applications, we need to go through all the resources in our hand, not only monitoring the requests and responses, help. We need to go through the UI and also the source code for the evidences of exploitation.

Thanks for reading, hope you learned something new.

See ya’ll in my next blog.