Tag Info

Hot answers tagged

33

The author of that JS library seems to have made a common, yet mistaken, assumption, though based on just enough knowledge to get things wrong. You can't just sprinkle magik crypto faerie dust and expect to get more security, like chocolate chips. What the author is missing is that once you sign the session id, and put that in the cookie - the signed ...


29

After a bit of searching, it seems some banks are giving this advice following an attack on a bank that allowed users or malicious websites to reuse persistent cookies after a user had logged out, allegedly because other browser tabs were left open on the site in question and so the browser had not cleared the cookies yet. The reason such a vulnerability ...


27

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


24

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


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


18

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


17

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


17

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


16

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


14

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


14

The connection between the client and the server does not use public key encryption (that is only used for the initial key exchange). A different algorithm is used for encryption (usually a symmetric encryption), such as AES-256-CBC on a TLS 1.2 connection. So unless you intercepted it, no one but the intended browser and the original server can decrypt the ...


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


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

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


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

They are meant to clear a part of your browser history that is in this so called "private" session and to separate that session from previously existing sessions as well. Things in this session won't be stored after you leave the session. This is not a 100% foolproof method however: They will still be able to track you based on your IP-addresss and your ...


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

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


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

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


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


9

You should close your web browser (to avoid private information disclosure) if... Someone might access the computer after you do The HTTP response (of the sensitive info) does not set the Cache-Control header properly For example, go to yourbank.com, and look at your account. Click logout. Click the back button. Do you see your account info? On some ...


9

Eran Hammer, one of the maintainers of the yar session management module for NodeJS, had this to say on the matter: Disclaimer: like any security advice from someone who doesn't know the specifics of your own system, this is for educational purposes only. Security is a complex and very specific area and if you are concerned about the security of ...


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



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