播放有关Cookie和会话的框架安全性问题 [英] Play framework security issue regarding cookies and sessions

查看:99
本文介绍了播放有关Cookie和会话的框架安全性问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于我的应用程序,我正在实现与zentask中所示相同的安全性.

For my app I'm implementing the same security as shown in the zentask.

public class Secured extends Authenticator {

@Override
public String getUsername(Context ctx) {
    return ctx.session().get("email");

}

@Override
public Result onUnauthorized(Context ctx) {
    ctx.flash().put("error", "please login to proceed");
    return redirect(routes.Application.index());
}

}

用户通过身份验证后即为用户session().put("email", email);

When a user is authenticated isuser session().put("email", email);

我有两个问题.第一:当用户不使用注销退出应用程序时,如何使会话无效?第二个更严重的问题是,我使用firefox插件cookies manager+检查了cookie,然后可以复制cookie,然后将其粘贴,因此无需先登录就可以访问方法,基本上可以窃取会话

I have two problems. First: how you invalidate a session when user leaves the app without using the logout? Second more serious one is that I examined the cookie using firefox plugin cookies manager+ and I can copy a cookie and later paste it thus I can access methods without having to first login, basically I can steal sessions

推荐答案

Play Framework使用无状态会话.服务器端没有存储状态,而是所有状态都存储在会话cookie中.为了验证会话,Play使用密钥对会话签名,并在带有会话cookie的请求到达时验证签名.例如,如果用户要篡改会话数据,例如,如果他们将会话中的电子邮件地址更改为其他人的电子邮件地址,则签名将不匹配,因此Play会拒绝会话cookie.

Play Framework uses stateless sessions. There is no state stored on the server side, rather, all the state is stored in the session cookie. To validate a session, Play signs the sessions using a secret key, and validates the signature when a request with a session cookie arrives. If a user was to tamper with the session data, for example, if they changed the email address in the session to someone else's email address, then the signature would not match, and so Play would reject the session cookie.

是的,您可以复制cookie并在以后使用.但是您不能更改Cookie.这意味着您可以窃取"的唯一cookie是您自己的,但从自己身上窃取并不是真正的窃取.因此,不能,除非利用其他漏洞(例如XSS),否则您不能窃取会话,但是会话令牌也容易受到此攻击.

Yes, you can copy the cookie and use it later. But you can't change the cookie. This means the only cookie that you can "steal" is your own, but stealing from yourself is not really stealing. So no, you can't steal sessions, except through exploiting other vulnerabilities such as XSS, but session tokens are vulnerable to this too.

默认情况下,将Play配置为创建会话" Cookie,即,当您关闭浏览器时过期的Cookie.因此,如果用户退出浏览器,浏览器将删除所有会话cookie,并且该用户将不再登录.会话令牌也是如此.

By default, Play is configured to create "session" cookies, ie, cookies that expire when you close the browser. So if a user quits out of their browser, the browser will delete all the session cookies, and the user will not be logged in anymore. This is the same for session tokens.

有一个需要注意的注意事项,即会话令牌在服务器上也会过期,因为服务器保持状态.没有状态的已签名会话(例如Play中使用的会话)则不会.但是,您可以自己实现过期机制,方法是在创建会话时将时间戳记存储在会话中,并确认该时间戳记不早于getUsername()方法中配置的过期期限.由于时间戳存储在已签名的会话中,因此在不更改签名的情况下不能篡改时间戳,因此这种简单的机制非常安全.一种更高级的解决方案可能是实施一个过滤器,该过滤器会在每次请求进入时更新该时间戳记,以使到期时间可以基于上次访问的时间,而不是基于用户登录时的时间.

There is one consideration to be aware of, and that is that session tokens also expire on the server because the server holds state. Stateless signed sessions, such as those used in Play, don't. However, you can implement an expiration mechanism yourself, by storing a timestamp inside the session when it is created, and verifying that that timestamp is no older than a configured expiration period in the getUsername() method. Since the timestamp is stored in the session, which is signed, the timestamp can't be tampered with without changing the signature, so this simple mechanism is quite safe. A more advanced solution might be to implement a filter that updated that timestamp each time a request came in, so that expiration could be based on last accessed, rather than when the user logged in.

这篇关于播放有关Cookie和会话的框架安全性问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