In terms of separation of concerns, I would like to know your opinion about whether the concern of handling SQL Injection Attacks is a concern of System A or System B, let me explain:
System A - You where asked to implement an Web Interface, responsible to determine authentication, this is, determine if the user exists and it's password does match. To perform this, you where told that, to determine if an user exists and is valid (password validation), you have to call an Web Service (System B).
So System A is just an interface HTML and JS that sends data to server code a PHP page for example,
and from your PHP page you receive the input and pass it along to the Web Service, and you wait for a response.
After that you assume that you can communicate with it and you get some statistical data only.
To remember the user you use cookies.
System B - The Web Service, is not of your responsibility, is a previously developed system already working for a good amount of time, and you know nothing about it besides it's WSDL specification.
Later on, a Security Team, tests your interface and says 'Hey you allow SQL Injection, your interface has problems it should clean the inputs to prevent against SQL Injections!!!'.
Question ?
So, know that you have understood the situation, I ask you guys, in
terms of Web Security Best Practices and Separation-of-Concerns,
should System A, the interface/proxy who knows nothing about the Web
Service underlining Persistence technology, protect against SQL
Injection or not?!
In case, there is some best practices that contradict my opinion, can you point me to it please?
My Opinion
My opinion is that, NO, the interface in this case is Delegator of
responsibility and is intended to be a Proxy between an user complex
specification (WSDL) and a more simple interface (Web Page), it is NOT
intended for this interface to be a some kind of Firewall between the
Web Service and the Client (client > web server > web service).
Assumptions
1) Browser and Web Server communication is protected over an SSL connection (HTTPS).
2) The network where the connection between WebServer and WebService is established is considered a trusted network, assume you have some kind of firewall between the web server network (DMZ) and the Web Service network (Privileged Network).
3) The Web Service is only accessible inside the same network of the web server of course.
4) Anyone can talk with the Web Service because it doesn't enforce any kind of authentication, to the machines you can reach him, although this is not a concern of System A, so this is just for you to know, no need to think about it.
Only the code that actually talks to the database (i.e. System B) should be concerned with protecting against SQL injection (typically, just by using bound parameters).
Anything at a higher level is not in a position to effectively protect against SQL injection - it won't actually know what kind of database server is being used so it can't protect against server-specific attacks, it doesn't know how the application is actually using parameters (it might be concatenating two fields together before using them in SQL), etc.
Also, attempting to block SQL injection at higher levels runs a high risk of false positives. This might not affect some applications (e.g. forms consisting of numbers only), but for anything needing to handle arbitrary text, SQL injection protection at the wrong level is highly likely to incorrectly block perfectly harmless uses of ', ;, --, etc.
It’s always the responsibility of the system that executes the SQL to ensure the SQL does what it’s intended to be.
So if system B does not what that anyone may change the intended SQL via injections, it’s absolutely the responsibility of system B to prevent that.
To supplement what others have already said, this is definitely system B's responsibility for a variety of reasons, probably the most important of which is that the author of system A has no idea what the appropriate protections might be due to the decoupling. Even if system B is using plain text concatenation when interacting with the database in its current incarnation, there's no guarantee that any part of this mechanism will be conserved in its next version. Maybe it won't even use a database at all, in which case any database-relevant protections implemented in system A will become moot.
Even worse, the kinds of "protections" that one could possibly implement in system A might actually lead to security weaknesses of their own. For example, it is not unusual to see sites restrict character sets available for passwords, presumably out of concern for potential injection attacks. Given that raw passwords should never be passed to the underlying data store for either storage or matching (a system B concern in this case), there is no actual protection provided by restricting the password character set if the authentication system is well designed. However, restricting the character set does have the deleterious effect of reducing the potential password entropy, thereby making the system less secure overall.
That said, while a potential SQL injection vulnerability in system B isn't really your responsibility as the implementer of system A, there presumably is an overall system owner somewhere who is driving the decision to rely on system B for authentication. The system B vulnerability should be communicated to that system owner so that an appropriate decision can be made regarding whether to fix system B, switch to an alternate authentication service, or accept the vulnerability (with that last option not being particularly recommended ).
System B should handle input validation in this case. If system A does input validation for preventing injections, tomorrow if you have one more new interface C which talks to B then you will have same issues to be fixed. So the entity which has more control on SQL interaction should handle this concerns.
