Owasp Security Shepherd – Poor Data Validation – Solution – LSB

Welcome hackers to a new OWASP Security Shepherd solution. The challenge in question is the Poor Data Validation and this happens when data is only checked on the client side. By catching the traffic as it leaves the browser, we can alter the data.

If you want to know how to set up Security Shepherd on your home network, I did a blog on that, you can find it here.

Description

The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as Interpreter Injection, locale/Unicode attacks, file system attacks and buffer overflows. Data from the client should never be trusted for the client has every possibility to tamper with the data.

AvantLink Affiliate Program avant


In many cases, Encoding has the potential to defuse attacks that rely on lack of input validation. For example, if you use HTML entity encoding on user input before it is sent to a browser, it will prevent most XSS attacks. However, simply preventing attacks is not enough – you must perform Intrusion Detection in your applications. Otherwise, you are allowing attackers to repeatedly attack your application until they find a vulnerability that you haven’t protected against. Detecting attempts to find these weaknesses is a critical protection mechanism.

pdv1

As we can see from the image, we have our browser open and there is a short explanation telling us how poor data validation occurs. The object of this level is to enter a negative number into the text field and send it to the server as we see in the following image.

pdv2

So lets enter a number and press the Submit button and see what the application does. It just says it’s a valid number. So lets try a negative number and see what the application does.

pdv3

We have an error. So lets try submit a positive number 1 and catch the traffic as it leaves the browser. We need Burp Suite running with the intercept on and drive the traffic through 127.0.0.1 port 80.

pdv4

We will need to instruct the traffic to go through the same IP and port. Use Foxy Proxy for this task.

pdv5

Okay, once that’s done lets submit the number 1 in the application again and catch the traffic before it leaves the browser with Burp.

pdv6

The image above shows the request to the server and as we can see at the bottom the application is sending a userdata integer. What would happen if we changed the number to a -1 and send that request?

pdv7

Lets forward that to the application and return to our browser.

pdv8

Eureka!! we have the result key. It was that simple. Copy the validation code and enter it in the field above and hit Submit.

pdv9

We have passed this level.

pdv10

Data Validation Strategies

There are four strategies for validating data, and they should be used in this order:

Accept known good

This strategy is also known as “whitelist” or “positive” validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn’t match should be rejected. Data should be:

  • Strongly typed at all times
  • Length checked and fields length minimized
  • Range checked if a numeric
  • Unsigned unless required to be signed
  • Syntax or grammar should be checked prior to first use or inspection

If you expect a postcode, validate for a postcode (type, length and syntax):

Thanks for visiting. Let me know what you think in the comments below.

QuBits 2017-09-08

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s