推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 3400 天前的主题，其中的信息可能已经有所发展或是发生改变。
网站希望改成后端只输出json，前端全部ajax请求的模式，也包括登录，那么问题来了
前端这块，用户登录后，登录信息只能保存在cookies里，到期清空，安全性实在是低，有什么好办法吗？
 |
1
582033 2015-08-07 06:44:11 +08:00 via Android
oauth2.0
ssl也有必要. 应该没什么太大问题了吧。 |
 |
2
OpooPages 2015-08-07 07:08:03 +08:00 via Android
大多session也是基于cookie。
如果是非浏览器客户端，或者oauth，每个访问都需要access_toke，其实原理跟cookie差不多。 |
 |
3
cnhongwei 2015-08-07 07:17:05 +08:00 via iPhone
现在所有的认证手段除硬件认证外，都是基于cookie的，怎么会不安全。但在cookie的设计上要防cookie盗用，并兼顾用户跟踪。
|
 |
4
ihciah 2015-08-07 08:20:46 +08:00 via iPhone
没有ssl的话可以考虑淘宝以前的做法，一段时间无用户活动可以提示用户重新登录
|
 |
5
jugelizi 2015-08-07 08:35:36 +08:00
有效期 httponly 加密 就可以了
|
 |
6
ltttx 2015-08-07 09:00:47 +08:00
前后端分离，一般就不用cookie来保证用户认证登录了（比如 native app情况下），一般是基于 token或者 oauth，前者实现更简单点。token （hash）的话，一般是用户通过某种方式认证登录（比如基于https的 http basic 登录），然后返回一个token给用户，以后每次请求都必须带上token进行授权。
|
 |
7
imn1 2015-08-07 09:57:02 +08:00
后端对重要操作二次询问密码，例如查看身份信息，改密码，加密保之类
如果什么操作都重要，那就不该cookies登录 |
 |
8
jiaozi 2015-08-07 10:17:02 +08:00
我们是前端ajax提交到后台，保存到session中的。从来木有用过cookie，都是用session的···
|
|
13
jiaozi 2015-08-07 10:29:21 +08:00
cookie 和session 的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。 2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session。 3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面，应当使用COOKIE。 4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。 将登陆信息等重要信息存放为SESSION 其他信息如果需要保留，可以放在COOKIE中 |
 |
14
breeswish 2015-08-07 10:31:29 +08:00
@jiaozi 然而 session 要通过 cookie 传递的亲……session id 是在 cookie 里的，id 所对应的 data 才是在服务器上..用着 session (基本)就得用 cookie..
|
 |
15
irainy 2015-08-07 10:33:37 +08:00 via iPhone  1
|
|
16
jiaozi 2015-08-07 10:34:00 +08:00
@breeswish cookie是不用写的，用了session，自动在客户端生成的吧。就是觉得登陆信息就应该用session。
|
|
18
breeswish 2015-08-07 10:39:10 +08:00 1
@jiaozi 确实有不用 cookie 传递 session 的办法，可以用 HTTPS Session 传递 Session，可以用 ETags 借助浏览器缓存传递 session，可以用 URL 传递 session，然而 OAuth 以外 99% 以上的 session 都是通过 cookie 传递的…
TCP 自身是无状态的，总要有个地方「持久化记录」一个唯一标示符，浏览器提供的「可以让服务器在客户端保存一段信息以供后续使用」的这个功能叫做 Cookie。 不信你清空 v2ex 上的 cookie 试试..看看 session 是不是丢失了 |
 |
20
sujin190 2015-08-07 11:04:13 +08:00 1
@jiaozi 安全上没什么区别，我既然能伪造cookie保存的登录信息伪造登录，当然也能伪造sessionid伪造登录，反正你要有个信息来源于客户端不是
|
 |
22
Sight4 2015-08-07 11:48:39 +08:00 1
首先，cookie 与 session 是息息相关的，session的标识是通过 cookie 的固定 key获取，比如 session_id 或者 jsession_id 等等，现在很多框架都会帮你实现隐藏的 session 功能。但实际上，在标准的HTTP协议上，根本没有我们所谈论的 session，session 是基于 cookie 的一种HTTP状态维持实现(RFC2109)
其次，在很多精简的后端框架，压根是没有session这个东西，需要实现session，需要自己去写cookie，并且需要自己去序列化session信息保存，比如使用数据库，使用文件，使用缓存等等。而且写入cookie的key可以是你自己定义的任何值，比如 access_token、auth_token、abc或者任何你喜欢的 然后，最近我们做了一个项目，是完整的前后端分离，使用的方法是使用token验证，而且涉及到不同后端应用的反向代理，实现一个分布式的 session 不太现实，我们要求各后端应用的设计各自实现自己的类session状态维持，但实际上，这种设计是不合理的，http的优势反而是无状态。 最后，关于安全问题，除了增加无操作超时机制、多重验证的手段外，最能够防止 cookie 劫持的方法是使用 https。 希望以上信息对你有用。 |
 |
