Hot answers tagged session-management
17
Cookies have, historically, been a source of numerous security and privacy concerns.
For example, tracker cookies can be used to identify which websites you've visited and what activities you've done on them:
Site A includes hidden iframe that points at a tracker service.
Tracker service issues a cookie that identifies you, and logs your visit.
Site B ...
16
The key factors I always look for in a Project Definition spec are missing here:
What are you protecting? Who are you protecting it from? What is the impact if it is compromised?
If you are protecting your list of friends birthdays it is almost certainly overkill.
If you are protecting Top Secret material from International or Corporate espionage then it ...
16
Summary. Yes, this is possible. It's not a browser bug. It is part of the as-designed functionality of cookies. There is no browser that is safe from this. Cookies are ancient technology and their security model is only loosely-integrated with the rest of the web. The details are messy and ugly.
The gory details
The site blog.example.com can set ...
15
Use a database for sessions.
Regenerate the session on when the
permissions change (e.g., when a user
logs in).
Regenerate the session on every page
load (optional).
Don't expose the session ID in the
URL.
Don't expose any sensitive data to the session.
11
With tracking cookies, advertisers can track users across different websites and even across IP addresses (e.g. for laptop users). This has been going on since forever (literally since the beginning of advertising networks, like Google Adwords), but recently the media has been inciting the public against those cookies, blaming them as the root cause for ...
10
TL;DR: FaceNiff probably exploits WPA's "Hole 192" and uses ARP poisoning to set up a Man-in-the-Middle attack. The steps, in short, are:
Eve uses the Group Temporal Key (GTK) to inject ARP packets into the network, with the network's gateway IP paired to her MAC address.
Clients register Eve's MAC address as their new gateway.
Clients send packets ...
10
Beware of overkill, it is counterproductive. If your login system is too inconvenient or annoying, users will actively try to work around it. "Users", here, includes application developers and server administrators.
login form is SSL secured
This one is the most important, but not "alone". Theoretically, the whole site should be secured with SSL, not ...
10
The basics
First, I assume you get the most basic session ID security right:
you are using an ID with sufficient entropy, and
you use transport level security (HTTPS).
Any approach to session ID (URL, cookies, whatever) that does not get those right has is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.
...
9
One problem you could have with this kind of setup is, from what you've said, it looks like the session token would be static (ie for a given user, it never changes, until they change their password). As such if an attacker manages to get access to a token for a given user (trojan, keylogger, packet sniffing (if SSL isn't used) etc), they will have ...
9
To be protected against CSRF while also hardening against XSS, store your session IDs in cookies (with httpOnly flag) and use separate session-bound form tokens that you validate upon POST. By combining these methods, you prevent an attacker that has found XSS from stealing session IDs, while you still protect against CSRF in a meaningful way. Using the ...
9
Don't implement your own session handler. Use $_SESSION, it was written and audited by people who very good understanding security. I don't even know the intricacies of how your session handler works, but based on the little information you have given us its insecure.
SQL Injection is useful to obtain data from the database. We HASH passwords because ...
8
I don't think you gain a lot since they'd still be associated with the site, or some sub-domain of it.
As for the downsides, you'd have to have some lookup to figure out what the name for a particular cookie is so you can know where the data you stored previously can be found.
I think you're better off not worrying about it, and instead make sure you only ...
8
Cookies only; of course, there's nothing preventing you from this:
if (empty($_SESSION['ip']) {
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} else {
if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
// IP changed
}
}
Note that identifying a user by IP address is only a stopgap measure, and I wouldn't consider it relevant to security - e.g. large ...
8
The first step in securing any web application is using SSL. That keeps your cookie confidential, prevents replay attacks, ensures the user is talking to the right server, prevents MitM, prevents attackers from changing the data on the network...
Then set the secure flag on the cookie, so it's only sent over SSL. Setting the http-only flag, to prevent ...
7
Without a shadow of a doubt the answer is NO. You must have a completely secure transport layer in which to convey your session id. At no point can this session id be transmuted over an insecure connection, this would be a violation of OWASP A9 - Insufficient Transport Layer Protection
7
In principle you may be able to defend against passive attacks. But in practice it's non-trivial and not a great solution.
In principle, you can write your own encryption code in Javascript to encrypt everything on the client-side (in Javascript). The very first thing you run into is that this has poor performance, because crypto in Javascript is ...
7
I've seen implementations that tried this approach and ended up pulling it because yes it can cause resource issues and race conditions across Web farms. It sounds like a good idea at first, but can also make your application more prone to denial of service attacks if the regeneration process is too cryptographically intensive. Answer there is to ...
7
In addition to VirtuosiMedia's list:
Use TLS (SSL) across the entire site. Use the HSTS header.
Use a session cookie, rather than adding a session token to every link-href and form-action.
Use the secure and httpOnly flags on the cookie.
Use the X-Frame-Options header.
Keep the content of the session minimal. E.g., store only the user-id. If caching is ...
7
Most security researchers consider "hole 196" to be more of a technical break than something that is very useful to the attacker. I think that the WPA-PSK handshake, and the lack of encryption for for management frames are far more serious threats.
Although hole 196 can be used in conjunction with these attacks. 1) de-auth a client, 2) capture the ...
6
I don't know what libraries you are using for writing your application, but most provide some sort of session management.
The implication of using a password hash a session token, you will not be able to tell one session from another. And what if two users have the same password? Will you be able to tell the difference?
Further, you will make yourself ...
6
The answer to this depends on whether or not your application uses GET or POST data to populate SESSION data.
Say for example that the $_SESSION['username'] is populated when the user logins like this:
$_SESSION['username'] = $_GET['login-username']
As the XSS owns your client he can also modify the content of login-username variable, and thus control ...
6
IMHO, by far the biggest disadvantage is that you need to explicitly add code to repopulate the session identifier into each and every page, potentially in multiple places. Using a form field is only going to work where you've got a form and that's the only way to navigate off the page.
So you also need to add code to parse every href on the page and add ...
6
Parties can never fully agree in a situation where a message may or may not be received by either party because there will always be a difference in state between the two parties.
This is also the "girlfriend's cellphone stopped working" conundrum. The best solution is to have an agreed-upon protocol that is followed so that you know the other party is ...
6
The feature is really useful from a security perspective as it allows users to easily notice if someone else is accessing the account. This is a really useful feature in the sort of attacks where the attacker would want to silently observe the account to obtain information without actually doing anything active which would draw attention to himself.
The ...
5
It's difficult to give you a detailed answer as a lot will depend on the actual code you use to implement this process. The first and arguably most important thing to consider is input AND output validation on the data supplied by the user. There are plenty of good resources out there about that, http://www.owasp.org/ springs immediately to mind as the "go ...
5
Implement DNSSec to protect your HTTPS session from attacks over Wifi, or public networks including hardwired/switched.
Use HTTPS only for cookies that don't need Javascript access
Use the Secure attribute for all others cookies
Don't allow 3rd party javascript on your site
Similar to the above, don't serve advertisements on your site
5
A PHP 'SESSION' cookie does not incorporate IP address information out of the box. It is possible to associate it with that information, as Piskvor showed, but doing so may break the application for some users. See OWASP's discussion of the possible problems that IP address binding can cause.
5
Whenever you are requesting a page with HTTP, everything is sent plaintext, that means the session cookie containing the id is sent plaintext as well (even for image requests). That makes it an easy target for MITM attacks. You can configure the cookie to be sent to HTTPS pages only, but of course you will loose the session then on HTTP pages.
The best way ...
5
You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my users' subdomains?
Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks. It depends upon what kind of content you allow on the subdomains (e.g., elmer.acme.com). There are two cases:
If you allow Elmer to put ...
5
Don't store the password in the session variables. Instead, use a surrogate key.
For example:
Generate a random key. This is your surrogate key.
Use that key to encrypt whatever data you need.
Generate a storage key from your password, using an appropriate key-derivation function (e.g. PBKDF2 or bcrypt).
Encrypt the surrogate key with the storage key. If ...
Only top voted, non community-wiki answers of a minimum length are eligible
