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.