这样能阻止数据库被脱库么？

[MinonHeart]

服务器是否有定向的输入输出能力？比如n（服务器）只能被i输入（接受i数据），只能向o输出（发送数据给o）

如果上述可行，用户～a服务器（用于验证）～b服务器（数据库在这上面）～用户，这种流入流出信息的方式是否能够很好地阻止数据库被脱库？

ㄟ(￣▽￣ㄟ) 没秀下限吧！

我臆想了一下单向传输的特殊性，结果都跑到黑服务器去了。黑服务器又涉及黑客电脑和服务器间的通信问题，而服务器通信我假定是单向的了，也就是说黑客直接面对的服务器并不会向他返回数据，那如何黑？

单向传输中，我设定了两台服务器，算上用户，就相当于两个人要交易，支付宝当担保。买家的钱只能给支付宝，支付宝只能打钱给卖家，卖家只能把货物给买家。（不要说退货的事）整个流程是由买家发出需求，然后完成交易的。并未考虑到卖家发出的我有货的信息（相当于服务器主动推送信息）

睡不着了(⊙﹏⊙)

图

http://z-axis.qiniudn.com/v2ex_0.png

结贴~ 请看#31和#32楼。本贴的回复都很值得看哟 ( •̀ ω •́ )y

如果可以实现楼主假设的传输方式，从本贴的回复来看，安全性会提高很多，脱库、黑服务器也会变得更加困难。问题是想不到可以在理论上进行单向性数据库数据交互的方式，卡在了数据存储这一块了。
————————————————————————————————————
不再回复新增加的回复（已回帖的V2EXer除外）

[lvye]

数据库连接之后，数据传输总是双向的吧。

不管你经过几个跳板，只要用户可以请求数据库，那么就有被脱裤的可能。

[MinonHeart]

@lvye 如果可以单向传输，以上所说的方式能否防止脱库？

[ETiV]

单向传输...App连接上数据库之后读不到数据么...

[MinonHeart]

@ETiV 可以由下一个数据库返回数据，上面那个用于验证的服务器也有数据库，只是那不是脱库者想要的

[kslr]

@MinonHeart 单向传输？它怎么知道我想要的。

[10iii]

无论是一台还是数台服务器，都可以看作一个整体。只要这个整体是接受外部输入的，都有被入侵的风险。服务器之间以功能来隔离是可以从某种程度上降低某些方面的风险，但说杜绝，远远远远仍未够班。

[MinonHeart]

@kslr 没懂你的意思

[lvye]

@MinonHeart 用户向数据库请求数据，你怎么保证这个行为不是脱裤？

[MinonHeart]

@10iii 那把输入输出分配给两台服务器是不是会比在一台上风险要小？当然这里假定可以单向传输

[zhujinliang]

你加了一个人来传话，但怎么保证传话的那个人不会被收买呢

[MinonHeart]

@lvye 用户发送请求到a，a验证通过后向b发送所要请求的数据和要返回数据的地址。上面假设的是单向传输，也就是a并不会向用户返回数据，那么要怎么脱呢？

[MinonHeart]

@zhujinliang 这个相当于a被黑掉了吧！脱裤用黑服务器么？被黑相当于获得最好权限，这个似乎无解

[lvye]

@MinonHeart 我不知道a是怎么验证，现在不讨论怎么突破验证。假定我是黑客，我通过脚本请求用户数据，然后你饶了一圈返回给我。那我是不是拿到了用户数据，完成了脱裤呢？

[MinonHeart]

@lvye 不知道黑客是如何办到的，假设你说的可以办到。假定a只验证用户名和密码，黑客通过了a请求b，并返回了数据（比如：姓名，电话之类的）。

那么问题是黑客如何拿到用户名和密码（a只能向b发送数据，也就是不好脱库。黑掉a？黑掉过程中的数据传输由a独立完成？这个范围太宽泛了），这个数据只在a上，要拿到必须由b返回，这之前要通过a的验证，这样就矛盾了

[wzxjohn]

楼主完全不懂脱裤的原理，图样图森破啊。。。

[lvye]

@MinonHeart 你的a就相当于是ids，验证危险数据。一般来说ids很难突破，但是仔细研究还是可以的。其实很多脱裤都是拿下员工的，稍微花点心思在钓鱼邮件上，定向发个钓鱼邮件，总有员工会中招。
其实一般来说，都还会有应用层，黑客一般都是拿下应用层，得知数据库信息，然后发送请求脱裤。
如果你只有一个数据库，当然很基本上不可能脱裤，除非爆破。

[MinonHeart]

@wzxjohn 哈哈，说的对

