1
lvye 2014-09-28 23:38:02 +08:00 via Android
数据库连接之后,数据传输总是双向的吧。
不管你经过几个跳板,只要用户可以请求数据库,那么就有被脱裤的可能。 |
2
MinonHeart OP @lvye 如果可以单向传输,以上所说的方式能否防止脱库?
|
3
ETiV 2014-09-28 23:49:34 +08:00
单向传输...App连接上数据库之后读不到数据么...
|
4
MinonHeart OP @ETiV 可以由下一个数据库返回数据,上面那个用于验证的服务器也有数据库,只是那不是脱库者想要的
|
5
kslr 2014-09-28 23:57:39 +08:00
@MinonHeart 单向传输?它怎么知道我想要的。
|
6
10iii 2014-09-28 23:59:41 +08:00
无论是一台还是数台服务器,都可以看作一个整体。只要这个整体是接受外部输入的,都有被入侵的风险。服务器之间以功能来隔离是可以从某种程度上降低某些方面的风险,但说杜绝,远远远远仍未够班。
|
7
MinonHeart OP @kslr 没懂你的意思
|
8
lvye 2014-09-29 00:02:36 +08:00 via Android
@MinonHeart 用户向数据库请求数据,你怎么保证这个行为不是脱裤?
|
9
MinonHeart OP @10iii 那把输入输出分配给两台服务器是不是会比在一台上风险要小?当然这里假定可以单向传输
|
10
zhujinliang 2014-09-29 00:10:54 +08:00 via Android
你加了一个人来传话,但怎么保证传话的那个人不会被收买呢
|
11
MinonHeart OP @lvye 用户发送请求到a,a验证通过后向b发送所要请求的数据和要返回数据的地址。上面假设的是单向传输,也就是a并不会向用户返回数据,那么要怎么脱呢?
|
12
MinonHeart OP @zhujinliang 这个相当于a被黑掉了吧!脱裤用黑服务器么?被黑相当于获得最好权限,这个似乎无解
|
13
lvye 2014-09-29 00:22:23 +08:00 via Android
@MinonHeart 我不知道a是怎么验证,现在不讨论怎么突破验证。假定我是黑客,我通过脚本请求用户数据,然后你饶了一圈返回给我。那我是不是拿到了用户数据,完成了脱裤呢?
|
14
MinonHeart OP @lvye 不知道黑客是如何办到的,假设你说的可以办到。假定a只验证用户名和密码,黑客通过了a请求b,并返回了数据(比如:姓名,电话之类的)。
那么问题是黑客如何拿到用户名和密码(a只能向b发送数据,也就是不好脱库。黑掉a?黑掉过程中的数据传输由a独立完成?这个范围太宽泛了),这个数据只在a上,要拿到必须由b返回,这之前要通过a的验证,这样就矛盾了 |
15
wzxjohn 2014-09-29 00:55:29 +08:00 via iPhone
楼主完全不懂脱裤的原理,图样图森破啊。。。
|
16
lvye 2014-09-29 01:05:19 +08:00 via Android 1
@MinonHeart 你的a就相当于是ids,验证危险数据。一般来说ids很难突破,但是仔细研究还是可以的。其实很多脱裤都是拿下员工的,稍微花点心思在钓鱼邮件上,定向发个钓鱼邮件,总有员工会中招。
其实一般来说,都还会有应用层,黑客一般都是拿下应用层,得知数据库信息,然后发送请求脱裤。 如果你只有一个数据库,当然很基本上不可能脱裤,除非爆破。 |
17
MinonHeart OP @wzxjohn 哈哈,说的对
|
18
pimin 2014-09-29 01:11:43 +08:00
你的裤子一直在你身上,黑客拿走的只是你睡着时候的果照
|
19
MinonHeart OP |
20
MinonHeart OP @pimin 黑客手的只能伸出去,收不回来,怎么解决
|
21
pimin 2014-09-29 01:21:28 +08:00
@MinonHeart 用户跟你请求数据你给不给?
黑客就是用户!你给不给? |
22
MinonHeart OP @pimin 你先看看上面的回复,我再给
|
23
whywhywhy 2014-09-29 01:48:56 +08:00
oauth就是专门干这个的 比如说qq开放了登陆api,任何其他网站都可以申请api。
用这个api提交数据,服务器返回是否给你授权 给了授权就说明验证成功 其他网站并不知道密码是什么,只知道给了授权就是没问题的(甚至不知道被授权的qq号码是多少) 也就是授权部分单独放一个服务器,这样其他部分有bug就影响不到你的授权(账号)服务器了,因为其他部分一般来说功能越强大,越可能出现bug。 当然啦,这样单独放置账号服务器,因为账号验证的api很简单,一般不会出现什么bug被脱裤,那么就显得很安全了,然后数据库的用户密码再采用非常规的加密方式(比如说稍微改动下md5和sha1的算法),就算被脱裤,对方不知道算法也没戏,更悲剧的就是算法也被对方得到了,那也没关系,知道算法也只能一个个去暴力破解,效率低下 再悲剧就没办法了,对方拿着你的算法,拿着你的密钥,再拿着你的数据库,再多想什么都没有意义了。 |
24
egen 2014-09-29 06:16:58 +08:00 via iPhone
被脱裤,很多是数据库服务器被黑,也就是楼主所说的b服务器被黑,整个数据库被直接下载
如果要通过一个一个地请求来获取用户数据比较费力,防范方法应该也比较多 |
25
MinonHeart OP @egen 你说的岂不是a和b有数据交互嘛!但是现在是单向的考虑的
|
26
MinonHeart OP @whywhywhy 同楼上
|
27
MayLava 2014-09-29 10:08:06 +08:00
@MinonHeart 不需要ab之间有交互,只要掌握了规则骗过a,让a以为你是正规的请求,那么b自然会傻傻的把数据传给你。
|
28
MinonHeart OP @MayLava 正规请求不就是要脱库a嘛!要不然也不会正规通过验证,那问题是如何脱库a呢?a是不会向请求者返回数据的
|
29
usedname 2014-09-29 10:56:17 +08:00
我觉得楼主还是把网线拔了比较靠谱
|
30
MinonHeart OP @usedname 我觉得不要电脑更好o(^▽^)o
|
31
whywhywhy 2014-09-29 11:12:19 +08:00 2
@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)这样计算,就可以自己写算法来进行破解,拖库不一定知道算法,但是算法和密文都知道的话……那破解只是时间问题了,除非密码非常复杂,或者算法非常耗时,才能防止被破解) 再当然了,因为网页的话都是服务器先发送登录页面代码给用户,如果在这做手脚的话,什么算法什么安全方式都扯淡。 |
32
MinonHeart OP @whywhywhy 谢谢科普。看了以上,想到一个问题是服务器上的数据库依然是双向的,即A服务器对A上的数据库拥有读写权限,无法把读写分开,导致单向性的假设不成立。我附了一张图,不妨看一下,当然图是错误的。
|
33
whywhywhy 2014-09-29 13:56:04 +08:00
@MinonHeart md5 sha1等算法 本身就是单向的 这么担心拖库 直接交给qq或者别的来处理授权问题吧 这样绝对是”单向通讯“ 腾讯家的安全你信我信大家信……
申请qq登录api接口 http://connect.qq.com/intro/login 啥,qq不信任?没关系,google,微软,推特,豆瓣……大把大把的都支持这种方式代替你自己的账号系统,绝对让你放心无忧。 什么?交给别人不安全?????那么我们又要回到这个主题,单向传输,单向查询……又要自己搞?好吧我们再来谈谈拖库的危害…… |
34
duzhe0 2014-09-29 14:32:14 +08:00
楼主这个方案显然自己都没有想清楚。 拿张纸自己画一画, 再理一理。
不过楼主有一点是对了, 安全的核心是“限制”, “限制”可以提高安全性,也会降低易用性,所以"限制"的合理程度也很重要。理论上100%的安全不可能达到。 |
35
duzhe0 2014-09-29 14:33:06 +08:00
"限制"的程度
|
36
est 2014-09-29 14:37:35 +08:00
数据库直接权限控制禁止dump就好了。
|
37
9hills 2014-09-29 14:48:28 +08:00
TCP是双向的。。单向搞不定啊
|
38
GeekGao 2014-09-30 00:26:31 +08:00
哎哟 这么麻烦干嘛,你这方案完全是反模式啊,正常的生产场景中,数据库的数据流哪有单项传输的,防止数据库暴漏干脆做个安全的API server,然后API server和数据库server加安全审计。
|
39
MayLava 2014-09-30 01:28:09 +08:00
@MinonHeart 拿你说的图来做分析。攻击者可以通过抓包得到用户发请求给a的规律,然后攻击者可以试着给a发请求,假如b返回了数据,那么请求就成功了;如果没反应那就说明验证不通过,这就是一个调试的过程了。
再者,入侵服务器本来就是通过各种方式来查出服务器的漏洞,只要坏孩子找到了一种发送特定请求就能骗过a验证的方法就可以了。我觉得你不要纠结于a不返回任何数据这一点,因为事实上这只是将请求输入与数据返回分成了ab两个部分而已。攻击者判断是否骗过了a的标志是b有没有返回数据。 |