Simon Willison's Weblog: cookies

Quoting Frederik Braun

2024-08-26T20:26:31+00:00

In 2021 we [the Mozilla engineering team] found “samesite=lax by default” isn’t shippable without what you call the “two minute twist” - you risk breaking a lot of websites. If you have that kind of two-minute exception, a lot of exploits that were supposed to be prevented remain possible.

When we tried rolling it out, we had to deal with a lot of broken websites: Debugging cookie behavior in website backends is nontrivial from a browser.

Firefox also had a prototype of what I believe is a better protection (including additional privacy benefits) already underway (called total cookie protection).

Given all of this, we paused samesite lax by default development in favor of this.

— Frederik Braun

Tags: browsers, cookies, firefox, mozilla, privacy, security, cors, samesite

Exploring the SameSite cookie attribute for preventing CSRF

2021-08-03T21:09:02+00:00

In reading Yan Zhu's excellent write-up of the JSON CSRF vulnerability she found in OkCupid one thing puzzled me: I was under the impression that browsers these days default to treating cookies as SameSite=Lax, so I would expect attacks like the one Yan described not to work in modern browsers.

This lead me down a rabbit hole of exploring how SameSite actually works, including building an interactive SameSite cookie exploration tool along the way. Here's what I learned.

Background: Cross-Site Request Forgery

I've been tracking CSRF (Cross-Site Request Forgery) on this blog since 2005(!)

A quick review: let's say you have a page in your application that allows a user to delete their account, at https://www.example.com/delete-my-account. The user has to be signed in with a cookie in order to activate that feature.

If you created that page to respond to GET requests, I as an evil person could create a page at https://www.evil.com/force-you-to-delete-your-account that does this:

<img src="https://www.example.com/delete-my-account">

If I can get you to visit my page, I can force you to delete your account!

But you're smarter than that, and you know that GET requests should be idempotent. You implement your endpoint to require a POST request instead.

Turns out I can still force-delete accounts, if I can trick a user into visiting a page with the following evil HTML on it:

<form action="https://www.example.com/delete-my-account" method="POST">
<input type="submit" value="Delete my account">
</form>
<script>document.forms[0].submit()</script>

The form submits with JavaScript the instant they load the page!

CSRF is an extremely common and nasty vulnerability - especially since it's a hole by default: if you don't know what CSRF is, you likely have it in your application.

Traditionally the solution has been to use CSRF tokens - hidden form fields which "prove" that the user came from a form on your own site, and not a form hosted somewhere else. OWASP call this the Double Submit Cookie pattern.

Web frameworks like Django implement CSRF protection for you. I built asgi-csrf to help add CSRF token protection to ASGI applications.

Clearly it would be better if we didn't have to worry about CSRF at all.

As far as I can tell, work on specifying the SameSite cookie attribute started in June 2016. The idea was to add an additional attribute to cookies that specifies the policy for if they should be included in requests made to a domain from pages hosted on another domain.

Today, all modern browsers support SameSite. MDN has SameSite documentation, but a summary is:

SameSite=None - the cookie is sent in "all contexts" - more-or-less how things used to work before SameSite was invented. Update: One major edge-case here is that Safari apparently ignores None if the "Prevent cross-site tracking" privacy preference is turned on - and since that is on by default, this means that SameSite=None is effectively useless if you care about Safari or Mobile Safari users.
SameSite=Strict - the cookie is only sent for requests that originate on the same domain. Even arriving on the site from an off-site link will not see the cookie, unless you subsequently refresh the page or navigate within the site.
SameSite=Lax - cookie is sent if you navigate to the site through following a link from another domain but not if you submit a form. This is generally what you want to protect against CSRF attacks!

The attribute is specified by the server in a set-cookie header that looks like this:

set-cookie: lax-demo=3473; Path=/; SameSite=lax

Why not habitually use SameSite=Strict? Because then if someone follows a link to your site their first request will be treated as if they are not signed in at all. That's bad!

So explicitly setting a cookie with SameSite=Lax should be enough to protect your application from CSRF vulnerabilities... provided your users have a browser that supports it.

