Do you consider session replication as a security risk? I mean if an attacker manages to hijack the session, he would still be able to use the same valid session, especially in scenarios where the session do not expire until one manually logs out. What recommendations would you give to prevent session replication?
相关问题
- “Zero out” sensitive String data in Swift
- High cost encryption but less cost decryption
- Data loss during sending via $_SESSION from one sc
- Chrome not keeping my _SESSION vars when coming fr
- Using a session with php and Java
相关文章
- Page指令 的EnableSessionState="ReadOnly",怎么在web.confi
- Warning : HTML 1300 Navigation occured?
- How exactly do Firebase Analytics handle session d
- Security concerns about CORS
- Symfony2: check whether session exists or not
- How do I prevent SQL injection with ColdFusion
- When is destructor called in a WCF service
- LINQ to Entities and SQL Injection
You could have a rolling Session ID - every so often (e.g. after a certain number of requests or a certain short time period), the system generates a new Session ID.
To prevent errors with race conditions due to one resource request causing a new Session ID to be generated, both the current and the previous Session IDs should be accepted during the rollover interval.
In essence, this will cause one of the valid sessions (either the attacker's or the victim's) to expire within their browser as they are using the old Session ID and have not received the cookie containing a new ID.
You should display a message saying something along the lines of You have been logged out as your account is used elsewhere. If this happens to be the attacker's machine, then great - you have prevented an attack. If this happens to be the victim's machine at the very least they are aware that their session has been compromised and can take steps to inform the site owners.
If you also combine this with invalidating all existing session for the account upon user login, the victim user logging in again will kick the attacker out and the attacker will need to reacquire a valid Session ID. This should reduce the attack window significantly allowing the system to remain secure while the Session ID leak is investigated and fixed.
Sessions are a better idea when you don't want the client to have the ability to mess with the data.
For example using a session variable to store the User ID of the current user is alright.
So, Session is always a good idea to use it. But it depends how you manage it. (unsetting once used it)
But if you use Cookies it is not recommended as it is stored in the user's computer, it can be modified, viewed by the user itself.