1

After reading a bit on DB injections (injecting malicious query code written in SQL, NoSQL, or of any DB querying language), I understand that there are only 3 possible cases for this kind of attack:

  1. When no Transform-To-Pure-Text mechanism is installed on the webserver: For example, you print an HTML form with PHP; This form has an input field and the data is loaded to the DB when the form is saved. The webserver owner installed an experimental server software that doesn't have a mechanism to transform the DB query into pure text and each time such will be given as input, it will be injected and bias the normal DB ecology.

  2. When no Treat-As-Pure-Text mechanism is installed: This mechanism will cause the webserver to treat any form-input whatsoever (or at least any query-like input), as pure text.

  3. When either of the mechanisms exist, but doesn't work because of a bug.

Are these are the only cases when a DB injection could occur?

  • 1
    It might help to share some of the links you've been reading – paj28 Dec 22 '16 at 21:05
  • 2
    Agree, whatever articles you've been reading are full of neologisms or terms that aren't in common use. For example, I have no idea what "pure text" means in this context. Also, instead of "transformations" may I suggest you become familiar with [these terms](http://security.stackexchange.com/questions/143923/whats-the-difference-between-escaping-filtering-validating-and-sanitizing/143925#143925). – John Wu Feb 21 '17 at 00:09

1 Answers1

0

It would suffice to say - as for both of your case no. 1 & case. 2 to be that of input sanitisation problem. Pre-liminary to that of input sanitisation, there's input validation - this could be white listed or black-listed. The black listed approach is not preferred.

Now let's narrow down to the answer, it's just not data conversion, parsing of data, transformation of data or just rendering of data from another source which's the point here; the other sources could be data manipulation where you confuse the logic of the data handler.

Some examples could be basic authentication bypasses, others still could be LDAP variants of injections. Possible causes of DB Injections in your case should be lack of input validation, lack of input sanitisation, lack of escape sequences, lack of string-concatenated SQL queries, also lack of access control through policies which accesses various tables.

This could happen from different perspectives to gain an escalation; Let's discuss about some:

  1. Internal domain controlled SQL Databases - internally invoked which is due to lack of policy set-up.
  2. Externally targeted web applications due to lack of input validation on top of input sanitisation.
  3. At the handler tier of the DB-driver itself where-by an attacker confuses the db-handler to think it's the authenticated user & privileges are granted.

Some myths are:

Whitelisting will be hack-proof - it won't be as letting end-user supplied input be elevated to the same level as the command structure. Consequently, while whitelisting is part of any viable defense-in-depth approach to security, it's still not sufficient enough to protect against SQL injection on its own.

Stored Procedures will make it really hack-proof - while the proper use of stored procedures provides fantastic protection against SQL injection, there's nothing magical about stored procedures that prevents them from being used incorrectly or unsafely; developers make implementation mistakes.

Strict Input Validation, Escape Sequences & Input Sanitisation would suffice - combinations of encoding tricks, escape routines, homoglyphs, and uncommonly used Unicode and ASCII characters as a means of trying to compromise overly simplistic string-replacement routines defined by developers who don't think like hackers will fail, repeatedly.

Basically user input is the root problem set & hence command language is properly separated from data or user input & there you will be clearly be making a strict standard for SQL DB's to be safe.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Shritam Bhowmick
  • 1,602
  • 14
  • 28
  • I admit this answer was very hard for me to read and I misunderstood most of it. I tried to edit the question cosmetically and to be more accurate on terminology, but the answer is very hard for me. Any hope to generally-simplify it a bit?... –  Nov 26 '18 at 08:10
  • In a rare move, I mark as "solved" only because it was the only answer in a long time after above 115 views, and was reviewed without commenting by schroeder. –  Nov 26 '18 at 11:27