{"id":754,"date":"2019-04-25T19:01:01","date_gmt":"2019-04-25T19:01:01","guid":{"rendered":"http:\/\/www.smart-bricks.net\/?p=754"},"modified":"2019-04-28T22:23:12","modified_gmt":"2019-04-28T22:23:12","slug":"the-5-most-critical-web-application-security-risks","status":"publish","type":"post","link":"http:\/\/www.smart-bricks.net\/index.php\/2019\/04\/25\/the-5-most-critical-web-application-security-risks\/","title":{"rendered":"The 5 most critical web application security risks"},"content":{"rendered":"\n

OWASP provides a comprehensive list of the most common vulnerabilities<\/strong>, and here, we will show you 5 of them which you have to take into account during the entire dev process<\/strong>.<\/em><\/p>\n\n\n\n

Developing a real work web application can be really challenging. The developer team must have very good skills in all the layers from the frontend down to the very backend<\/strong>. This challenge is even bigger when considering the most common security risks that web applications can have.<\/p>\n\n\n\n

The Open Web Application Security Project (OWASP) wrote a document \nwith a list of the top 10 most critical web application security risks \nwith the goal to make companies aware of such important and common \nissues so that they can take proper action to avoid them. Here, and for \nthe sake of brevity, I am going to describe the 5 most critical security risks<\/strong> in the list.<\/p>\n\n\n\n

1. SQL injection<\/h2>\n\n\n\n

Consider an application that takes a text as input from a user in order to build a query (command).<\/p>\n\n\n\n

If this query is built concatenating the user input without escaping special characters, the attacker can trick the interpreter by inserting special commands<\/strong>.<\/p>\n\n\n\n

The most common example is the SQL Injection vulnerability<\/strong>. To be more illustrative, imagine that we have a query like this inside the application:\n\n\n\n\t\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\t“SELECT name FROM users\n\n WHERE name = ‘” + name + “‘ AND password = ‘” + password + “‘”\n\t\t\t\n\t\t\t\t<\/p>\n\n\n\n
\n\t\t\t\t\t123\n\t\t\t\t<\/td>“SELECT name FROM users  WHERE name = ‘” + name + “‘ AND password = ‘” + password + “‘”<\/td><\/tr><\/tbody><\/table>\n\n\n\n

\nImagine that there is a form where the application reads <name> and <password>.<\/p>\n\n\n\n

The attacker will be able to exploit this vulnerability easily by writing:\n\n\n\n\t\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\tname = foo\n\npassword = ‘ OR ‘1’ = 1\n\t\t\t\n\t\t\t\t<\/p>\n\n\n\n
\n\t\t\t\t\t123\n\t\t\t\t<\/td>name = foo password =  ‘ OR ‘1’ = 1<\/td><\/tr><\/tbody><\/table>\n\n\n\n

\nThe query will end up with this form:\n\n\n\n\t\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\tSELECT name FROM users\n\nWHERE name = ‘foo’ AND password = ” OR ‘1’ = ‘1’\n\t\t\t\n\t\t\t\t<\/p>\n\n\n\n
\n\t\t\t\t\t123\n\t\t\t\t<\/td>SELECT name FROM users WHERE name = ‘foo’ AND password = ” OR ‘1’ = ‘1’<\/td><\/tr><\/tbody><\/table>\n\n\n\n

\nThe addition of OR \u20181\u2019 = \u20181\u2019<\/strong> will make the where<\/strong> clause to always be true.<\/strong> This means the query will retrieve the complete list of users in the application. You can find more examples here<\/a>.<\/p>\n\n\n\n

In order to not have this issue, you should never concatenate strings to build queries. You should use Prepared Statements, Criterias, LINQ, or any other mechanism provided by frameworks<\/strong>.<\/p>\n\n\n\n

2. Sensitive data exposure<\/h2>\n\n\n\n

This exposure is related to how sensitive data is transmitted and stored<\/strong>. It can occur when:<\/p>\n\n\n\n