Tag Info

Hot answers tagged

29

Is passing the session id as url parameter really insecure? While it's not inherently insecure, it can be a problem unless the code is very well-designed. Let's say I visit my favorite forum. It logs me in and appends my session ID to the URL in every request. I find a particularly interesting topic, and copy & paste the URL into an instant ...


25

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


21

The cookies secure flag looks like this: secure; That's it. This should appear at the end of the Http header: Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly; Of course, to check it, simply plug in any proxy or sniffer (I use the excellent Fiddler) and watch... *Bonus: I also threw in there the httpOnly ...


19

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

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

No, this is not safe You should generate a long random number and store it in a cookie. This random number is essentially just another password for this user. So, on the serverside, you only store a properly salted hash of this random number. You should only give out each number once and it should only be valid for 1 login. So allow for more than one of ...


14

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

Quoted from OWASP's CSRF Prevention page: Double Submit Cookies Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value ...


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

You can check using a tool like Firebug (an extension for Firefox: http://getfirebug.com/). The cookie will display as 'secure'. Also if you're in Firefox you can look in the 'Remove Individual Cookies' window to be certain. From a development point of view, a 'secure' cookie is the same as a regular one, but has an extra parameter in it. e.g. ...


12

Yes, this does look like a pretty good scheme for protecting cookies. Another more recent scheme in this area is SCS: Secure Cookie Sessions for HTTP, which is a solid scheme, very well thought-out. I recommend reading the security discussion of that document to get a good sense of what the security threats may be. To help understand the purpose and role ...


12

If I'm using websites that do not use HTTPS, but I'm on a WEP-protected Wi-Fi network, are my cookies safe from being sniffed by third-parties? No. Outsiders can crack WEP networks almost as if they weren't encrypted at all, these days. Insiders have even more ease of access. Even on WPA/WPA2 networks, there are still exploits that enable insiders to ...


11

The answer here depends on how the website handles cookie management. If they're doing things correctly, following the signout link should invalidate the cookie on the server-side and also remove it from the client. As such if an attacker got access to your PC after that they shouldn't be able to mis-use the cookie, even if they could get access to it. ...


11

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


10

You can use app.config to force it; the format is (in the <system.web> section) <httpCookies domain="String" httpOnlyCookies="true|false" requireSSL="true|false" /> so you really want, at a minimum <httpCookies requireSSL='true'/> But preferably you'll also turn httpOnlyCookies on, unless you're doing some ...


10

Most of the websites store their user's login state into the session, and if an attacker has the session id, he has got the privileges of the logged in user as well. In other words,the two concerns of maintaining the session and authentication are often coupled. One problem is that, it is easy to make session fixation attacks. In this case an attacker would ...


10

The safest way to protect your site against Firesheep (and related attacks): Move to site-wide SSL protection: Move your entire site to HTTPS, and disable all HTTP access. In other words, protect your entire site with SSL. Here are some more resources on doing that: how to protect against Firesheep, pros and cons of site wide SSL, why SSL protects ...


10

I agree with most of the previous responses, but note that the FB and Google compact policies might be considered fraudulent due to the fact that they omit P3P elements and the way the P3P syntax is defined, omitting an element is an affirmative statement that you do not do the practice represented by that element. (See for example section 3.3.4 of the P3P ...


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

No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website. To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.


9

Generally speaking, this really depends on how the server implements the cookie-based authentication. If the server uses the cookie as an indexing key into the server database, which the server uses to recover all the session information, then "signing out" means having the server forget all about the session -- at which point the cookie becomes worthless ...


9

Your basic concept is not new: you want to have some state associated with the user, but you do not want to store that state yourself. Instead, you store it on the client (in a cookie). Since you want to protect against alterations of such a state (e.g. a client building a cookie from scratch), you need an integrity check, such as a Message Authentication ...


9

I'm willing to bet that they don't actually identify the computer, they just send you a persistent cookie once you've successfully logged in, and as long as your browser returns that cookie, they know it's a previously used machine. You should be able to test this quite easily using something like Firefox's Web Developer toolbar which will let you both ...


9

Of course it is possible... Think about it this way: The secure flag ensures that the cookie is locked to HTTPS. HTTPS ensures that the connection with the server (requests + responses) is tied to the server's certificate. The server's certificate ensures the actual identity of the web server. Now, if you remove that first step, the ...


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

A cookie has the "secure" flag if it says so. Theoretically, nothing prevents a "secure" cookie from being served by a HTTP (non-HTTPS) server; but your server software may take issue, since, from its point of view, the protocol is HTTP and a secure cookie makes little sense if it transits over HTTP. Your server does not know that it is behind a ...


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

No. To verify this, you would have to store the hashed value on your server to compare against, otherwise you wouldn't be able to invalidate login sessions; or even worse you would need to store the plaintext password and timestamp used in order to regenerate the value. If you're going to be storing a value between two machines to compare, that value should ...


8

The cookie path doesn't provide any security (in most real-world situations). It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn't evolved correspondingly. ...


8

In addition to what Charles and Martin have said, putting anything in the URL makes it more likely that it will leak. This can be through a Referer header in a linked resource, from access to the endpoint with browser history records, from brute force history sniffing, inappropriately protected web logs, and so on. So it's generally inadvisable to put ...



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