KEY TAKEAWAYS: #

• If you could watch the trail of a vulnerability, it is then obvious for you to know where to fix the problem.

Let’s start with a tale, Bunny Trail.

🐇. . . . #

Imagine you have a beautiful garden 🏡 in your yard.
But there is a problem. All your favorite veggies 🥕 (and some edible plants 🌱) are getting eaten up by bunnies 🐰 at night.
What do you do to solve this?

• I would put a wired mesh around each plant bed. Would this solve the problem?
• I would place multiple traps in the yard to catch the bunnies. Would this solve the problem, instead?
• I would install a camera, watch the trail to find how the bunnies are entering the yard. Then close that opening or hole to stop the bunnies from even entering the yard in future.
  Isn’t this better?

The software VULNERABILITY TRAIL is no different.
If you could watch the trail of a vulnerability, it is then obvious for you to know where to fix the problem.

Look at the typical vulnerability trail in a Web Application code:

As you can see, the vulnerability is entering from TRAIL 1.
This is the user INPUT in the browser on client side.

So you ask, is this where we need to fix the problem to stop the vulnerability from entering our system?
To answer that, let’s see what we can do to fix the problem in TRAIL 1.

In our client-side UI code, we could add input validations so that unexpected inputs 🐞 are not allowed in the UI input fields.

So, we are all good then, right? The user cannot type in and enter malicious payloads 🐞, which means the vulnerability cannot enter the system.
Well, unfortunately NO.
The UI validation code can be easily bypassed. The browser is merely a HTTP client that is sending HTTP requests to the back-end server.
One could use intercepting tools to modify the request parameters after input validations are done OR trick a user (victim) to click on malicious links that send HTTP requests (through victim’s browser).

Which then takes us to TRAIL 2.
This is the entry point for the vulnerability into our back-end system, which means, this is the ❗most important trail step out of all of them.

Once the HTTP request inputs are read for the first time, if we can perform a thorough input validations here, then this alone can ELIMINATE A CLASS OF VULNERABILITIES in our software’s.

In my 2 decades of security experience, most (if not all) of the vulnerabilities that I have come across, are due to simply failing to have a proper input validation in this trail 2 step, period.

Let’s examine the Vulnerability Trail image above and the user input fields Name and Age.
To perform a thorough input validation, one needs to understand the exact requirements on the input fields.
Here are some example requirements for these input fields,

The Name field:

> Accepts only strings (no special characters).
> Could be lower or UPPER case. 

The Age field:

> Accepts only numbers (no special characters).
> Min age is 18 and max age is 100.

Isn’t this simple to validate?
The input fields could be anything (Ex: email address, phone number, xml data, IP address, json, etc.)
If you do the input validations correctly in trail 2, rest assured you eliminated a mass class of vulnerabilities.

To put this in perspective, let’s look at the MITRE 2023 CWE (Common Weakness Enumeration) Top 25 Most dangerous software weaknesses.

XSS and SQLi are in the top 3 (for many years!!!) most dangerous and common vulnerabilities out there.

This is unbelievable but unfortunately is true. The reason I say unbelievable is because if you see the vulnerability trail image, these issues crossed all the trail steps without being detected by the code authors (primary and secondary). Then comes the security team who also failed to detect these vulnerabilities (either through code review or performing pen testing). Then the software is released to the world/customer and some external security researcher uncovers this (or internally found) and a CVE is assigned. The top CWE 25 is determined based on the CVE submissions in previous years.

What does this tell you?
It’s simple. Lack of awareness on secure coding best practices and not knowing how important proper input validations are in Trail 2.

Before I conclude, I want to mention at a high level that beyond Trail 2, we must have secure coding best practices in Trail 3 (Ex: Using prepared statements while building SQL query) and Trail 4 (Ex: escaping the user inputs) as well to achieve defense in depth for these type of issues.