Tag Info

Hot answers tagged

26

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 ...


20

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.


19

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 ...


19

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 ...


15

The basics First, I assume you understand 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 is vulnerable, your question is specifically about ID in URL, so I will not discuss that further. ...


13

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 ...


12

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 ...


12

The basic concept of a session identifier is that it is a short-lived secret name for the session, a dynamic relationship which is under the control of the server (i.e. under the control of your code). It is up to you to decide when sessions starts and stop. The two security characteristics of a successful session identifier generation algorithm are: No ...


12

"Replay attacks" don't really apply to cookies, because a cookie is by definition something which is meant to be replayed: the user's browser sends back the same cookie value, and that is how your server knows that it is the same user. What you want to avoid is someone spying on the line, observing the cookie value, and then sending the same cookie on his ...


11

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 ...


11

You know what you shouldn't do? Reinvent the wheel. There are many authentication libraries out there, especially for PHP. Almost every single framework includes one. Use it. If you aren't using a framework, stop what you are doing and use one! And yes, you must use TLS for your site.


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

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 ...


10

You could avoid the current Firesheep via some "security thru obscurity" scheme involving authentication via dynamic session management as discussed here. You can use "Digest Authentication" (RFC 2617), but that is still vulnerable to a MITM attack, degrades the user experience and requires the server to store your password (or a password equivalent) in the ...


10

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 ...


10

Yes it is possible, and this technique is widely used. It does have some minor drawbacks compared to stateful sessions: It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires. The use of a server-side secret ...


9

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 ...


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 ...


9

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 ...


9

Yes, what you're saying makes sense. By setting your cookie as an HttpOnly cookie, you're mitigating the risk of your partner's JavaScript having access to the user's session ID. Since your partner insists on getting a unique identifier for your customers, I see nothing wrong with sending them a securely hashed version of the session ID. The key point here ...


8

Expire your session after a reasonable amount of time... Delete the session out of whatever your using as a repository so it can't be re-used...


8

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 ...


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

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


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 ...


7

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 ...


7

From the perspective of the site developer, you should use the following: Adopt SSL: use SSL sitewide. Set the secure flag on all cookies. This will ensure that they are only sent over a SSL connection. Turn on HSTS. This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks. ...


7

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 ...


7

First, please read upon session fixation attacks and make sure you understand how they work. You didn't give us the information that is needed to determine whether standard session fixation attacks will work; all of that information is relevant to other attacks, but not to session fixation. The fundamental characteristic of a session fixation attack 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 ...



Only top voted, non community-wiki answers of a minimum length are eligible