Tag Info

Hot answers tagged

34

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


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

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


22

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.


18

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


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

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


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


16

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


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

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


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


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


13

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


13

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


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


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


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


12

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of ...


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

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


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

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


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

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

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



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