[pimin]

你的裤子一直在你身上，黑客拿走的只是你睡着时候的果照

[MinonHeart]

@lvye 前面那算保护不力，无解。

至于应用层(T_T)你是建立在双向传输的基础上？

[MinonHeart]

@pimin 黑客手的只能伸出去，收不回来，怎么解决

[pimin]

@MinonHeart 用户跟你请求数据你给不给？
黑客就是用户！你给不给？

[MinonHeart]

@pimin 你先看看上面的回复，我再给

[whywhywhy]

oauth就是专门干这个的 比如说qq开放了登陆api，任何其他网站都可以申请api。

用这个api提交数据，服务器返回是否给你授权

给了授权就说明验证成功

其他网站并不知道密码是什么，只知道给了授权就是没问题的（甚至不知道被授权的qq号码是多少）

也就是授权部分单独放一个服务器，这样其他部分有bug就影响不到你的授权（账号）服务器了，因为其他部分一般来说功能越强大，越可能出现bug。

当然啦，这样单独放置账号服务器，因为账号验证的api很简单，一般不会出现什么bug被脱裤，那么就显得很安全了，然后数据库的用户密码再采用非常规的加密方式（比如说稍微改动下md5和sha1的算法），就算被脱裤，对方不知道算法也没戏，更悲剧的就是算法也被对方得到了，那也没关系，知道算法也只能一个个去暴力破解，效率低下

再悲剧就没办法了，对方拿着你的算法，拿着你的密钥，再拿着你的数据库，再多想什么都没有意义了。

[egen]

被脱裤，很多是数据库服务器被黑，也就是楼主所说的b服务器被黑，整个数据库被直接下载

如果要通过一个一个地请求来获取用户数据比较费力，防范方法应该也比较多

[MinonHeart]

@egen 你说的岂不是a和b有数据交互嘛！但是现在是单向的考虑的

[MinonHeart]

@whywhywhy 同楼上

[MayLava]

@MinonHeart 不需要ab之间有交互，只要掌握了规则骗过a，让a以为你是正规的请求，那么b自然会傻傻的把数据传给你。

[MinonHeart]

@MayLava 正规请求不就是要脱库a嘛！要不然也不会正规通过验证，那问题是如何脱库a呢？a是不会向请求者返回数据的

[usedname]

我觉得楼主还是把网线拔了比较靠谱

[MinonHeart]

@usedname 我觉得不要电脑更好o(^▽^)o

[whywhywhy]

@MinonHeart 要单向的传输（只返回密码是否正确，不返回密码的明文或者密钥），我给你举个例子

a服务器(作为发起请求的一端)
b服务器(账号密码所在服务器，接受查询账号密码是否正确)

用户名abc
密码123

方法1
a网站没有存储账号密码，也不知道服务器上真实的用户密码是什么，每次查询的时候向服务器发送账号密码，或者不发送密码，只发送签名

a服务器接受用户输入的数据，比如说abc，123，那么如何知道正确与否？一般情况下是对比数据库里的值，这里账号密码数据库不在a服务器上，无法直接对比（对比就要取出数值）。
现在a服务器要验证账号密码是否正确就要向b服务器发起请求（在后端发起请求，避免被客户端劫持数据），比如说请求http://xxx.xx/login?user=abc&password=123，服务器返回数字1为验证通过，返回0为验证失败。
在这样的情况下，a服务器即便被盗，被拿到root权限，拿到数据库，也不知道密码是什么（当然a服务器偷偷记录下用户的密码那就是另外一回事了）
这里你可能要说了，密码不是被发送到服务器了吗，还是明文的，这样安全吗？（一般不会用http传输，会用https传输，防止服务器端被机房其他机器或者网关劫持）
总结：服务器后端传输密码，需注意服务器端所在网络是否劫持，当然了https一般情况是无法劫持的

方法2
a服务器不向b服务器发送密码，只发送签名，这样双方都不知道对方所知道的账号和密码
何为签名？那就是a服务器用abc和123进行hash处理（一般为了防止每次hash都一样，会带上时间戳，并限制时间在当前时间的一定范围之内，比如一般会要求双方服务器时间差距不能超过60秒或者30秒）。比如说md5，或者sha1。下面我以md5为例子（算法md5(abc+123)）。
http://xxx.xx/login?user=abc&time=xxxxxxx&hash=A6091522F955F170
b服务器获取abc，然后查询数据库里的abc的密码，进行同样的hash计算(我md5没带上时间戳，正常情况是要带上时间戳一起运算，服务器需要对时间进行判断，不能超过当前时间的一定范围)，最后对比a服务器发来的hash是否一致，一致的话。返回1代表正确，返回2代表错误
总结：双方服务器都不知道对方所知的密码是什么，传输也不带密码，安全性很高！

