关于cookie的安全性问题

最近在学习cookie和session的基础知识，在这过程中涉及到cookie的安全性问题时总是很疑惑，很多文章都会涉及到安全性的问题，但是总是一句话带过，并没有详细说到底是怎么回事，比如我看到别人的观点：

服务器鉴别session需要至少从客户端传来一个session_id，session_id通常存于cookie中，或是url（很少用url，主要涉及安全性和SEO的影响）

所以在工程上session离了cookie基本没法用，但是cookie可以单独使用，不过cookies是明文存储，安全性很低，只使用cookie的话盗取了cookie基本就获取了用户所有权限。

亦或者

某个用户竟然在凭证上伪造了内容，让服务器哥误认为他是某个用户（这个时候凭证是明文，该起来非常方便），然后被伪造的那个用户的信息泄漏了

当我看到这些的时候总是不太清楚到底是怎么回事，以上面的例子为例，假如有人可以伪造cookie的内容那就算使用session，也可以有人伪造session_id啊，所以很疑惑。。

另外，大家可以具体讲下用户填写账号密码并提交表单后，服务器验证的具体过程吗？（是根据session_id从内存或者数据库中取出账号密码进行对比？）

感激不尽~

html

chrome firefox

阅读 21.2k

9 个回答

eechen

用于识别身份的cookie应该设置为HttpOnly,也就是禁止通过JS操作这个cookie,这样可以避免网站因为XSS漏洞而导致用户的cookie被XSS收集.

另一个方面,如果要防止cookie被中间人劫持,还得上HTTPS加密通信,这就得购买CA证书(受制于人)和配置Web服务器了,cookie里也有这个配置,就是secure,比如:

setcookie('sessid', 'uniqid', time()+3600, '/', '', true, true);
//上面这句PHP设置cookie的代码将生成类似下面的响应头
//Set-Cookie: sessid=uniqid; expires=Wed, 07-Sep-2016 12:08:22 GMT; path=/; secure; httponly

楼主还有一个疑问就是cookie怎么避免被伪造?
要搞清楚这个问题,就要了解cookie的认证过程:

//保护用户密码的盐(用户注册或修改密码时生成)
$salt = sha1(uniqid($user_id.'_'.getmypid().'_'.mt_rand().'_', true));

//数据库保存的用户密码($pwd_user是用户输入的密码明文)
$pwd_db = sha1($salt.sha1($pwd_user));

//cookie里的盐
//其中$global_salt是配置里config.php定义的全局盐,用来保护用户的盐,一旦修改,所有用户的cookie都将失效.
$cookie_salt = sha1($global_salt.sha1($salt));

//最终生成的cookie内容
$cookie = base64_encode($user_id.'|'.$cookie_salt);
//如果你需要高安全性,还可以使用AES对整个cookie的内容做一次加密.
//https://segmentfault.com/q/1010000006884052/a-1020000007074076
//$cookie = openssl_aes_encrypt($cookie, $key);
这里把过期时间设为604800秒(60*60*24*7,一周)
setcookie('sessid', $cookie, time()+604800, '/', '', false, true);

//解密cookie
//$cookie = openssl_aes_decrypt($_COOKIE['sessid'], $key);

//解码分割后拿到里面的$user_id和$cookie_salt
//根据$user_id查询$salt拼出$cookie_salt,然后跟cookie里的$cookie_salt做对比,一致则通过cookie认证.
$cookie = explode('|', base64_decode($_COOKIE['sessid']));
list($user_id, $cookie_salt) = $cookie;

可见因为有随机且唯一并经过哈希的盐(以及AES加密),所以cookie是很难伪造的.
根据cookie里的ID查询数据库用户表对应的盐,并与cookie中的盐比对,一致则通过用户身份认证.

木槿

34042030

发布于
2016-11-02

大家回答的都差不多了，我来说说个人对cookie安全加密的一些看法。

cookie一般情况下用于记录用户登录状态的，比如userid，千万不要记录密码，由于cookie是存储在客户端的，所以cookie很容易被人劫持修改。比如登录成功后在客户端写入cookie('userid') = 1，在服务器读取cookie userid的值，如果userid在数据库用户表中可以找到则证明当前用户userid为1且合法登录，显然这样是不可行的。如果用户自行修改userid为2或者其它用户的userid，那么服务器就认为当前合法登录的用户userid为2，这样用户就不需要知道userid为2的密码就合法登录了，修改cookie可以通过直接修改浏览器cookie文件或者通过JavaScript修改cookie值达到欺骗服务器的目的，所以需要对存储在客户端的cookie要进行加密。

提到加密可能大家首先想到MD5，通过MD5算法对userid进行加密然后存储在客户端cookie中，由于MD5是不逆的，所以服务器在收到cookie(‘userid’)的时候也不可以解密，那么服务器应该在用户数据表中添加一个字段专门存储MD5加密后的userid，然后通过SQL查询到userid。虽然MD5是不可逆的，但是MD5还是可以暴力破解的，尤其是对于userid这种纯数字的，比如userid为12345，MD5加密后的值为827CCB0EEA8A706C4C34A16891F84E7B，我们把加密后的值放到http://www.cmd5.com/中解密看看，不到2秒结果12345就出来了。如果用户知道了你的userid只是经过了一次MD5加密，那么用户随便对一个已经存在的userid进行MD5加密，然后伪造cookie(‘userid’)，此时服务器会认为用户为合法用户了，获取了其它用户的权限。那么我的建议是对userid进行两次MD5加密或者加一个复杂的key，因为越复杂MD5暴力破解就越慢，如果暴力破解需要2万年那就没有任何意义了。