(Can I Use reports 93.95% global support for the attribute - not quite high enough for me to stop habitually using CSRF tokens, but we're getting there.)

What if the SameSite attribute is missing?

Here's where things get interesting. If a cookie is set without a SameSite attribute at all, how should the browser treat it?

Over the past year, all of the major browsers have been changing their default behaviour. The goal is for a missing SameSite attribute to be treated as if it was SameSite=Lax - providing CSRF protection by default.

I have found it infuriatingly difficult to track down if and when this change has been made:

Chrome/Chromium offer the best documentation - they claim to have ramped up the new default to 100% of users in August 2020. WebViews in Android still have the old default behaviour, which is scheduled to be fixed in Android 12 (not yet released).
Firefox have a blog entry from August 2020 which says "Starting with Firefox 79 (June 2020), we rolled it out to 50% of the Firefox Beta user base" - but I've not been able to find any subsequent updates. Update 26th August 2024: It turns out Firefox didn't ship this after all, going with their own Total Cookie Protection solution instead, which rolled out in April 2023.
I have no idea at all what's going on with Safari!

I started a Twitter thread to try and collect more information, so please reply there if you know what's going on in more detail.

The Chrome 2-minute twist

Assuming all of the above, the mystery remained: how did Yan's exploit fail to be prevented by browsers?

After some back-and-forth about this on Twitter Yan proposed that the answer may be this detail, tucked away on the Chrome Platform Status page for Feature: Cookies default to SameSite=Lax.

Note: Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention ("Lax + POST") will be removed in the future.

It looks like OkCupid were setting their authentication cookie without a SameSite attribute... which opened them up to a form-based CSRF attack but only for the 120 seconds following the cookie being set!

Building a tool to explore SameSite browser behaviour

I was finding this all very confusing, so I built a tool.

The code lives in simonw/samesite-lax-demo on GitHub, but the tool itself has two sides:

A server-side Python (Starlette) web application for setting cookies with different SameSite attributes. This is hosted on Vercel at https://samesite-lax-demo.vercel.app/
An HTML page on a different domain that links to that cookied site, provides a POST form targetting it, embeds an image from it and executes some fetch() requests against it. This is at https://simonw.github.io/samesite-lax-demo/

Hosting on two separate domains is critical for the tool to show what is going on. I chose Vercel and GitHub Pages because they are both trivial to set up to continuously deploy changes from a GitHub repository.

Using the tool in different browsers helps show exactly what is going on with regards to cross-domain cookies.

A few of the things I observed using the tool:

SameSite=Strict works as you would expect. It's particularly interesting to follow the regular <a href=...> link from the static site to the application and see how the strict cookie is NOT visible upon arrival - but becomes visible when you refresh that page.
I included a dynamically generated SVG in a <img src="/cookies.svg"> image tag, which shows the cookies (using SVG <text>) that are visible to the request. That image shows all four types of cookie when embedded on the Vercel domain, but when embedded on the GitHub pages domain it differs wildly:
- Firefox 89 shows both the SameSite=None and the missing SameSite cookies
- Chrome 92 shows just the SameSite=None cookie
- Safari 14.0 shows no cookies at all!
Chrome won't let you set a SameSite=None cookie without including the Secure attribute.
I also added some JavaScript that makes a cross-domain fetch(..., {credentials: "include"}) call against a /cookies.json endpoint. This didn't send any cookies at all until I added server-side headers access-control-allow-origin: https://simonw.github.io and access-control-allow-credentials: true. Having done that, I got the same results across the three browsers as for the <img test described above.

Safari ignoring SameSite=None looked like it was this bug: Cookies with SameSite=None or SameSite=invalid treated as Strict - it's marked as fixed but it's not clear to me if the fix has been released yet - I still saw that behaviour on my macOS 10.15.6 laptop or my iOS 14.7.1 iPhone.

Update: krinchan on Hacker News has an answer here:

The Safari "bug" is a new setting that's turned on by default: "Prevent cross-site tracking". It treats all cookies as SameSite=Lax, even cookies with SameSite=None.

Full Third-Party Cookie Blocking and More on the WebKit blog has more about this.

Most excitingly, I was able to replicate the Chrome two minute window bug using the tool! Each cookie has its value set to the timestamp when it was created, and I added code to display how many seconds ago the cookie was set. Here's an animation showing how Chrome on a form submission navigation can see the cookie that was set with SameSite missing at 114 seconds old, but that cookie is no longer visible once it passes 120 seconds.

Consider your subdomains

One last note about CSRF that you should consider: SameSite=Lax still allows form submissions from subdomains of your primary domain to carry their cookies.

This means that if you have a XSS vulnerability on one of your subdomains the security of your primary domain will be compromised.

Since it's common for subdomains to host other applications that may have their own security concerns, ditching CSRF tokens for Lax cookies may not be a wise step!

A Login CSRF attack is when a malicious forces a user to sign into an account controlled by the attacker. Why do this? Because if that user then saves sensitive information the attacker can see it.

Imagine I trick you into signing into an e-commerce account I control and saving your credit card details. I could then later sign in myself and buy things on your card!

Here's how that would work: Say the site's login form makes a POST to https://www.example.com/login with username and password as the form fields. If those credentials match, the site sets an authentication cookie.

I can set up my evil website with the following form:

<form action="https://www.example.com/login">
  <input type="hidden" name="username" value="my-username">
  <input type="hidden" name="password" value="my-password">
</form>
<script>document.forms[0].submit()</script>

I trick you into visiting my evil pge and you're now signed in to that site using an account that I control. I cross my fingers and hope you don't notice the "you are signed in as X" message in the UI.

An interesting thing about Login CSRF is that, since it involves setting a cookie but not sending a cookie, SameSite=Lax would seem to make no difference at all. You need to look to other mechanisms to protect against this attack.

But actually, you can use SameSite=Lax to prevent these. The trick is to only allow logins from users that are carrying at least one cookie which you have set in that way - since you know that those cookies could not have been sent if the user originated in a form on another site.

Another (potentially better) option: check the HTTP Origin header on the oncoming request.

Final recommendations

As an application developer, you should set all cookies with SameSite=Lax unless you have a very good reason not to. Most web frameworks do this by default now - Django shipped support for this in Django 2.1 in August 2018.

Do you still need CSRF tokens as well? I think so: I don't like the idea of users who fire up an older browser (maybe borrowing an obsolete computer) being vulnerable to this attack, and I worry about the subdomain issue described above.

And if you work for a browser vendor, please make it easier to find information on what the default behaviour is and when it was shipped!

Tags: chrome, cookies, csrf, security, samesite, starlette

Quoting Nat Friedman

2020-12-17T19:44:20+00:00

At GitHub, we want to protect developer privacy, and we find cookie banners quite irritating, so we decided to look for a solution. After a brief search, we found one: just don’t use any non-essential cookies. Pretty simple, really. 🤔

So, we have removed all non-essential cookies from GitHub, and visiting our website does not send any information to third-party analytics services.

— Nat Friedman

Tags: cookies, github, privacy

Tip for changing cookie subdomains: change the cookie name too

2020-06-09T18:41:42+00:00

Tip for changing cookie subdomains: change the cookie name too

This is a really useful tip I hadn’t encountered before. If you make a change to the way cookies are configured—changing the cookie domain or path for example—it’s a good idea to change the name of the cookie as well. If you don’t change the cookie name you’ll see weird behaviour for users who have previously had the cookie set using the older configuration. This definitely explains bugs I’ve seen in the past. Filing this tip away for future cookie-related development work.

Tags: cookies

Weeknotes: datasette-auth-existing-cookies and datasette-sentry

2020-01-29T05:58:13+00:00

Work on Datasette Cloud continues - I'm tantalizingly close to having a MVP I can start to invite people to try out.

I'm trying to get as much work as possible done for it using Datasette Plugins. This week I've released two new plugins to assist in the effort.

datasette-auth-existing-cookies

My first attempt at adding authentication to Datasette was datasette-auth-github, which takes advantages of GitHub's best-in-class OAuth flow to implement sign-in with GitHub and builds a relatively powerful permission system on top of GitHub users, organizations and teams.

For Datasette Cloud I need to go a step further: I'm definitely going to have regular username/password accounts, and I'll probably implement sign-in-with-Google as well.

I don't particularly want to implement username/password accounts from scratch. Django (and django-registration) provide robust and very well tested solution for this. How about I use that?

Datasette Cloud teams will each get their own Datasette instance running on a subdomain. If I implement authentication as a Django app running on example.com I can set that as the cookie domain - then Datasette instances running on teamname.example.com will be able to see the resulting authentication cookie.

Given a Django authentication cookie (which may just be a sessionid) how can I tell if it corresponds to a logged in user? That's where my new datasette-auth-existing-cookies plugin comes in.

The plugin lets you configure Datasette to read in a specified list of cookies and then forward them on as part of an API request to an underlying application. That application then returns JSON showing if the user is signed in or not. The plugin then sets a short-lived signed cookie that persists that information.

Here's what the configuration looks like:

{
    "plugins": {
        "datasette-auth-existing-cookies": {
            "api_url": "https://www.example.com/user-from-cookies",
            "auth_redirect_url": "https://www.example.com/login",
            "original_cookies": ["sessionid"]
        }
    }
}

Any hits to teamname.example.com will be checked for a sessionid cookie. That cookie is forwarded on to https://www.example.com/user-from-cookies to see if it's valid.

If the cookie is missing or invalid, the user will be redirected to the following URL:

https://www.example.com/login?next=https://teamname.example.com/

The plugin has a few other options: you can request that the ?next= parameter is itself signed to help protect against unvalidated redirects for example. But it's a pretty simple piece of code that hopefully means I won't have to spend much more time thinking about login and registration.

httpx for testing ASGI apps

All of my Datasette plugins ship with unit tests - mainly so that I can implement continuous deployment from them, where new tagged releases are automatically shipped to PyPI provided the tests pass.

For ASGI plugins, this means writing unit tests against the ASGI spec. I've mainly been doing this using the ApplicationCommunicator class from asgiref, which provides powerful low-level hooks for interacting with an ASGI application. The tests end up being pretty verbose though!

Here's the ApplicationCommunicator test I first wrote for datasette-auth-existing-cookies.

I've been exploring Tom Christie's httpx library for asynchronous HTTP calls in Python recently, and I spotted an interesting capability buried deep in the documentation: you can pass it an ASGI app and make requests directly against the app, without round-tripping through HTTP!

This looked ideal for unit testing, so I had a go at rewriting my tests using it. The result was delightful:

auth_app = ExistingCookiesAuthTest(
    hello_world_app,
    ...
)
async with httpx.AsyncClient(app=auth_app) as client:
    response = await client.get(
        "https://demo.example.com/", allow_redirects=False
    )
    assert 302 == response.status_code
    location = response.headers["location"]
    assert "https://www.example.com/login" == location

This is a much nicer way of writing tests for ASGI applications and middleware. I'm going to be using this for all of my projects going forward.

datasette-sentry

In starting to deploy Datasette Cloud I quickly ran into the need to start collecting and analyzing errors thrown in production.

I've been enjoing using Sentry for this for several years now, and I was pleased to see that the official Sentry SDK grew support for ASGI last July.

Wrapping it up as a Datasette plugin took less than half an hour: datasette-sentry. It's configured like this:

{
    "plugins": {
        "datasette-sentry": {
            "dsn": {
                "$env": "SENTRY_DSN"
            }
        }
    }
}

The DSN configuring Sentry will then be read from the SENTRY_DSN environment variable.

Tags: cookies, django, projects, sentry, datasette, weeknotes, datasette-cloud, httpx

Quoting Troy Hunt

2020-01-03T16:22:42+00:00

Come version 80, any cookie without a SameSite attribute will be treated as "Lax" by Chrome. This is really important to understand because put simply, it'll very likely break a bunch of stuff. [...] The fix is easy, all it needs is for everyone responsible for maintaining any system that uses cookies that might be passed from an external origin to understand what's going on. Can't be that hard, right? Hello? Oh...

— Troy Hunt

Tags: chrome, cookies, csrf, samesite, troy-hunt

Cookies-over-HTTP Bad

2018-04-07T14:39:06+00:00

Cookies-over-HTTP Bad

Mike West from the Chrome security team proposes a way for browsers to start discouraging the use of tracking cookies sent over HTTP—which represent a significant threat to user privacy from network attackers. It’s a clever piece of thinking: browsers would slowly ramp up the forced expiry deadline for non-HTTPS cookies, further encouraging sites to switch to HTTPS cookies while giving them ample time to adapt.

Via @mikewest

Tags: cookies, https, privacy

Can you mark items on a website as 'unread' without cookies?

2012-10-20T13:44:00+00:00

My answer to Can you mark items on a website as 'unread' without cookies? on Quora

It's not very exciting, but CSS will let you set different styles for visited vs unvisited links and the technique has worked reliably since the mid 1990s.

Tags: cookies, html5, javafx, javascript, web-development, quora, frontend

Firesheep

2010-10-25T09:11:00+00:00

Firesheep

Oh wow. A Firefox extension that makes sniffing for insecured (non-HTTPS) cookie requests on your current WiFi network and logging in as that person a case of clicking a couple of buttons. Always possible of course, but it’s never been made easy before. Private VPNs are about to become a lot more popular.

Via Hacker News

Tags: cookies, security, wifi, recovered, firesheep

Facebook's Instant Personalization: An Analysis of Fundamental Privacy Flaws

2010-10-02T23:53:00+00:00

Facebook's Instant Personalization: An Analysis of Fundamental Privacy Flaws

Oh FFS. “Instant Personalization” means you visit one of Facebook’s “partner websites” and Facebook instantly tells them your full identity and gives them access to full Facebook connect functionality—without you performing any action other than visiting the site. This will not end well.

Via Hacker News

Tags: cookies, facebook, privacy, recovered

Internet Explorer Cookie Internals (FAQ)

2010-02-26T12:25:24+00:00

Internet Explorer Cookie Internals (FAQ)

Grr... IE 6, 7 and 8 don’t support the max-age cookie argument, forcing you to use an explicit expiry date instead. This appears to affect the cache busting cookie pattern, where you set a cookie to expire in 30 seconds for any user who posts content and use the presence of that cookie to skip caches and/or send their queries to a master instead of slave database. If you have to use expires, users with incorrect system clocks may get inconsistent results. Anyone know of a workaround?

Tags: cachebusting, caching, cookies, internet-explorer

Negative Cashback from Bing Cashback

2009-11-23T21:24:12+00:00

Negative Cashback from Bing Cashback

Some online stores show you a higher price if you click through from Bing—and set a cookie that continues to show you the higher price for the next three months. It’s unclear if this is Bing’s fault—comments on Hacker News report that Google Shopping sometimes suffers from the same problem (POST UPDATED: I originally blamed Bing for this).

Via Peter Van Dijck

Tags: affiliates, bing, cookies, google, microsoft

Django ponies: Proposals for Django 1.2

2009-09-28T23:32:04+00:00

I've decided to step up my involvement in Django development in the run-up to Django 1.2, so I'm currently going through several years worth of accumulated pony requests figuring out which ones are worth advocating for. I'm also ensuring I have the code to back them up - my innocent AutoEscaping proposal a few years ago resulted in an enormous amount of work by Malcolm and I don't think he'd appreciate a repeat performance.

I'm not a big fan of branches when it comes to exploratory development - they're fine for doing the final implementation once an approach has been agreed, but I don't think they are a very effective way of discussing proposals. I'd much rather see working code in a separate application - that way I can try it out with an existing project without needing to switch to a new Django branch. Keeping code out of a branch also means people can start using it for real development work, making the API much easier to evaluate. Most of my proposals here have accompanying applications on GitHub.

I've recently got in to the habit of including an "examples" directory with each of my experimental applications. This is a full Django project (with settings.py, urls.py and manage.py files) which serves two purposes. Firstly, it allows developers to run the application's unit tests without needing to install it in to their own pre-configured project, simply by changing in to the examples directory and running ./manage.py test. Secondly, it gives me somewhere to put demonstration code that can be viewed in a browser using the runserver command - a further way of making the code easier to evaluate. django-safeform is a good example of this pattern.

Here's my current list of ponies, in rough order of priority.

Signing and signed cookies

Signing strings to ensure they have not yet been tampered with is a crucial technique in web application security. As with all cryptography, it's also surprisingly difficult to do correctly. A vulnerability in the signing implementation used to protect the Flickr API was revealed just today.

One of the many uses of signed strings is to implement signed cookies. Signed cookies are fantastically powerful - they allow you to send cookies safe in the knowledge that your user will not be able to alter them without you knowing. This dramatically reduces the need for sessions - most web apps use sessions for security rather than for storing large amounts of data, so moving that "logged in user ID" value to a signed cookie eliminates the need for session storage entirely, saving a round-trip to persistent storage on every request.

This has particularly useful implications for scaling - you can push your shared secret out to all of your front end web servers and scale horizontally, with no need for shared session storage just to handle simple authentication and "You are logged in as X" messages.

The latest version of my django-openid library uses signed cookies to store the OpenID you log in with, removing the need to configure Django's session storage. I've extracted that code in to django-signed, which I hope to evolve in to something suitable for inclusion in django.utils.

Please note that django-signed has not yet been vetted by cryptography specialists, something I plan to fix before proposing it for final inclusion in core.

django-signed on GitHub
Details of the Signing proposal on the Django wiki
Signing discussion on the django-developers mailing list

Improved CSRF support

This is mainly Luke Plant's pony, but I'm very keen to see it happen. Django has shipped with CSRF protection for more than three years now, but the approach (using middleware to rewrite form HTML) is relatively crude and, crucially, the protection isn't turned on by default. Hint: if you aren't 100% positive you are protected against CSRF, you should probably go and turn it on.

Luke's approach is an iterative improvement - a template tag (with a dependency on RequestContext) is used to output the hidden CSRF field, with middleware used to set the cookie and perform the extra validation. I experimented at length with an alternative solution based around extending Django's form framework to treat CSRF as just another aspect of validation - you can see the result in my django-safeform project. My approach avoids middleware and template tags in favour of a view decorator to set the cookie and a class decorator to add a CSRF check to the form itself.

While my approach works, the effort involved in upgrading existing code to it is substantial, compared to a much easier upgrade path for Luke's middleware + template tag approach. The biggest advantage of safeform is that it allows CSRF failure messages to be shown inline on the form, without losing the user's submission - the middleware check means showing errors as a full page without redisplaying the form. It looks like it should be possible to bring that aspect of safeform back to the middleware approach, and I plan to put together a patch for that over the next few days.

Luke's CSRF branch on bitbucket
My django-safeform on GitHub
Details of the CSRF proposal on the Django wiki
CSRF discussion on the django-developers mailing list

Better support for outputting HTML

This is a major pet peeve of mine. Django's form framework is excellent - one of the best features of the framework. There's just one thing that bugs me about it - it outputs full form widgets (for input, select and the like) so that it can include the previous value when redisplaying a form during validation, but it does so using XHTML syntax.

I have a strong preference for an HTML 4.01 strict doctype, and all those <self-closing-tags /> have been niggling away at me for literally years. Django bills itself as a framework for "perfectionists with deadlines", so I feel justified in getting wound up out of proportion over this one.

A year ago I started experimenting with a solution, and came up with django-html. It introduces two new Django template tags - {% doctype %} and {% field %}. The doctype tag serves two purposes - it outputs a particular doctype (saving you from having to remember the syntax) and it records that doctype in Django's template context object. The field tag is then used to output form fields, but crucially it gets to take the current doctype in to account.

The field tag can also be used to add extra HTML attributes to form widgets from within the template itself, solving another small frustration about the existing form library. The README describes the new tags in detail.

The way the tags work is currently a bit of a hack - if merged in to Django core they could be more cleanly implemented by refactoring the form library slightly. This refactoring is currently being discussed on the mailing list.

django-html on GitHub
Improved HTML discussion on the django-developers mailing list

Logging

This is the only proposal for which I don't yet have any code. I want to add official support for Python's standard logging framework to Django. It's possible to use this at the moment (I've done so on several projects) but it's not at all clear what the best way of doing so is, and Django doesn't use it internally at all. I posted a full argument in favour of logging to the mailing list, but my favourite argument is this one:

