22

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?

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 1
    "_... are there mitigations to those attacks?_" "only well informed users are allowed to use this application" is a mitigation technique? – curiousguy Jul 27 '12 at 07:40

3 Answers3

24

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.

Web-browser leaks

The most obvious risk of ID leak is with the Referer HTTP header. The simple solution to this is either:

  • to forbid outgoing all links (<a href and others), all external embedded content (<img>, <object>...) and other external dependencies (<script>...), or
  • to change all outgoing links to go to an internal redirection page (which could be another security issue, depending on how you implement this).

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

User-behaviour related leaks

Voluntary sharing of URL with other users

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:

  • link apparently to a webmail: the link was not working, I presume because the session was cookies based and not URL based;
  • link to the configuration page of a modem-box in the administration Web application of the ISP; the administration application is on a public Web server and requires authentication (this allows ISP clients to view or change some of their account information from anywhere). Giving others access to this interface includes: giving bank account information, ability change account password, change account email contact address, buy optional features, terminate account ... or just click the "disconnect" button to terminate the session.

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.

Sharing of screen shots (revealing URL)

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.

Technical and user issues

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

Combination?

You could combine both ID in cookies and ID in URL, if:

  • both ID are different, independent cryptographic random numbers
  • and each ID contains sufficient entropy for secure protection if the other ID is leaked.
OzzieOrca
  • 103
  • 3
curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • 1
    +1 Hmm, what about wrapping the page requiring a session in an iFrame, hiding the URL – makerofthings7 Jul 27 '12 at 14:14
  • @makerofthings7 Interesting idea! – curiousguy Jul 27 '12 at 14:45
  • 1
    @makerofthings7 - still presents an non-neglectable amount of risk of voluntary URL sharing by accessing it through a few mouse clicks and doesn't change anything for being a part of the referrer string in external requests. It does however completely remove the risk of sharing the URL with a screenshot (but sufficiently long ID that wouldn't display in the address bar in its entirety does that almost equally well). You should also pair your user ID with user IP and user-agent string, though you can't depend it's always going to narrow it down to a single user. – TildalWave Mar 09 '13 at 06:03
  • @TildalWave Very true... though I didn't expect anyone to seriously consider this, especially now with all the issues with iFrames – makerofthings7 Mar 09 '13 at 07:56
  • @makerofthings7 - Oh I'm not, it was brought to my attention by a fragment of another topic. Which iFrames issues are you referring to? Are there any new ones I overlooked? I thought it's supposed to be getting slightly better now with wider `X-Frame-Options` support, especially for `SAMEORIGIN`. Or you were thinking of exactly this being an issue due to inconsistent support in user-agents and web servers and developers taking it too lightly? – TildalWave Mar 09 '13 at 15:58
  • @TildalWave Nothing new per-se but Java exploits are common with this vector... not exclusive to it, but common with it. – makerofthings7 Mar 09 '13 at 18:08
  • Its also a PITA to ensure all your URLs are populated with the session id - even when you have an automated mechanism. – symcbean Jan 24 '16 at 22:16
  • 1
    About your referer leak, one could use the referer policy header to modify these. – Braiam Feb 06 '19 at 11:15
4

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • +1 for session fixation. Altough you can do cokkie-based session fixation by using MITM to inject a cookie. How reliable is the use of TLS session ID for sessio tracking. Are there some sites using this method? – ysdx Jul 27 '12 at 19:43
  • @ysdx, Using the TLS session ID is highly secure, but I don't know how stable the TLS ID is. I don't know of anyone who is using it (probably because support for exposing the TLS session ID to the web application is poor in most webservers and web frameworks, and because cookie-based session management is the overwhelming norm). You'd have to test reliability. One possible concern is that users' TLS session IDs might change; I don't know how stable it is. TLS does have mechanisms for session caching and resumption that might address this, but they may not be perfect: I don't know. – D.W. Jul 27 '12 at 21:44
2

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:

  • Always use TLS to prevent sniffing attacks and proxies from storing the URL
  • Always prefer cookies, and only set cookieless sessions if the user agent does not support cookies.
  • Use short timeouts on the session IDs to reduce the window during which the URLs are valid.
  • Tie the session to the client's IP address and invalidate the session if it is accessed from a different IP.
mgorven
  • 596
  • 5
  • 11