• Anupam Juniwal

One simple step to make your web application secured from about 80% of attack attempts

TLDR;

Sanitize user input.


Introduction


When it comes to web application vulnerabilities the most common ones all fall under a single type: Injection attacks

Why should injection attacks be taken seriously?


In all common critical Internet-Facing vulnerabilities,

- XXS accounts for about 40% of web attack attempts.

- Query Injection for 24% and,

- Path Traversal accounts for 7%


All of these attacks are marked as ‘High risk’. Why? Because attacker can get access to sensitive information, corrupt your data, get your system information, crash your system or worse, get total control over your system.

So, what is injection? It basically is adding an extra syntax in input which would lead to unintended execution, may it be a system command, query or file access.

Above stated are 3 types of injections, let’s have a look at some classic examples:


1. Cross Site scripting (XXS):


XXS attacks are the most dangerous ones as they can give system level access to the hacker.

Let’s say your webapp have a ping utility, so whatever address you give in as input, your application is going to ping to that address and check if it is reachable.

response = runCommand(‘ping -c 4 ’ + address);

now let’s say an attacker gives in address as:

8.8.8.8; ls -l;

The final command executed would be:

ping -c 4 8.8.8.8; ls -l;

This would execute ls -l command on your system and return it’s output to the attacker.

Now, ls still looks harmless on surface, but any command could be executed in place ( ex: reboot), and even the information gathered from ls could be used to orchestrate a more complex attack.


2. Query Injection:


Query injection vulnerabilities are the most easily left out by any developer. Let’s take an example of a simple login form, where you have an sql query as:

query(`select id from users where username = ‘${username}’ and password = ‘${password}’`);

now, if the user input given for username and password is:

username: ’ or ‘1’=’1

password: ‘ or ‘1’=’1’ and role = ‘admin

this would result in the following query to be executed:

select id from users where username = ‘’ or ‘1’=’1’ and password = ‘’ or ‘1’=’1’ and role = ‘admin’;

now this completely changes the meaning of query and simply logs in with first user found with admin role.

This is not just the case with sql statements, this happens with no-sql queries also, let’s take an example for mongodb:

db.users.find({username: userName, password: userPassword});

And we give in input as:

{ userName: {$ne: null}, userPassword: {$ne: null} }

This would result in bypassing the login, logging attacker in with the first user found.


3. Path traversal:


Let’s say you have a file hosting application. So you let users upload a file, save it on the server, generate an Id for them — using which they can access the file. And the following is your implementation to return the file:

return openFile(‘public/uploads/’ + fileName);

now if we supply fileName as:

‘../../../../../../../../../../../etc/passwd’

The resultant command would become:

openFile(‘public/uploads/../../../../../../../../../../../etc/passwd’)

which would return the contents of passwd system file.

Solution: Sanitize user input.

For all three above stated attacks if the user input is sanitized, we could prevent possible vulnerabilities. One method of string sanitization which works for query injection and XSS attacks is to escape the input. For example if in example 1, ‘8.8.8.8; ls -l’ is escaped, the input would be considered as a single argument and thus the command would act as:

ping -c 4 ‘8.8.8.8; ls -l’

which would result in incorrect command.

And the sql query for example 2 would become:

select id from users where username = ‘\’ or \‘1\’=\’1’ and password = ‘\’ or \‘1\’=\’1\’ and role = \‘admin’;

which would again result in no matches.

For path traversal, a different technique could be used. Something similar to:

fileName = fileName.split(‘/’)[0]

could work.

For sql query injections, try to use prepared statements, they handle sanitization of sql inputs for you, considering each input as a single token, thus the sql query does not gets malformed.


Resources:


If you want to play around and test some vulnerabilities out for your self, here is an application for you: https://github.com/appsecco/dvna


References:


Original Post at:


https://medium.com/@anupamjuniwal/one-simple-step-to-make-your-web-application-secured-from-about-80-of-web-vulnerabilities-49370697df54?sk=24e36dd169f10e06c5d18fa07ddb867b

16 views
  • Facebook
  • Twitter
  • LinkedIn
  • Pinterest