Built-in support for logging reflects a growing reality of modern Web development: more and more sites have interfaces with external web service APIs, meaning there are plenty of things that could go wrong that are outside the control of the developer. Failing gracefully and logging what happened is the best way to deal with 3rd party problems - much better than throwing a 500 and leaving no record of what went wrong.

I'm not actively pursuing this one yet, but I'm very interesting in hearing people's opinions on the best way to configure and use the Python logging module in production.

A replacement for get_absolute_url()

Django has a loose convention of encouraging people to add a get_absolute_url method to their models that returns that object's URL. It's a controversial feature - for one thing, it's a bit of a layering violation since URL logic is meant to live in the urls.py file. It's incredibly convenient though, and since it's good web citizenship for everything to have one and only one URL I think there's a pretty good argument for keeping it.

The problem is, the name sucks. I first took a look at this in the last few weeks before the release of Django 1.0 - what started as a quick proposal to come up with a better name before we were stuck with it quickly descended in to a quagmire as I realised quite how broken get_absolute_url() is. The short version: in some cases it means "get a relative URL starting with /", in other cases it means "get a full URL starting with http://" and the name doesn't accurately describe either.

A full write-up of my investigation is available on the Wiki. My proposed solution was to replace it with two complementary methods - get_url() and get_url_path() - with the user implementing one hence allowing the other one to be automatically derived. My django-urls project illustrates the concept via a model mixin class. A year on I still think it's quite a neat idea, though as far as I can tell no one has ever actually used it.

