The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide charitable organization focused on improving the security of software.  They are best known for maintaining the OWASP Top 10 list of website vulnerabilities.  Last released in 2014, the organization has just published its updated 2017 release candidate list.

Probably the most jarring revelation of the 2017 list is that it looks remarkably like the first OWASP list, originally released in 2003. That's 14 years of little to no change to the top ten list for vulnerabilities which continue to include risks such as cross-site scripting, injection flaws, broken access control and session management.

It may be hard to understand why these risks keep cropping up, however the answer is simple. These vulnerabilities are deeply technical and rarely audited.  Case in point, here’s an example attack scenario offered by OWASP in support of the current #1 and longest-lasting vulnerability - injection:

Scenario #1: 
An application uses untrusted data in the construction of the following vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

---

Scenario #2: 
Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts
WHERE custID='" + request.getParameter("id") + "'");

---

In both cases, the attacker modifies the ‘id’ parameter value in her browser to send: ' or '1'='1. For example:

http://example.com/app/accountView?id=' or '1'='1

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures.

There is an underlying assumption that these types of issues are resolved by the programming department or contractor, but the data indicates that this assumption is wrong. It would be hard for anyone but an experienced and security-conscious programmer or data scientist to grasp this example and ensure it doesn't exist.  

Keep in mind, as humans we are visual and results oriented. We focus on what is in front of us, like does the website look good on a smartphone? Can clients search for a dealer? Can prospects submit request forms? Is it fast?  None of which address website security. It’s usually an afterthought when something goes wrong.

There is such a wide array of competence required to program back-end systems.  Sure, a junior high student can create a great looking, fast and responsive website with dealer search and a request form. But how will will it stand up to a modified "id" parameter? This is when that great looking site becomes a nightmare. It happens all the time, even when there is clear list of security risk to check.

We know this first hand. For several years, Imaginary has been conducting OWASP Security Reviews upon requests for Python-based websites.  If you’re not sure or might benefit from an impartial and expert review, you should consider an OWASP security review. 

For more information on a OWASP Security review, request our OWASP Security Review one-sheet using the contact form below or view an excerpt from a Security Risk reivew.