Tag Archives: SQL Injection

OWASP logo

OWASP Top 10 List Maturing – Evidenced by Minor Changes

The OWASP Top 10 list is well known as the industry standard for what matters in web security. The list, which ranks the most critical risks organizations face through their web applications, was recently updated. The 2013 Top 10 List features some incremental but noteworthy changes that point to the project’s maturity.

OWASP logo

Perhaps the most significant change to the Top 10 list is the moving of “cross-site scripting” (XSS) from its No. 2 spot to No. 3. This is a big change because web security was built on two things: SQL injection and XSS. Almost every browser these days has some level of XSS prevention, so it’s more difficult to deliver a XSS payload to a user. As a result, XSS represents less of a risk.

By moving to No. 3, XSS switched places with “broken authentication and session management,” which moves up to No. 2 from No. 3. Broken authentication and session management isn’t well understood by most developers, and I suspect that’s why it’s moving up. We see a lot of weak authentication and session management schemes. Developers just aren’t doing a good job with it. But they’re going to have to, because this is a new attack vector that will really matter in the future, especially with the move to mobile.

The OWASP also renamed what was previously “failure to restrict URL access” to “missing function-level access control” and moved it up one spot, from No. 8 to No. 7. This makes sense since it doesn’t matter how access is presented. It is either restricted or it’s not.

“Insecure cryptographic storage” and “insufficient transport layer protection” were also combined and renamed “sensitive data exposure,” which came in at No. 6. This essentially merges the encryption layer, which makes sense. Sensitive data should be transported over a secure channel and stored in a secure manner. You’re dropping the ball if you do one and not the other.

OWASP also added an item to the Top 10 that I think is long overdue. “Using known vulnerable components” deserves its spot at No. 9. Developers have long used shared libraries and open source code, and oftentimes these components have vulnerabilities that affect the software built with them. This has gone on since the days of PHP-Nuke. I’m shocked that it wasn’t on the list before because it seems so obvious, but maybe that’s why it was overlooked.

Finally, the last change I’d like to point out is also one that I don’t necessarily agree with. That’s the drop that “cross-site request forgery” (CSRF) made from No. 5 to No. 8 on the list. We still see a lot of CSRF, partly because automated testing tools just aren’t good at detecting it. It’s becoming increasingly difficult to test for these vulnerabilities and to know when you need CSRF protection. Unfortunately, it still happens a lot and when an attack is successful it can have significant repercussions – especially when combined with XSS.

The changes that we see in the OWASP 2013 Top 10 won’t impact most people because they are incremental, but overall these changes bode well for the list. It’s getting leaner and better. That’s a sign of the project’s maturity.

 

Surviving the Week – 12/09/2011

Sorry I missed last week, this one will cover the last two weeks.

 

Announcing SQL Invader

Today, we announced SQL Invader, a new free GUI-based tool that enables testers to easily and quickly exploit a SQL Injection vulnerability, get a proof of concept with database visibility and export results into a csv file. In just a few clicks, users will be able to view the list of records, tables and user accounts on the back-end database.

Tools like this are still critical for comprehensive application security testing and can help organizations remain a step ahead of the bad guys. SQL Injection has been the dominant method used in this year’s high-profile web application attacks; with millions of sites attacked in 2011.

We created this tool because our customers and the community at large have expressed a need. We want to always contribute to the community as much as we can. Although SQL Injection is well documented and there are tools to discover the vulnerabilities, it has been very difficult to determine if the vulnerability can actually be exploited because most existing SQL Injection testing tools are executed from a command line, lack an intuitive user interface or are no longer supported.  Without the ability to clearly demonstrate the exploitability of a vulnerability, remediation efforts are often delayed and friction between security and development teams surfaces. We designed NTO SQL Invader so that penetration testers and developers can quickly and easily leverage a vulnerability to view the list of records, tables and user accounts on the back-end database.

SQL Invader works as a standalone solution or with NTOSpider and enables you to:

  • Paste the injectable request straight from an application scan report
  • Control how much information is harvested.
  • View data in an organized manner using tree control and data grids.
  • Leverage logging data in CSV file