ReplacingGetAbsoluteUrl on the wiki
django-urls on GitHub
Recent get_absolute_url discussion on the django-developers mailing list

Comments on this post are open, but if you have anything to say about any of the individual proposals it would be much more useful if you posted it to the relevant mailing list thread.

Tags: cookies, cryptography, csrf, django, html, logging, luke-plant, markup, ponies, projects, python, security, signedcookies, signing, xhtml

Adding signing (and signed cookies) to Django core

2009-09-24T19:31:20+00:00

Adding signing (and signed cookies) to Django core

I’ve been increasing my participation in Django recently—here’s my proposal for adding signing and signed cookies to Django, which I’d personally like to see ship as part of Django 1.2.

Tags: cookies, cryptography, django, security, signedcookies, signing

You Deleted Your Cookies? Think Again

2009-08-17T15:23:32+00:00

You Deleted Your Cookies? Think Again

Flash cookies last longer than browser cookies and are harder to delete. Some services are sneakily “respawning” their cookies—if you clear the regular tracking cookie it will be reinstated from the Flash data next time you visit a page.

Via Bruce Schneier

Tags: cookies, flash, privacy, respawning, security

Towards a Standard for Django Session Messages

2009-06-19T21:57:36+00:00

Towards a Standard for Django Session Messages

