SQL注入谁来处理? [英] SQL Injection who should handle it?
问题描述
在关注点分离方面，我想知道您对处理SQL注入攻击的关注点是系统A还是系统B的关注点，让我解释一下:
系统 A - 您被要求实现 Web 界面，负责确定身份验证，即确定用户是否存在且其密码是否匹配.要执行此操作，您会被告知要确定用户是否存在且有效(密码验证)，您必须调用 Web 服务(系统 B).
所以系统 A 只是一个 HTML 和 JS 接口，用于将数据发送到服务器代码，例如 PHP 页面，从 PHP 页面接收输入并将其传递给 Web 服务，然后等待响应.
在那之后，您假设您可以与它通信并且您只能获得一些统计数据.记住您使用 cookie 的用户.
系统 B - Web 服务不是您的责任，它是一个以前开发的系统，已经工作了很长时间，除了 WSDL 规范之外，您对它一无所知.>
后来，安全团队测试您的界面并说嘿，您允许 SQL 注入，您的界面有问题，它应该清理输入以防止 SQL 注入！！！".
问题?
<块引用>所以，知道你已经了解情况，我问你们，在网络安全最佳实践和关注点分离条款，系统 A 应该是对 Web 一无所知的接口/代理服务强调持久化技术，防范SQL注射还是不注射?！
如果有一些最佳实践与我的观点相矛盾，请您指出来好吗?
我的意见
<块引用>我的观点是，不，这种情况下的接口是 Delegator of责任，旨在成为用户群之间的代理规范(WSDL)和更简单的界面(网页)，它不是旨在将此接口作为某种防火墙之间的Web 服务和客户端(客户端 > Web 服务器 > Web 服务).
假设
1) 浏览器和 Web 服务器的通信通过 SSL 连接 (HTTPS) 得到保护.
2) WebServer 和 WebService 之间建立连接的网络被认为是可信网络，假设您在 Web 服务器网络 (DMZ) 和 Web Service 网络(特权网络)之间有某种防火墙.
3) Web 服务当然只能在 Web 服务器的同一网络内访问.
4) 任何人都可以与 Web 服务交谈，因为它不强制任何类型的身份验证，您可以联系到他的机器，尽管这不是系统 A 的问题，所以这只是让您知道，无需考虑.
只有实际与数据库对话的代码(即系统 B)才应该关注防止 SQL 注入(通常，仅通过使用绑定参数).
任何更高级别的东西都无法有效地防止 SQL 注入 - 它实际上不知道正在使用哪种数据库服务器，因此它无法抵御特定于服务器的攻击，它不会了解应用程序实际上是如何使用参数的(在 SQL 中使用它们之前，它可能将两个字段连接在一起)等.
此外，尝试在更高级别阻止 SQL 注入会导致误报的风险很高.这可能不会影响某些应用程序(例如仅由数字组成的表单)，但是对于需要处理任意文本的任何内容，错误级别的 SQL 注入保护很可能会错误地阻止对 ' 的完全无害的使用，;、--等
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.
这篇关于SQL注入谁来处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
