SQL注入谁应该处理它?

Joã*_*nho 1 security sql-injection separation-of-concerns

在关注点分离方面,我想知道您对处理SQL注入攻击的问题是否是系统A或系统B的关注的看法,让我解释一下:

系统A - 您被要求实施Web界面,负责确定身份验证,这是确定用户是否存在且密码是否匹配.要执行此操作,您要告知,要确定用户是否存在且有效(密码验证),您必须调用Web服务(系统B).

因此,系统A只是一个接口HTML和JS,它将数据发送到服务器代码,例如PHP页面,然后从PHP页面接收输入并将其传递给Web服务,然后等待响应.

之后,您假设您可以与之通信,并且只获得一些统计数据.要记住用户,请使用cookie.

系统B - Web服务,不是你的责任,是一个以前开发的系统已经工作了很长时间,除了它的WSDL规范之外你对它一无所知.

稍后,一个安全团队,测试你的界面并说'嘿,你允许SQL注入,你的界面有问题,它应该清理输入,以防止SQL注入!!!'.

题 ?

所以,知道你了解情况,我问你们,在网络安全最佳实践和分离问题方面,如果系统A,对Web服务一无所知的接口/代理,强调持久性技术, SQL注入与否?!

如果有一些最好的做法与我的意见相矛盾,你能指点我吗?

我的看法

我的观点是,NO,在这种情况下,接口是责任委托者,并且旨在成为用户复杂规范(WSDL)和更简单的接口(Web页面)之间的代理,它不是用于此接口的Web服务和客户端之间的某种防火墙(客户端> Web服务器> Web服务).

假设

1)浏览器和Web服务器通信受SSL连接(HTTPS)保护.

2)建立WebServer和WebService之间的连接的网络被认为是可信网络,假设您在Web服务器网络(DMZ)和Web服务网络(特权网络)之间有某种防火墙.

3)Web服务当然只能在Web服务器的同一网络中访问.

4)任何人都可以与Web服务进行交谈,因为它不对您可以联系到他的机器执行任何类型的身份验证,尽管这不是系统A的关注,所以这只是让您知道,不需要想一想.

Gum*_*mbo 5

执行SQL的系统始终负责确保SQL执行预期的操作.

因此,如果系统B没有任何人可以通过注入改变预期的SQL,那么系统B绝对有责任防止这种情况发生.