I completely agree that Django’s user.message_set (which I helped design) is unfit for purpose, but I don’t think sessions are the right solution for messages sent to users. A signed cookie containing either the full message or a key referencing the message body on the server is a much more generally useful solution as it avoids the need for a round trip to a persistent store entirely.

Tags: cookies, django, flash, messages, python, sessions, signedcookies

Integrating Facebook Connect with Django in 15 minutes

2008-12-17T13:18:38+00:00

Integrating Facebook Connect with Django in 15 minutes

Django authentication middleware that calls the Facebook REST API using a cookie set by Facebook Connect and checks if that person is your Facebook friend. Despite most of the magic happening on the server you still need Facebook’s JavaScript to set that cookie in the first place.

Tags: cookies, django, facebook, facebookconnect, javascript, middleware

Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

2008-08-27T22:18:49+00:00

Django snippets: Sign a string using SHA1, then shrink it using url-safe base65

I needed a way to create tamper-proof URLs and cookies by signing them, but didn’t want the overhead of a full 40 character SHA1 hash. After some experimentation, it turns out you can knock a 40 char hash down to 27 characters by encoding it using a custom base65 encoding which only uses URL-safe characters.

Tags: base65, cookies, cryptography, django, django-snippets, hashes, python, security, sha1, signedcookies, urls

