Hot answers tagged cookies
19
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 ...
17
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
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 ...
15
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.
14
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
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 ...
12
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 ...
11
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
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 ...
10
The basics
First, I assume you get 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 has is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.
...
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 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.
...
9
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 ...
9
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.
...
9
A lot of websites will store the login state into the session, and if an attacker has the session id, he has got the priviledges of the logged in user as well. I 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 send ...
8
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 ...
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 ...
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
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 ...
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
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 ...
8
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 ...
7
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 ...
7
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 ...
7
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 ...
7
Here are some papers that I enjoyed and think are worth reading:
Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning, by Mika Ayenson, Dietrich James Wambach, Ashkan Soltani, Nathan Good, and Chris Jay Hoofnagle. 2011.
Flash Cookies and Privacy, by Ashkan Soltani, Shannon Canty, Quentin Mayo, Lauren Thomas, and Chris Jay Hoofnagle. August ...
7
I would say yes and no at the same time.
Advertising company are using some clever techniques (including cookies) to identify your browser :
Your classic cookies (which are now gone).
Flash cookies : you can store content in flash which can be using for cookies (very common now).
Your browser fingerprint (HTTP Header fingerprint, fonts installed, OS, ...
7
No, this is not true, refer to this excellent answer for more details.
Can't comment on this as I have never used the framework before. Are you sure there isn't a way to set the expiry timing of the session cookie using the framework itself?
The config file should be stored outside the web root. See my answer here. The directory where it is stored should be ...
7
The server can ask the browser to set cookies with the secure flag on over HTTP, but the browser should only include them in responses via HTTPS.
But you should never present a request for authentication over HTTP direct responses to authentication requests over HTTP. The former may be tampered with to copy the credentials elsewhere, while the latter can be ...
6
The trick is too make the "eventually" go beyond the predicted lifetime of the Universe. That's pretty easy because of exponentials: just use a long-enough cookie. Each added bit doubles the number of possible cookie values.
For instance, assume that you get 16 billions of users (i.e. each human being, including babies, creates two or three accounts). ...
Only top voted, non community-wiki answers of a minimum length are eligible