23
CosWind 2015-08-07 13:36:27 +08:00
建议session用redis来做，后面做负载也不用考虑session共享的问题
|
|
24
CosWind 2015-08-07 13:38:01 +08:00
抱歉，没看清楚是网站，惯性以为是app的
|
 |
25
br00k 2015-08-07 14:02:52 +08:00
session的数据是存放在服务端的，但是session ID是写在cookies的。
最简单提升安全度的方式自然是SSL，这样你的session ID就不会被人抓到了。 |
 |
26
Amit 2015-08-07 15:19:57 +08:00
@Sight4
https可以防止cookie劫持，但是考虑极端一点，如果别人可以使用你的浏览器，把cookies记录下来，这样是可以伪造cookies进行登录的吧。如果session设置超时自动销毁还好，但是许多地方都有记住密码功能，用户状态是长期保存的，这样的网站如果伪造了cookies是可以一直保持登录的吧 |
 |
27
freemind 2015-08-07 15:28:52 +08:00
大多数网站登录信息保存都和cookie相关，只是说看你登录信息如何保存了，自己想一套token验证机制用cookie实现还是比较安全的，遇到cookie劫持另说。 没有绝对安全的系统。
|
 |
28
iyaozhen 2015-08-07 15:40:41 +08:00
首先 session 没有比 cookie 安全。
下面都是一般的情况，安全要一步步来嘛： 现在基本都是 ajax 做基本的前后端分离，用 session 的话和以前没什么区别（所有的接口验证 session）。session_id 通过 cookie 传递（httponly），你网页上的恶意脚本无法获取到 session_id，但抓包的话还是可以看见 session_id，这是时候 https 就登场了，在证书安全的情况下别人是无法获取你的 cookie 的（至于能获取到什么这个不清楚，求大神赐教）。 楼主你是要在 cookie 里面存什么登录信息呀？一般的做法是存一个加密后的 “token”，这个 token 是有时效性的，可以在服务端反解出用户id/用户名。其实和 session 机制类似，这样做的好处就是统一认证接口，各个端、各个产品线、各个开发语言都可以用。当然还是不能防止别人复制你的 token 干坏事，请搜索关键词：CSRF 攻击。 cookie、session 的问题至少还可以说 10 年，并不是一句“cookie 保存在客户端，session 保存在服务端”能解释清楚的。 |
 |
29
allce231 2015-08-07 15:57:00 +08:00
登录注册都交给后台 cookie也是后台设置 httponly 退出登录都是交给后台清cookie
|
 |
30
hupeng 2015-08-07 16:15:54 +08:00
@jiaozi 有个问题，你的session怎么和用户对应起来，不还是客户端的cookie中的某个值来找到对应的session？
|
 |
31
outfocontrol 2015-08-07 17:01:04 +08:00
看有些回复似乎对 cookie 和 session 概念不是很清楚，我的理解是 session 和 cookie 根本是两个不同层次的概念，可很多文章非要把这两放在一起对比来说混淆读者。
cookie 是与 http 协议和浏览器实现标准相关的一部分，cookie 和 http 头部的其它http头字段差不多，而 session 是服务器维持用户状态的一种机制，它对于 http 协议和浏览器来说是透明的，它们并不知道 session 的存在。 由于http是无状态的，必须采取一种机制来追踪用户状态，session 的概念是这个，session 可以用不同的方式来实现，对 web 来说绝大部分情况都是用 cookie 来实现的，也有一些小众做法是在 url 上加 session id，或者在页面里加上个隐藏表单，session 实现的本质都是一样的，请求必须带上一个标识用户的信息，只不过在大部分情况下，这个信息都放在 cookie 中。 |
 |
32
zonghua 2015-08-07 19:23:56 +08:00 via iPhone
一般情况下都是session要依靠cookie保持的，比如jsessionid的那个cookie，马德好多教材都不说明这个
|
 |
33
janxin 2015-08-07 20:30:25 +08:00
可以看一下JSON Web Token这个解决方案
|
|
34
Sight4 2015-08-07 21:05:15 +08:00 via Android
@Amit 能使用你的浏览器已经属于社会工程的安全入侵问题，也不是服务端的设计能控制得来；无论session还是cookie还是token，在实际生产中都会控制超时，https只是提升安全系数，不是杜绝安全隐患。安全不是一方做得万无一失就高枕无忧，就好像，银行安全系数再高，被别人偷看了密码还是能把钱取出来是一个道理
|
|
35
OpooPages 2015-08-07 22:00:27 +08:00
|
 |
36
mornlight 2015-08-08 02:03:19 +08:00
你要这么想，淘宝、FaceBook、Google也还是用 Cookie 来保存用户状态...
|
Select Language