Major Update to Prism

2008-03-10T14:03:29+00:00

Major Update to Prism

Mozilla’s site-specific browser tool can now use separate profiles (and hence separate cookie jars) for each instance, making it an excellent tool for protecting yourself against CSRF vulnerabilities in the web applications you rely on.

Via Ajaxian

Tags: cookies, csrf, mozilla, prism, sitespecificbrowsers

Fluid

2007-12-28T23:42:43+00:00

Fluid

Another site-specific browser toolkit for OS X (Leopard only), from Todd Ditchendorf. Again, it’s not clear if this does the Right Thing and creates separate cookie jars for every application.

Tags: cookies, fluid, leopard, macos, sitespecificbrowsers, toddditchendorf

Site-specific browsers and GreaseKit

2007-10-25T07:56:01+00:00

Site-specific browsers and GreaseKit

New site-specific browser tool which lets you include a bunch of Greasemonkey scripts. For me, the killer feature of site-specific browsers is still cookie isolation (to minimise the impact of XSS and CSRF holes) but none of the current batch of tools advertise this as a feature, and most seem to want to share the system-wide cookie jar.

Tags: chris-messina, cookies, csrf, greasekit, greasemonkey, javascript, safari, security, sitespecificbrowsers, webkit, xss

Quoting Mark Finkle

