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:
- Internal domain controlled SQL Databases - internally invoked which is due to lack of policy set-up.
- Externally targeted web applications due to lack of input validation on top of input sanitisation.
- 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.