V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
这是一个专门讨论 idea 的地方。

每个人的时间,资源是有限的,有的时候你或许能够想到很多 idea,但是由于现实的限制,却并不是所有的 idea 都能够成为现实。

那这个时候,不妨可以把那些 idea 分享出来,启发别人。
MinonHeart
V2EX  ›  奇思妙想

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

  •  
  •   MinonHeart · 2014-09-28 23:30:02 +08:00 via Android · 6775 次点击
    这是一个创建于 3708 天前的主题,其中的信息可能已经有所发展或是发生改变。
    服务器是否有定向的输入输出能力?比如n(服务器)只能被i输入(接受i数据),只能向o输出(发送数据给o)

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

    ㄟ( ̄▽ ̄ㄟ) 没秀下限吧!
    第 1 条附言  ·  2014-09-29 01:08:45 +08:00
    我臆想了一下单向传输的特殊性,结果都跑到黑服务器去了。黑服务器又涉及黑客电脑和服务器间的通信问题,而服务器通信我假定是单向的了,也就是说黑客直接面对的服务器并不会向他返回数据,那如何黑?

    单向传输中,我设定了两台服务器,算上用户,就相当于两个人要交易,支付宝当担保。买家的钱只能给支付宝,支付宝只能打钱给卖家,卖家只能把货物给买家。(不要说退货的事)整个流程是由买家发出需求,然后完成交易的。并未考虑到卖家发出的我有货的信息(相当于服务器主动推送信息)
    第 2 条附言  ·  2014-09-29 01:25:53 +08:00
    睡不着了(⊙﹏⊙)
    第 3 条附言  ·  2014-09-29 11:17:34 +08:00
    第 4 条附言  ·  2014-09-29 12:02:43 +08:00
    结贴~ 请看#31和#32楼。本贴的回复都很值得看哟 ( •̀ ω •́ )y

    如果可以实现楼主假设的传输方式,从本贴的回复来看,安全性会提高很多,脱库、黑服务器也会变得更加困难。问题是想不到可以在理论上进行单向性数据库数据交互的方式,卡在了数据存储这一块了。
    ————————————————————————————————————
    不再回复新增加的回复(已回帖的V2EXer除外)
    39 条回复    2014-09-30 01:28:09 +08:00
    lvye
        1
    lvye  
       2014-09-28 23:38:02 +08:00 via Android
    数据库连接之后,数据传输总是双向的吧。

    不管你经过几个跳板,只要用户可以请求数据库,那么就有被脱裤的可能。
    MinonHeart
        2
    MinonHeart  
    OP
       2014-09-28 23:44:35 +08:00 via Android
    @lvye 如果可以单向传输,以上所说的方式能否防止脱库?
    ETiV
        3
    ETiV  
       2014-09-28 23:49:34 +08:00
    单向传输...App连接上数据库之后读不到数据么...
    MinonHeart
        4
    MinonHeart  
    OP
       2014-09-28 23:54:34 +08:00 via Android
    @ETiV 可以由下一个数据库返回数据,上面那个用于验证的服务器也有数据库,只是那不是脱库者想要的
    kslr
        5
    kslr  
       2014-09-28 23:57:39 +08:00
    @MinonHeart 单向传输?它怎么知道我想要的。
    10iii
        6
    10iii  
       2014-09-28 23:59:41 +08:00
    无论是一台还是数台服务器,都可以看作一个整体。只要这个整体是接受外部输入的,都有被入侵的风险。服务器之间以功能来隔离是可以从某种程度上降低某些方面的风险,但说杜绝,远远远远仍未够班。
    MinonHeart
        7
    MinonHeart  
    OP
       2014-09-29 00:00:02 +08:00 via Android
    @kslr 没懂你的意思
    lvye
        8
    lvye  
       2014-09-29 00:02:36 +08:00 via Android
    @MinonHeart 用户向数据库请求数据,你怎么保证这个行为不是脱裤?
    MinonHeart
        9
    MinonHeart  
    OP
       2014-09-29 00:10:30 +08:00 via Android
    @10iii 那把输入输出分配给两台服务器是不是会比在一台上风险要小?当然这里假定可以单向传输
    zhujinliang
        10
    zhujinliang  
       2014-09-29 00:10:54 +08:00 via Android
    你加了一个人来传话,但怎么保证传话的那个人不会被收买呢
    MinonHeart
        11
    MinonHeart  
    OP
       2014-09-29 00:15:44 +08:00 via Android
    @lvye 用户发送请求到a,a验证通过后向b发送所要请求的数据和要返回数据的地址。上面假设的是单向传输,也就是a并不会向用户返回数据,那么要怎么脱呢?
    MinonHeart
        12
    MinonHeart  
    OP
       2014-09-29 00:19:25 +08:00 via Android
    @zhujinliang 这个相当于a被黑掉了吧!脱裤用黑服务器么?被黑相当于获得最好权限,这个似乎无解
    lvye
        13
    lvye  
       2014-09-29 00:22:23 +08:00 via Android
    @MinonHeart 我不知道a是怎么验证,现在不讨论怎么突破验证。假定我是黑客,我通过脚本请求用户数据,然后你饶了一圈返回给我。那我是不是拿到了用户数据,完成了脱裤呢?
    MinonHeart
        14
    MinonHeart  
    OP
       2014-09-29 00:53:44 +08:00 via Android
    @lvye 不知道黑客是如何办到的,假设你说的可以办到。假定a只验证用户名和密码,黑客通过了a请求b,并返回了数据(比如:姓名,电话之类的)。

    那么问题是黑客如何拿到用户名和密码(a只能向b发送数据,也就是不好脱库。黑掉a?黑掉过程中的数据传输由a独立完成?这个范围太宽泛了),这个数据只在a上,要拿到必须由b返回,这之前要通过a的验证,这样就矛盾了
    wzxjohn
        15
    wzxjohn  
       2014-09-29 00:55:29 +08:00 via iPhone
    楼主完全不懂脱裤的原理,图样图森破啊。。。
    lvye
        16
    lvye  
       2014-09-29 01:05:19 +08:00 via Android   ❤️ 1
    @MinonHeart 你的a就相当于是ids,验证危险数据。一般来说ids很难突破,但是仔细研究还是可以的。其实很多脱裤都是拿下员工的,稍微花点心思在钓鱼邮件上,定向发个钓鱼邮件,总有员工会中招。
    其实一般来说,都还会有应用层,黑客一般都是拿下应用层,得知数据库信息,然后发送请求脱裤。
    如果你只有一个数据库,当然很基本上不可能脱裤,除非爆破。
    MinonHeart
        17
    MinonHeart  
    OP
       2014-09-29 01:11:00 +08:00 via Android
    @wzxjohn 哈哈,说的对
    pimin
        18
    pimin  
       2014-09-29 01:11:43 +08:00
    你的裤子一直在你身上,黑客拿走的只是你睡着时候的果照
    MinonHeart
        19
    MinonHeart  
    OP
       2014-09-29 01:16:52 +08:00 via Android
    @lvye 前面那算保护不力,无解。

    至于应用层(T_T)你是建立在双向传输的基础上?
    MinonHeart
        20
    MinonHeart  
    OP
       2014-09-29 01:18:52 +08:00 via Android
    @pimin 黑客手的只能伸出去,收不回来,怎么解决
    pimin
        21
    pimin  
       2014-09-29 01:21:28 +08:00
    @MinonHeart 用户跟你请求数据你给不给?
    黑客就是用户!你给不给?
    MinonHeart
        22
    MinonHeart  
    OP
       2014-09-29 01:24:02 +08:00 via Android
    @pimin 你先看看上面的回复,我再给
    whywhywhy
        23
    whywhywhy  
       2014-09-29 01:48:56 +08:00
    oauth就是专门干这个的 比如说qq开放了登陆api,任何其他网站都可以申请api。

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

    给了授权就说明验证成功

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

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

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

    再悲剧就没办法了,对方拿着你的算法,拿着你的密钥,再拿着你的数据库,再多想什么都没有意义了。
    egen
        24
    egen  
       2014-09-29 06:16:58 +08:00 via iPhone
    被脱裤,很多是数据库服务器被黑,也就是楼主所说的b服务器被黑,整个数据库被直接下载

    如果要通过一个一个地请求来获取用户数据比较费力,防范方法应该也比较多
    MinonHeart
        25
    MinonHeart  
    OP
       2014-09-29 09:56:51 +08:00
    @egen 你说的岂不是a和b有数据交互嘛!但是现在是单向的考虑的
    MinonHeart
        26
    MinonHeart  
    OP
       2014-09-29 09:57:10 +08:00
    @whywhywhy 同楼上
    MayLava
        27
    MayLava  
       2014-09-29 10:08:06 +08:00
    @MinonHeart 不需要ab之间有交互,只要掌握了规则骗过a,让a以为你是正规的请求,那么b自然会傻傻的把数据传给你。
    MinonHeart
        28
    MinonHeart  
    OP
       2014-09-29 10:28:28 +08:00
    @MayLava 正规请求不就是要脱库a嘛!要不然也不会正规通过验证,那问题是如何脱库a呢?a是不会向请求者返回数据的
    usedname
        29
    usedname  
       2014-09-29 10:56:17 +08:00
    我觉得楼主还是把网线拔了比较靠谱
    MinonHeart
        30
    MinonHeart  
    OP
       2014-09-29 11:08:05 +08:00
    @usedname 我觉得不要电脑更好o(^▽^)o
    whywhywhy
        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)这样计算,就可以自己写算法来进行破解,拖库不一定知道算法,但是算法和密文都知道的话……那破解只是时间问题了,除非密码非常复杂,或者算法非常耗时,才能防止被破解)

    再当然了,因为网页的话都是服务器先发送登录页面代码给用户,如果在这做手脚的话,什么算法什么安全方式都扯淡。
    MinonHeart
        32
    MinonHeart  
    OP
       2014-09-29 11:52:32 +08:00
    @whywhywhy 谢谢科普。看了以上,想到一个问题是服务器上的数据库依然是双向的,即A服务器对A上的数据库拥有读写权限,无法把读写分开,导致单向性的假设不成立。我附了一张图,不妨看一下,当然图是错误的。
    whywhywhy
        33
    whywhywhy  
       2014-09-29 13:56:04 +08:00
    @MinonHeart md5 sha1等算法 本身就是单向的 这么担心拖库 直接交给qq或者别的来处理授权问题吧 这样绝对是”单向通讯“ 腾讯家的安全你信我信大家信……

    申请qq登录api接口

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

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

    什么?交给别人不安全?????那么我们又要回到这个主题,单向传输,单向查询……又要自己搞?好吧我们再来谈谈拖库的危害……
    duzhe0
        34
    duzhe0  
       2014-09-29 14:32:14 +08:00
    楼主这个方案显然自己都没有想清楚。 拿张纸自己画一画, 再理一理。
    不过楼主有一点是对了, 安全的核心是“限制”, “限制”可以提高安全性,也会降低易用性,所以"限制"的合理程度也很重要。理论上100%的安全不可能达到。
    duzhe0
        35
    duzhe0  
       2014-09-29 14:33:06 +08:00
    "限制"的程度
    est
        36
    est  
       2014-09-29 14:37:35 +08:00
    数据库直接权限控制禁止dump就好了。
    9hills
        37
    9hills  
       2014-09-29 14:48:28 +08:00
    TCP是双向的。。单向搞不定啊
    GeekGao
        38
    GeekGao  
       2014-09-30 00:26:31 +08:00
    哎哟 这么麻烦干嘛,你这方案完全是反模式啊,正常的生产场景中,数据库的数据流哪有单项传输的,防止数据库暴漏干脆做个安全的API server,然后API server和数据库server加安全审计。
    MayLava
        39
    MayLava  
       2014-09-30 01:28:09 +08:00
    @MinonHeart 拿你说的图来做分析。攻击者可以通过抓包得到用户发请求给a的规律,然后攻击者可以试着给a发请求,假如b返回了数据,那么请求就成功了;如果没反应那就说明验证不通过,这就是一个调试的过程了。

    再者,入侵服务器本来就是通过各种方式来查出服务器的漏洞,只要坏孩子找到了一种发送特定请求就能骗过a验证的方法就可以了。我觉得你不要纠结于a不返回任何数据这一点,因为事实上这只是将请求输入与数据返回分成了ab两个部分而已。攻击者判断是否骗过了a的标志是b有没有返回数据。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2887 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 08:49 · PVG 16:49 · LAX 00:49 · JFK 03:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.