Avoiding code flaws, ok, but how?

It’s not uncommon to spot code flaws in the code base. If you find any weakness such as harmful injections, XSS vulnerabilities, hard-coded credentials, hazardous serializations then it’s essential to fix them.

You’d be surprised how critical your code can be.

Permalink to heading Disclaimer Disclaimer

The code base is only one element in the global security. An important one, but there are many other elements to check. For example, your code might be “perfectly” fine, but if the server is misconfigured, hackers will exploit that.

Permalink to heading The state of cybersecurity The state of cybersecurity

Websites and apps have now pretty robust technologies to fight cybercriminals in addition to the firewalls, scanners, and other classic defenses. That’s why it’s often more efficient for attackers to exploit unescaped inputs and weak validations.

There are literally dozens of variants of injections and XSS, and such vulnerabilities can be used for further actions like privilege escalations and lateral movements.

Ok. It’s pretty bad, and your potential adversaries have access to an extensive range of free tools and techniques to destroy your house of cards:

Photo by Sigmund

However, with some principles in mind, you can prevent the most obvious flaws, a.k.a. the ones that hackers will try first.

Permalink to heading 7 elements to protect 7 elements to protect

Permalink to heading Ok, but not all flaws are critical Ok, but not all flaws are critical

It’s true that reflected XSS (Cross-Site Scripting), for example, rely on weak input validation but are non persistent. It gives the classic joke:

https://mywebsite.com?s=<script>console.log("Welcome back XSS. Sir, what can I do for you?");</script>

The code is not supposed to work, but if that’s the case, anybody can execute arbitrary JavaScript on your page.

The hackers would need to send the crafted link to their victim (e.g., in a malicious mail). As a result, you might think it’s a bit less dangerous than SQL injections that can retrieve the entire database with users’ credentials and their confidential information.

Still, JavaScript can do a lot of things, so yes, there are various degrees of severity, but it’s always the same principle “Don’t trust user inputs.”

Don’t assume, don’t expect anything from the users. Another underappreciated flaw, to me, can be the lack of server-side validation for HTML <select>. If you have something like the following:

<select id="myselect" name="select" required>
  <option value="coco">Coco</option>
  <option value="banana">Banana</option>
  <option value="vanilla">Vanilla</option>

Don’t let people modify the HTML and send you other values. Instead, whitelist allowed values. Likewise, validate data types, file types, and everything you can to filter the values in other inputs.

Indeed, it’s not the end of the world if you receive “chocolate,” but do you really want to add potential extra work to the support team?

Besides, it can raise the curiosity, like “hum, let’s see if I can inject more here.”

Permalink to heading Don’t trust your eyes Don’t trust your eyes

Some techniques rely on invisible chars and other fancy tricks with unicode or a specific charset to bypass validation.

Escape HTML entities and other special chars.

Permalink to heading Use strict mode Use strict mode

Enable strict mode whenever you can, regardless of the language. Most devs don’t use strict mode for convenience or because of a bad legacy code.

The problem is that the engine will make guesses and even sometimes modify the values automatically if you don’t enable it, which is precisely what hackers need to inject malicious commands.

Permalink to heading Prefer late escape Prefer late escape

It’s best if you can escape data the latest possible, for example, just before database insert or the final display. This approach has many advantages such as:

Permalink to heading Wrap up Wrap up

Even with all that in mind, there are tons of other elements to consider, but, hopefully, it’s a good start to improve security.

Try to hack your own code by passing unexpected values to your inputs or modifying the HTML before sending forms, and you’ll know what to do.