2007-09-30T16:08:58+00:00

Currently WebRunner applications share cookies with other WebRunner applications, but not with Firefox. WebRunner uses its own profile, not Firefox's profile. There is a plan to allow WebRunner applications to create their own, private profiles as well.

— Mark Finkle

Tags: cookies, csrf, firefox, mark-finkle, security, sitespecificbrowsers, webrunner

IE vulnerability allows cookie stealing

2007-06-06T09:53:31+00:00

IE vulnerability allows cookie stealing

Full exploit against the same-domain cookie origin policy, so malicious sites can steal cookies from elsewhere. Avoid using IE until this is patched.

Tags: cookies, internet-explorer, samedomain, security

IE and 2-letter domain-names

2007-02-15T00:33:13+00:00

IE and 2-letter domain-names

IE won’t let you set a cookie on XX.YY, where YY is anything other than .pl or .gr. Other browsers have better exception lists.

Via Mark Pilgrim

Tags: cookies, dns, internet-explorer, mark-pilgrim

Quoting Már Örlygsson

2007-02-06T00:01:59+00:00

There's an unfortunate side-effect to altogether eliminating the sub-domain name from your site URLs [...] Every cookie you may want to set for that site will automatically "bleed" down to all sub-domain-based websites you might want to add later.

— Már Örlygsson