方法3
a服务器不知道用户在b服务器输入了什么账号什么密码
a服务器需要验证用户账号的地方跳转到B服务器，并带上一个随机生成的字符串，比如sdfht32sh38作为会话id的依据（比如跳转到b服务器的网址http://xxx.xx/login?id=sdfht32sh38），然后用户在b网站进行登录操作，b服务器验证用户密码是否正确，正确则在用户浏览器跳转回a服务器，并且在后端请求a服务器，把结果发送过去，以及本次的id就是sdfht32sh38，并且提供用户特征（为防止a服务器得知用户的用户名后跑到b服务器去破解，所以只给特征，比如说cba，如果在必须知道用户名的情况下，返回用户名，并且返回一个签名，确保本次通讯的可靠性，一般是a服务器有一个证明自身的用户名和密码，双方才可以此确保请求是否是对方发来的，并非虚假的请求，所以一般服务器通讯的时候也会带上这个用户名）
总结：a服务器不知道用户在b服务器输入了什么账号什么密码，只知道登录用户的特征，只知道对方登录是通过验证的。如果用户输入的账号和密码错误，a服务器得不到任何东西。

方法3也是各大网站登录api的原理，算法可能更加高级，但是过程大概就是这样，包括银行网上交易，网上付款也是同样的过程！所以安全性可以说非常高。

当然啦，也不是没有破解的方法啊，比如a服务器模拟b服务器的页面给用户，用户以为自己是在b服务器，实际上是在a服务器……

所谓拖库，一般是能连上账号密码所在服务器，然后导出用户信息，一般来说，现在都会对用户密码进行hash处理并且加入随机字符串。所以黑客能得到的只是一个加密后的字符串，无法进行破解，当然了，如果黑客还拿到了这个密文的运算方式（比如知道我是md5(abc+123)这样计算，就可以自己写算法来进行破解，拖库不一定知道算法，但是算法和密文都知道的话……那破解只是时间问题了，除非密码非常复杂，或者算法非常耗时，才能防止被破解）

再当然了，因为网页的话都是服务器先发送登录页面代码给用户，如果在这做手脚的话，什么算法什么安全方式都扯淡。

[MinonHeart]

@whywhywhy 谢谢科普。看了以上，想到一个问题是服务器上的数据库依然是双向的，即A服务器对A上的数据库拥有读写权限，无法把读写分开，导致单向性的假设不成立。我附了一张图，不妨看一下，当然图是错误的。

[whywhywhy]

@MinonHeart md5 sha1等算法 本身就是单向的 这么担心拖库 直接交给qq或者别的来处理授权问题吧 这样绝对是”单向通讯“ 腾讯家的安全你信我信大家信……

申请qq登录api接口

http://connect.qq.com/intro/login

啥，qq不信任？没关系，google,微软,推特，豆瓣……大把大把的都支持这种方式代替你自己的账号系统，绝对让你放心无忧。

什么？交给别人不安全？？？？？那么我们又要回到这个主题，单向传输，单向查询……又要自己搞？好吧我们再来谈谈拖库的危害……

[duzhe0]

楼主这个方案显然自己都没有想清楚。 拿张纸自己画一画， 再理一理。
不过楼主有一点是对了， 安全的核心是“限制”， “限制”可以提高安全性，也会降低易用性，所以"限制"的合理程度也很重要。理论上100%的安全不可能达到。

[duzhe0]

"限制"的程度

[est]

数据库直接权限控制禁止dump就好了。

[9hills]

TCP是双向的。。单向搞不定啊

[GeekGao]

哎哟 这么麻烦干嘛，你这方案完全是反模式啊，正常的生产场景中，数据库的数据流哪有单项传输的，防止数据库暴漏干脆做个安全的API server，然后API server和数据库server加安全审计。

[MayLava]

@MinonHeart 拿你说的图来做分析。攻击者可以通过抓包得到用户发请求给a的规律，然后攻击者可以试着给a发请求，假如b返回了数据，那么请求就成功了；如果没反应那就说明验证不通过，这就是一个调试的过程了。

再者，入侵服务器本来就是通过各种方式来查出服务器的漏洞，只要坏孩子找到了一种发送特定请求就能骗过a验证的方法就可以了。我觉得你不要纠结于a不返回任何数据这一点，因为事实上这只是将请求输入与数据返回分成了ab两个部分而已。攻击者判断是否骗过了a的标志是b有没有返回数据。