I'm debating if I should support cookieless sessions in my web app. It would look something like this:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
Since the URL is never constant, I don't think it's possible for a CSRF attack to occur. What other attacks am I openening myself up to?
... are there mitigations to those attacks? For example, can I set an expire header (or similar) to prevent the URL from appearing in browser history?
First, I assume you understand the most basic session ID security right:
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.
The most obvious risk of ID leak is with the Referer HTTP header. The simple solution to this is either:
<a href and others), all external embedded content (<img>, <object>...) and other external dependencies (<script>...), orMany Web application have zero outgoing links, and no content (esp. HTTP resources) from other users (which often has potential security/privacy issues, like Web bugs in emails).
This issue is usually described as a serious risk, but I disagree; if well understood it is easily managed.
Another practical issue is that users could fail to recognise the URL as the access key to the page, and share it with others, via email or in a forum. The risk is even higher if the document is public but the user might have some privileged access to it (like in SE), so sending the URL is the most obvious things to do to share a page with a friend.
When the page is by nature private and contains sensitive personal informations, such as the interface to manage your account, the risk is lower, but still exits.
I have personally witness more than one case of non-public URL being posted on a public forum, where the URL designates a web page random users could not ever legitimately access:
The issue I am pointing out here is not the web application design, but that the behaviour of a few uneducated users is to copy URL and post it even when the account manages some serious stuff (not just a lame forum account).
In the second example, it clearly shows that some user simply to not think about what they are doing: the shared URL was either useless for people willing to help, or a security risk. This is just simple logic, and zero technical knowledge was necessary to understand that: either an information is sufficient to access some other information, or it is not, so obviously this link was useless or a serious risk.
Usually when such URL is posted in a public place, some nice guy sees the URL, copies it and if the session is still valid, clicks "disconnect"; then he explains that serious issue to the user. Most people are honest, but there is a risk.
Another risk is when users want to share some data shown on one administrative web page (and not their access to such page), so they make screen shots of an administrative web page, failing to realise that the cryptic information in the URL bar is a secret. Making the URL very long so that it is not visible on user screen lowers this risk.
This case is very different, as the sharing of information is voluntary but the fact is contains the URL is not realised by the user.
Some technical issues exist with ID in URL; other issues exist with ID in HTTP cookies. In both cases it is up to the developer to understand the issues and fix them.
A user expectations issue exists with the "secret in URL" approach. The issue is not that the user can see the secret information, it is the fact the URL bar does not usually contain a secret.
You could think of a social engineering attack were the user is convinced to install the (very nice) Firebug plug-in, then activate it, go to the cookie panel and copy session cookies from there. But even a user willing to do everything you tell him might not be able to correctly accomplish each of these steps!
Copying the content of the URL is not just very easy (downloading malware on the Web and installing is easy enough for many users too); the user is used to copy and send URL. Some more experienced user may have explained a beginner how to send a link to a news article. The beginner might assume he can do that on any website and any webapp (even if the more experienced user never told him anything like that).
The problem here is that you can review your webapp design, you can get help from security experts and pay them to do a complete analysis of your application (complete from design to every line of code), but you cannot do a security analysis of your users (unless this webapp is only intended for your highly qualified employees and security consultants).
You could combine both ID in cookies and ID in URL, if:
I recommend that you look at web-keys, a method for inserting an unguessable token into the URL.
Web-keys include several techniques that are directly relevant to you. For instance, the design ensures that the token is not leaked over a Referer header, by placing the token in a URL fragment, like this: http://www.example.com/orderform.aspx#lit3py55t21z5v55vlm25s55. Read the paper here:
In addition to @curiousguy's excellent answer outlining some security risks to think about, let me mention one more: session fixation. It is challenging to defend against session fixation, when the session identifier is in the URL. Two candidate solutions are: change the session identifier when the user logs in (however, this is not enough to defeat login CSRF), and use the TLS session identifier as your session identifier.
The risk is that the URL containing the session ID is leaked. URLs are not supposed to contain secret information, and so are stored by servers, proxies and user agents, and shared by users.
The mitigations are:
