在关注点分离方面，我想知道您对处理SQL注入攻击的问题是否是系统A或系统B的关注的看法，让我解释一下：
系统A - 您被要求实施负责确定身份验证的Web界面，即确定用户是否存在且密码是否匹配。要执行此操作，您要告知，要确定用户是否存在且有效（密码验证），您必须调用Web服务（系统B）。
所以系统A只是一个接口HTML和JS，它将数据发送到服务器代码的PHP页面，例如， 从PHP页面接收输入并将其传递给Web服务，然后等待响应。
之后，您假设您可以与之通信，并且只获得一些统计数据。 要记住用户，请使用cookie。
系统B - Web服务不是您自己的责任，以前开发的系统已经工作了很长时间，除了WSDL之外您对此一无所知说明书
稍后，一个安全小组，测试你的界面并说'嘿，你允许SQL注入，你的界面有问题它应该清理输入以防止SQL注入!!!＆＃39;。
问题？
所以，知道你已经理解了这种情况，我问你们 网络安全最佳实践和分离关注的术语， 应该是系统A，对Web一无所知的接口/代理 服务强调持久性技术，防止SQL 注射与否？！
如果有一些与我的观点相悖的最佳做法，你能指点我吗？
我的意见
我的意见是，不，这种情况下的界面是代理人 责任和旨在成为用户群之间的代理 规范（WSDL）和更简单的接口（Web页面），它不是 打算让这个界面成为某种防火墙之间的 Web服务和客户端（客户端＆gt; Web服务器＆gt; Web服务）。
假设
1）浏览器和Web服务器通信受SSL连接（HTTPS）保护。
2）建立WebServer和WebService之间连接的网络被视为可信网络，假设您在Web服务器网络（DMZ）和Web服务网络（特权网络）之间有某种防火墙。
3）Web服务当然只能在Web服务器的同一网络中访问。
4）任何人都可以与Web服务进行通信，因为它不会对您可以联系到他的计算机执行任何类型的身份验证，尽管这不是系统A的问题，所以这只适合您知道，不需要考虑它。
答案 0 :(得分：5)
执行SQL的系统始终负责确保SQL完成预期的工作。
因此，如果系统B不能通过注入改变预期的SQL，那么系统B绝对有责任防止这种情况发生。
答案 1 :(得分：3)
只有与数据库实际对话的代码（即系统B）才应该关注防止SQL注入（通常只使用绑定参数）。
更高级别的任何东西都无法有效防止SQL注入 - 它实际上不知道正在使用什么类型的数据库服务器，因此无法防止特定于服务器的攻击，它不会知道应用程序实际上是如何使用参数的（它可能是在SQL中使用它们之前将两个字段连接在一起）等。
此外，尝试阻止较高级别的SQL注入会产生误报的高风险。这可能不会影响某些应用程序（例如，仅由数字组成的表单），但对于任何需要处理任意文本的内容，错误级别的SQL注入保护很可能会错误地阻止' {{1}的完全无害的使用}，;等
答案 2 :(得分：1)
为了补充其他人已经说过的内容，出于各种原因，这绝对是系统B的责任，其中最重要的原因可能是系统A的作者不知道由于解耦而可能出现的适当保护措施。即使系统B在与当前版本的数据库交互时使用纯文本连接，也不能保证在下一个版本中将保留此机制的任何部分。也许根本不会使用数据库，在这种情况下，在系统A中实现的任何与数据库相关的保护都将没有实际意义。
更糟糕的是，人们可能在系统A中实施的“保护”实际上可能导致他们自己的安全漏洞。例如，看到网站限制可用于密码的字符集并不罕见，可能是出于对潜在注入攻击的担忧。鉴于原始密码永远不应该传递给底层数据存储以进行存储或匹配（在这种情况下涉及系统B），如果身份验证系统设计得很好，则不会通过限制密码字符集来提供实际保护。但是，限制字符集会产生减少潜在密码熵的有害影响，从而使系统更少整体安全。
尽管如此，虽然系统B中潜在的SQL注入漏洞并不是您作为系统A的实施者的责任，但可能是某个整体系统所有者正在推动依赖系统B进行身份验证的决策。应将系统B漏洞传达给系统所有者，以便就是否修复系统B，切换到备用身份验证服务或接受漏洞（不特别推荐最后一个选项）做出适当的决定。
答案 3 :(得分：0)
在这种情况下，系统B应该处理输入验证。如果系统A确实输入了用于防止注射的验证，那么明天如果你还有一个与B对话的新接口C，那么你将有相同的问题需要修复。因此，对SQL交互有更多控制权的实体应该处理这个问题。