Tag Info

Hot answers tagged

32

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


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


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


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.


20

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


17

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


16

There is indeed an EU legislation : European Union Directive 2009/136/EC says that websites must get consent from their visitors about information they intend to keep/store/retrieve on their computer/device. There is even a fine, up to £500,000 for those who don't comply. Source : ICO (Information Commissione's Office) Blog European Comission ...


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


15

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


15

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


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

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


13

Usually, the password isn't stored in the cookie. You login to example.com with your username and password, these are verified to belong to you (typically by hashing your password and checking the hash of your password matches with the hash for a user with that username), and the server issues you a long random number token as a secret identifier for you. ...


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

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


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

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


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


10

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


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.


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


10

The easiest way to avoid interception/modification of your web traffic is one that you mention in the question which is to use a VPN. This will encrypt traffic between your device and the VPN endpoint and should prevent your ISP from being able to modify web headers or other aspects of your use. There are VPN clients for most modern mobile operating ...


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

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

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



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