Tags: cookies, urls

Ubuntu sugar cookies

2007-01-11T14:49:12+00:00

Ubuntu sugar cookies

Different coloured dough is used to bake the Ubuntu logo in to the cookies themselves, kind of like making sushi rolls.

Via Ned Batchelder

Tags: cookies, cooking, ubuntu

Thirty five year old cookies

2003-03-09T14:58:49+00:00

I'm finding myself slightly confused about the Google backlash washing around the blogosphere, which is summarised quite well by Gavin Sheridan. Most of the arguments against using Google unsurprisingly centre around privacy issues, in particular the "35 year cookie". I was under the impression that cookies could only be set for a maximum of a year, but having checked Netscape's Cookie Specification and RFC 2965 it appears I was mistaken.

So let's take a look at the cookies in question, via the Mozilla project's handy Web Sniffer utility (the front page for this tool is here):

HTTP/1.0 200 OK Content-Length: 3403 Connection: Keep-Alive Server: GWS/2.0 Date: Sun, 09 Mar 2003 14:34:32 GMT Content-Type: text/html Cache-control: private Set-Cookie: PREF=ID=05ba0c124de8df6e:TM=1047220472:LM=1047220472:S=Ke2RQCqjCEowS1x-; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

There it is - a 35 year cookie. Now let's take a look at some of Google's competitors.

AllTheWeb:

HTTP/1.1 200 OK Date: Sun, 09 Mar 2003 14:36:42 GMT Server: Apache/1.3.27 (Unix) PHP/4.2.3-atw Set-Cookie: atw-uid=CgVSBj5rUXoAAQnFAwSFAg==; path=/; domain=.alltheweb.com; expires=Sat, 09-Mar-13 02:36:42 GMT X-Powered-By: PHP/4.2.3-atw Last-Modified: Sun, 09 Mar 2003 14:35:00 GMT Expires: Thu, 19 Apr 2001 04:25:21 GMT Cache-Control: max-age=0, private Set-Cookie: PREF=frschk=1:_lm=1047220602; expires=Fri, 07-Mar-08 14:36:42 GMT; path=/ Connection: close Content-Type: text/html; charset=iso-8859-1

That's two cookies - one for 5 years and one for 10 years. Interesting to see that they're using their own modified version of PHP 4.2.3 :)

Teoma:

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sun, 09 Mar 2003 14:38:50 GMT Connection: Keep-Alive Content-Length: 6629 Content-Type: text/html Set-Cookie: CTST=yes; expires=Sun, 09-Mar-2003 15:03:50 GMT; path=/ Cache-control: private

That cookie lasts for about half an hour and doesn't contain a unique identifier. Plus they're running IIS!

Altavista:

HTTP/1.0 200 OK Set-Cookie: AV_POS=pos=1047220999574; path=/; domain=.altavista.com; Set-Cookie: AV_USERKEY=AVS03b87123ae55d80a1c21250000022; expires=Tuesday, 31-Dec-2013 12:00:00 GMT; path=/; domain=altavista.com; Server: AV/1.0.1 MIME-Version: 1.0 Cache-Control: no-cache,no-store,max-age=0 pragma: no-cache Expires: Sun, 09 Mar 2003 14:43:19 GMT Set-Cookie: AV_MKT=1; Domain=altavista.com; Path=/; Expires=Thu, 01-Dec-1994 16:00:00 GMT Content-Type: text/html; charset=ISO-8859-1 Content-Length: 10020 Date: Sun, 09 Mar 2003 14:43:19 GMT

What a mess! There's a session cookie (which only lasts until the browser s closed) recording what looks like the time I first visited the front page, a 10 year cookie with a unique ID and another cookie set to expire in 1994, possibly in an attempt to wipe out cookies set by an older version of the site.

So what have we learnt? Both AllTheWeb and Altavista set 10 year unique identifier cookies, while Teoma appears not to set any. At the end of the day though, what is the difference between a 10 year and a 35 year cookie? How many people are going to go a whole ten years without losing their browser's cookies, through a browser upgrade, PC upgrade, change of job or just wiping the cookie directory? Thee answer to that question is self evident, so in practise a 10 year unique identifier cookie is just as big an invasion of privacy as a 35 year cookie.

On the privacy front, AllTheWeb and Altavista are just as guilty as Google.

Tags: cookies, google, privacy