9

First some background:

I'm an Infrastructural Engineer with 5 years of experience mainly in Virtualization and Networking.

I've spent the past year doing a lot of self study about security, passed the Security+, read Web Applications Hackers Handbook and made some good money finding bugs using Bugcrowd and Hackerone.

Whenever I look for vulnerabilities, I always skip SQL injection as most modern application don't show any sign weakness against traditional SQL Injection methods shown in books or online tutorials.

Now, is this the case for other security enthusiasts? How do you approach this? I try to send a lot of unusual characters but the best the result I've got so far was error 500.

Thanks in advance

Mico
  • 377
  • 3
  • 16
  • 1
    You should change the title of you question to something like "Is testing for SQL injection vulnerabilities still relevant in modern web applications?" – ForguesR May 01 '15 at 15:06
  • 2
    Based on the usage of "modern application", I'm guessing one of the reasons this came up is because of how ORMs do the escaping for you to avoid SQL injection. So, related: [Is Django's built-in security enough?](http://security.stackexchange.com/q/27805/7232) – Izkata May 01 '15 at 17:34
  • 2
    It is extremely relevant. When you manage to produce error's, including 500, you're proving that the server isn't handling the input properly. Try brushing up on blind SQL injection techniques. Just because you don't see it, doesn't mean you're not doing it... – Alex May 01 '15 at 21:16
  • 2
    I would say that yes, it really is still relevant. We just found one recently caused by an internal value that ended up in a visible payload. No protection for the internal value in the code as it was never intended to be visible. – John Turner May 01 '15 at 19:42
  • 1
    @Mico Watch https://www.youtube.com/watch?v=rdyQoUNeXSg – Sumurai8 May 02 '15 at 11:13
  • Wordpress doesn't even bother with transactions, I guess you can expect anything… – o0'. May 02 '15 at 13:47
  • 3
    Or, .. how many times a week do I have to point out to someone asking a SQL question over at stackoverflow.com that the approach they are trying to implement is inherently injectable? (and Stack Overflow is dominated by web developers). Worse, how often do I have to point out the same things to someone answering a SQL question? Answer: way too often. – RBarryYoung May 03 '15 at 01:02

9 Answers9

18

Actually according to OWASP, SQL Injection is on top of the top 10 Vulnerabilities through Web applications. https://www.owasp.org/index.php/Top_10_2013-Top_10

and there are many papers, article, news about concerns in this subject and every day there is a news about SQL injection attack against famous web applications such as for example Joomla,Wordpress or websites and so on, so we can not say that " modern application don't show any sign weakness against traditional SQL Injection methods" because every day a new SQL Injection method is introduced.

Ali
  • 2,694
  • 1
  • 14
  • 23
  • 4
    +1 The world hasn't changed much. I just found what looks like SQL injection in an application just this week. In my estimation the developers who don't understand what SQL injection even is still far outnumber the ones who can properly defend against it. – Steve Sether May 01 '15 at 15:23
  • I would not take the OWASP top 10 or Verizon DBR numbers as gospel, you should consider that universal applicability of the data sources and determine what is right for "your" universe - http://blog.diniscruz.com/2013/01/stats-used-to-support-owasp-top-10.html – Eric G May 01 '15 at 20:38
4

SQL injection is definitely not something I would skip over when testing for security. According to the Ponemon Institute Breach Report, SQL injection accounts for 30% of malicious or criminal breaches, the most of any attack vector that resulted in a breach.

My company uses a variety of methods to find SQL injection vulnerabilities in our proprietary applications. We use a combination of scanning the source code through static code analysis and penetration testing on the app in development, test and production. This is coupled with technical controls such as intrusion detection systems (IDS) and a web application firewall (WAF).

Static code analysis vendors/products:

  • Checkmarx
  • Whitehat

Some vendors/technologies that do pen testing:

  • Whitehat
  • Sword and Shield
  • Accuvant
  • Nexpose (Rapid7)
  • Hailstorm (Trustwave, formerly Cenzic)

There are a number of methods for detecting and/or blocking SQL injection that you can review here: Imperva - How to Block SQL Injection. While the blocking might not be what you are looking for, it definitely has some good tools to determine if it is vulnerable.

The simplest method is to just run some simple scripting that throws garbage/attacks at the website but I would clear it first, obviously.

oBreak
  • 470
  • 3
  • 5
4

I am not sure what exactly is meant by a modern application. Yes, many frameworks, ORMs, Entity Framework, etc. decompose queries and may apply some default filtering. However, in more complex scenarios that require custom coding, or where the ORM or library functions won't do exactly what you want, you will open up the door to SQL injection or other attacks.

With a lot of ORMs and frameworks, the security part is baked in. This has the impact of automatically taking care of some security concerns, but at the same time, many developers may not understand what these library functions do for them, and when they need to craft a bespoke solution, they just follow some tutorial and don't know they need to take security into account.

Also, when you step outside of basic end-user CRUD type apps, developers may need to use less well maintained libraries. For example, lets say you have a business app where someone can upload a CSV file and that is being processed. Maybe someone wrote up a library to handle this and didn't use the ORM, it works so your developers go with it. The CSV is then read line by line and processed into the database, SQL injection may be possible here.

SQL injection is a symptom of a lack of proper input validation, the likelihood of this increases in less common or more complex scenarios where it can't be baked in or its an after thought.

Also, "modern" applications may look modern but are built upon some old junk or some weird legacy connections which throw off the baked in expectations.

Eric G
  • 9,691
  • 4
  • 31
  • 58
  • 2
    SQL injection is not an issue of improper input validation. `O'Reilly` is a proper input for a last name. – Gumbo May 02 '15 at 06:07
3

OWASP has some information about how to fins SQL inhections, as to not beeing present. A recent Drupal SQL injection shows that that is simply not true (even in a mature environment as Drupal.)

The way you find these things is often simply employing fuzzers and sending random garbage to the web app.

LvB
  • 8,217
  • 1
  • 26
  • 43
2

Now, is this the case for other security enthusiasts?

In my experiences, No - SQL injection is still prevalent.

I perform on average 30-50 web application assessments per quarter and I can vouch that SQL injection is still an issue with modern applications.

With that being said my assessments are approximately 85% automated with 15% manual followup / verification / validation (I am by no means a professional pen tester)

An automated scanner has the benefit of finding finding SQL injection in parameters fields that may have otherwise been overlooked.

The downside is that an automated scanner isn't great at exploiting logic flaws like a human could.

k1DBLITZ
  • 3,933
  • 14
  • 20
2

Many applications have grown over the years. Unless the code is refactored once in a while to reflect current best practices (i. e., in case of SQL injections: parameterization), many applications contain quite much legacy code that hasn’t been touched in years. And chances are that it won’t be touched as other parts depend on it. Refactoring costs time and money. And honestly, there is no need for refactoring as long as it works, right?

For example, if you look at Wordpress, they are using a function called wp_magic_quotes, which basically mimics the behavior of PHP’s magic quotes, which was a ‘security feature’ that automatically escapes certain characters in $_GET, $_POST, $_COOKIE, and thus $_REQUEST. This ‘feature’ has been deprecated in PHP 5.3.0 and removed in PHP 5.4.0 as it has been considered a bad idea for several reasons (also note the comments).

Yet, although Wordpress depends on and enforces magic quotes, there are still plenty of SQL injection vulnerabilities in plugins or themes.

Another fact: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') is placed third with 10 % among the weaknesses of all CVEs (see Overall CWE in Security Database’s Dashboard).

Gumbo
  • 2,003
  • 1
  • 13
  • 17
  • 1
    The entire WordPress plugin ecosystem is a security disaster. The core product itself isn't much better. The only thing slightly worse than WordPress and WordPress plugins is a backdoor script. – CubicleSoft May 02 '15 at 06:16
0

The classic, old-school 'or 1=1 # SQL injections are long gone; but sophisticated ones will creep up once in while. That's one way that TrustWaves makes money by keeping its ModSecurity rulesets updated.

Most modern web apps go through a 'security deployment checklist' and are usually also tested for known vulnerabilities before production deployment. Once deployed, the bounty hunters appear and run their own tests. The system is considered as 'secure' as it could get at that point in time.

The automated tools used by developers and bounty hunters, while fast and helpful, also miss some sophisticated injections that a determined human attacker would eventually discover.

David_Springfield
  • 184
  • 10
  • 2
    They are certainly not long gone. It truly depends on the developers writing the data access layer and whether they perform the appropriate checks. On StackOverflow there are plenty of questions in which queries are built by raw string concatenation (these questions usually receive strict warnings from commentators). – grovesNL May 02 '15 at 19:21
0

It depends on what platform an application is built on. I don't think that Drupal or Wordpress will be a mature developer's choice of tool to design an App. And you as an experienced software engineer in your analysis probably don't face low quality applications like that. I don't want to say that if one uses Wordpress he will get an SQL injection or XSS attack for sure. These platforms are like Windows, improper use and popularity brings to vulnerability.

Yes, SQL injections are still present and you need to be careful about them. On the other hand the more mature developers you are dealing with, the less you need to worry about it.

Said Kholov
  • 101
  • 2
0

Finding SQL injections today it iss very easy, and anyone can do it.

There have been many developers and researchers predicting the end of SQL Injection, however, year after year we see it still in the OWASP Top 10.

SQL injection is everywhere and lack of education or knowledge (or maybe bad habits) how to write secure code is a problem. For example in this book "Head First PHP & MySQL" in chapter six the reader is introduced to SQL Injection and how to thwart it with mysqli_real_escape_string(), but the sanitation method is not used throughout the rest of the book, leaving any readers that don’t read from page to page vulnerable. By not using proper sanitation for the rest of the book the users will of course forget to use sanitation as well.

For passwords the book introduces MySQL’s SHA() method, however, no proper password algorithm or salts are used.

In Appendix A (named “All the topics we didn’t cover) we find a topic called “Securing your PHP application”. These pages only contained a couple of pages on removing phpinfo() scripts and combating XSS.

So yes SQL injection are still very relevant.

Michal Koczwara
  • 1,580
  • 3
  • 15
  • 27