Common Security Issues in Web Applications. Part 1

Yo Yo chaps.

Today, I want to talk about some of the common security issues in modern web applications and best practices for avoiding them. I hope this article will help developers to have simple understanding of some issues that appear to be in 80–85% of applications.

Let’s discuss some possible vulnerabilities…

Password Hashing

A lot of people use MD5, SHA512 for password hashing. Don’t do this ever again! They have been considered deprecated for a long time. Well, you might think they are not the best choice due to their cryptographic weakness, but that’s not the case. The main reason is that it‘s fast which means during brute force attacks millions of passwords can be tried on a single GPU.

I hacked couple of websites that were using these kind of algorithms. With machine learning and statistics, I made a list of most possible passwords for a user, and it took minutes to hack some users’ accounts. Most of them had very simple passwords, usually, people don’t bother to think of a good password for simple websites like forums or blogs.
P.S. Don’t try this at home!! :)

The right solution(this is not the only one) is using BCrypt for storing user’s passwords which is an adaptive hash function based on the Blowfish symmetric block cipher cryptographic algorithm. BCrypt also introduces a work factor, the value of which determines how slow the hash function will be. Higher values for the work factor will take longer and will generate different hash values, which makes it extremely resistant to brute force attacks.

You want to hash passwords because when someone gets access to the application database, they will not be able to restore the original versions of passwords(if it’s hashed properly).

But why should you always hash passwords in the back-end and not in the front-end? In either case HASHED passwords are stored in the database, aren’t they ?!?!

NO! Hash the passwords only in the back-end and there is a reasonable explanation for that. If you hash the passwords in the back-end, an attacker has to first crack(bring back to original version) them to use them on your website, but if you hash them in the front-end, an attacker doesn’t need to do this, they can just pass the hash as it is stored in the database.

XSS

People who are using jQuery or vanilla JavaScript will surely encounter this issue as there are no implemented XSS prevention mechanisms. Even if there are, it’s not what we actually need. In this example,

XSS example in JS

inserting data with innerHTML may cause serious problems as responseText from back-end could be something like this.

<img onerror=”alert(‘Yo Yo, I am about to do something bad’)” src=”NotAProperUrlhere”>

And someone’s JavaScript code will start working on your browser.

Same story with jQuery html() and append() functions. Those ones sanitize script tags, but still, a bunch of other tags can do the job.

But if you’re using Angular, React, etc., you can be sure that you‘re protected from XSS attacks unless you disable security features, which is strongly NOT recommended.

<div dangerouslySetInnerHTML={createMarkup()} />;

This is how you should bypass React’s rules for XSS attack prevention. Doesn’t look trustworthy, eh?)

Session Handling

In most cases, after the session has started, you generate a session Id(this can be done by a lib) and store it in browser cookie for handling the authenticated users for each and every ajax call. Always be careful about these points:

1. The cookie SHOULD have the ‘httpONLY’ flag set, so that the attacker’s JavaScript can’t have access to the session Id.
2. The session Id should not be username, user id or something like this. It should be a random and a unique string, which practically can’t be guessed. Don’t use Math.random() or anything like this since it’s not cryptographically secure. And to be fair, It’s not even random :) You can use ‘uuid/v5’. This seem to work really good.
3. A session shouldn’t have a long lifetime, so that the session Id does not remain on the web client cache for a long period of time, from where an attacker can obtain it.
4. Sessions should be destroyed after some time of user inactivity.

Thanks for reading. To be continued…