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.

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.

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.

7 elements to protect

• all inputs
• databases
• dangerous functions such as eval() in PHP or JavaScript that allows passing other commands
• auth tokens (make it unpredictable and for one-time use)
• financial transactions
• emails
• maintenance processes such as backup files

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></select>

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," here 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."

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.

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.

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:

• preventing oversights
• knowing the use context

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.