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.
$199 ENROLLS YOU INTO OUR SELF PACED COURSE – LFS264 – OPNFV FUNDAMENTALS!
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.
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.
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.
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.
We will need to instruct the traffic to go through the same IP and port. Use Foxy Proxy for this task.
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.
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?
Lets forward that to the application and return to our browser.
Eureka!! we have the result key. It was that simple. Copy the validation code and enter it in the field above and hit Submit.
We have passed this level.
$299 WILL ENROLL YOU IN OUR SELF PACED COURSE – LFS205 – ADMINISTERING LINUX ON AZURE!
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
Linux Security Blog 