上面提到的使用已知加密算法（如MD5）还是有漏洞的，最好的是自己编写一套加密算法，这样用户就无法伪造其它用户了。当然了不是每个人都有编写加密算法的能力，我们还是可以用DES加密算的，DES加密需要密钥，而且还可以解密，当用户登录成功后使用预先设置好的密钥对userid进行DES加密，然后存储到客户端cookie中。服务器读取cookie(‘userid’)时在服务器端使用相同的密钥进行DES解密，然后取得userid，由于用户不知道密钥（密钥存储在服务器上），所以用户也无法伪造成其它用户了。我的项目用的是Thinkphp框架，采用的Thinkphp自带的加密算法。此外为了防止用户通过javascript修改伪造cookie，可以设置cookie的httponly属性为true，这样cookie就只能通过服务器读取不能通过javascript读取了，也防止了恶意用户通过XSS跨站脚本攻击获取其它用户的cookie信息，一定程度上提示了安全性。

别以为这样就万事大吉了，既然不能伪造cookie了，但还是可以通过抓包获取其它用户的cookie的，毕竟cookie是在网络中传输的，那怎么办呢？可以用https协议代替普通http协议，这样恶意用户抓到的报文已经是密文了，也就不知道cookie了。

huahuadavids

6691716

发布于
2016-11-01

点击登录后，浏览器会自动把你的cookie放在请求头（request headers)里，一起发送给服务器

然后服务器就会验证你的cookie有没有过期，不合法之类的。。。

wardoggie

29147

发布于
2016-11-01

更新于
2016-11-01

在强调cookie，session区别时。一般意味着cookie只包含原始用法，在头文件里设置键值对。方便服务器追踪。返回响应时同时返回cookie，前端页面也能‘回想起’用户在上一次加载页面时干了什么。相当于给无状态的http协议，打了个状态补丁。
比如说上次退出在用户设置界面，这次进入www.foo.com直接转到用户设置。或者是保留偏好设置，皮肤选项什么的。
使用cookie来登陆，指的是服务器验证后，直接在cookie中写入username:laowang;这样简单的记录方式。cookie能对上号就认定这个用户代理就是某个用户在使用。坏人只需要窃取这几条cookie，就可以在任何地方模拟是laowang的账号了。即便给这几条cookie加密，但是不会改变cookie和账号一一对应的关系，偷cookie，改头信息===获得访问权限。

http协议对各种代理设备，中转路由又完全是明文的。非常容易中途被复制一份cookie。

现在常用session技术可以看作对cookie的一个封装，或者说应用。具体实现可能不同。大概就是客户端post账号密码后，验证通过，服务器写一条数据在服务器本地标记xxx正在线上。两边互相确认身份本质上还是通过cookie。好处是服务器可以在一段时间无请求时，清理掉记录，防止其他人伪造cookie登陆。中途也可以设置策略临时改变用以验证身份的cookie内容。
具体能有多安全，看服务器session的实现。
segment fault里面关于session原理的问题还是挺多的，可以搜索试试。https://segmentfault.com/a/11...

可以这样区分，假设你在一个化装舞会，大家按主办方要求全部打扮得一样。你为了确认你的同伴，约定了一个暗号就是cookie。任何人听到了都可以来冒充是你的同伴。session就是每次对暗号后都换个新暗号，你朋友走了还会告诉你一声不要继续和别人对暗号了。
有点hack的感觉，其实也不是绝对安全。
只能说大多数时候够用，真正机密信息都是靠证书，特定二进制文件或者其他协议。
要安全可以考虑上https，直接简单写cookie也没关系。都是明文的锅。

session可以看作是一条生命周期非常有限的cookie，作用在服务端。cookie技术则主要是指用http头信息记录用户在浏览器中的行为，多数时候用来给前端页面增强功能，也可以提供广告定制一类的服务。

术语不严谨，旨在理解精神。?
我开始的时候还蛮容易把服务器session的概念和HTML5的sessionStorage搞混的。注意用途不一样。

JayChen

1k6

发布于
2016-11-01

也可以有人伪造session_id啊

没错,session_id可以伪造,但是,session的有效期一般比较短,(有一些网站,你访问之后没有退出,静静的放着,过个1,2个小时可能就会提示你重新登录,就是因为session过期了.)一般鉴于session_id的有效时间比较短,所以没什么大碍.

登录过程

首次提交用户密码以及记住密码选项到服务器,从数据库验证,成功返回两个cookie,一个是session_id的cookie,一个是用于下次登录免输入密码的cookie
登录之后浏览网页,每次都会携带session_id到服务器,验证身份.如果服务器设置了session过期时间为2个小时,那么两个小时之后,你的账号就会强制被退出了,因为你的session过期了.
下一次登录的时候,浏览器会携带上次账户密码登录获取到的cookie,服务器对这个cookie进行验证,成功的话就直接登录,失败就进行账户密码的登录.一般说的cookie泄露是指这个cookie泄露.

linong

29.2k1164130

发布于
2016-11-02

谢邀。
上面的回答基本已经说差不多了。
cookie的保存在本地时间比较久，有可能别人获取到了，还可以继续使用
session是在服务器存，一般就是登陆信息，cookie里面存个session标识，session过期时间是服务器设置的。一般为了服务器的性能，过期时间都在三十分钟以下。
你总不能说你的电脑实时被监控吧，实时被监控，也就不用什么cookie截获了，直接电脑什么都是透明的了。