Security in IT is like locking your house or car – it doesn’t stop the bad guys, but if it’s good enough they may move on to an easier target. — Paul Herbka
We couldn’t agree more. Ensuring the security of your web application is vital. So, here we are with the latest OWASP Top 10 security threats for you to keep an eye out for.
OWASP stands for Open Web Application Security Project — an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.
We share OWASP’s ideology to encourage organizations to get off the penetrate and patch mentality and support what Jeff Williams, from Contrast Securities, said in his 2009 OWASP AppSec DC Keynote: “We will never hack our way secure - it’s going to take a culture change” for organizations to properly address application security. So, this post is not only intended for the application security community but also aims to reach out to developers too.
OWASP Top 10 - 2017 mentioned the following security threats:
This is one of the many upcoming posts, aimed at covering these threats in details. We would start off by looking at Code Injection today.
Injections are among the oldest and most dangerous attacks to any web application. In this attack, the attacker simply sends malicious data, in order to make the application process it and do something it is not supposed to do. Injection flaws are very prevalent, particularly in legacy code. The core reason being: User-supplied data is not validated, filtered or sanitized by the application.
Some other potential reasons include:
Using dynamic queries directly in the interpreter.
Using non-parameterized calls without implementing context-aware escaping (auto-escaping in short) directly in the interpreter. Read more about escaping all user-supplied input here.
Hostile data being used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
Hostile data being used or concatenated directly, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures.
Here is OWASP’s example of an SQL query consuming untrusted data:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";This query can be exploited when the attacker modifies the ‘id’ parameter value in their browser to send: ' or '1'='1.
For example: http://example.com/app/accountView?id=' or '1'='1
This can cause the database table to return all the rows.
To secure your application from injection attacks, here are some of OWASP’s technical recommendations to look out for:
Preventing injection requires keeping data separate from commands and queries.
The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs).
Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
Code injection can be very fatal as it can result in data loss or corruption, lack of accountability, denial of access or can sometimes lead to complete host takeover.