The HTTP protocol and web servers are stateless by nature. This means that there is no way for them to track user activity. The web server treats every request as a new one. For this reason, browsers and web servers need to use session tokens.
Session tokens are unique pieces of information shared between the browser and the server. They make it possible to track user activity and differentiate between users. For example, an e-commerce application may use a session token to identify the shopping cart that belongs to a particular user.
There are different ways to share session tokens. They are most commonly included in cookies but alternative methods are quite widespread as well. Such methods include sending the session tokens directly in URLs, in dynamically rewritten URLs, or hidden in the HTML source of the web page. These methods are also often combined and on the rise because users often disable cookies in web browsers due to privacy concerns.
Why Is Using Session Tokens in URLs a Bad Idea?
The easiest method of sharing session tokens is placing one directly in the URL, for example, http://www.example.com/account.php?token=12345. Using such an URL, a user who was authenticated earlier can access their account. This method is not inherently insecure but if the session token is not validated by the server, it could lead to potentially high-risk vulnerabilities.
If you place a session token directly in the URL, it increases the risk of an attacker capturing and exploiting it. Anyone who follows that URL inherits the session. When you connect to the web server using HTTPS the risk is less than if you use HTTP but it is still a threat.
HTTPS URLs are encrypted during transmission but they are often stored in server logs. Anyone who gains access to the logs can exploit these tokens. In the worst case, this can lead to session fixation or session hijacking. Therefore, even though we classify the Session Token in URL vulnerability as low severity, you should not take it lightly.
What Are the Alternatives?
Applications should use alternative methods of sharing session tokens, for example, HTTP cookies. You should also encrypt such applications because it is possible to retrieve session tokens from unencrypted applications.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Bernhard Abele. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/Rdm0R7Ad8Rk/