Session Support
HTTP is a stateless protocol. Once the server has sent data, it does not care or track what you do with that data. As far as the server is concerned, the transaction is complete. Any new response you make is a new transaction.
Web applications need to track a user between these stateless transactions, and this is typically done through session support. A unique ID is stored in an HTTP Cookie or as an HTTP GET variable. This ID is then used by the web application to track your use of the web application.
When you log in or otherwise authenticate to a web application, the fact that you are authenticated is recorded in the session data. At this point, anyone who supplies your session ID will be seen as the authenticated you.
Session Hijacking
When a user (or bot) steals the session ID of another user, it is called session hijacking. There are three ways this is typically achieved:
URL Extraction
Some web applications will pass your session ID as a GET variable, where it appears in the URL string. This is the only way to keep track of a user who is using a browser with cookies disabled. It is also extremely unsafe. Anyone can see the URL and extract the session ID, allowing them to masquerade as that other user.
DOMBlogger does not support session ID being passed via GET and will never craft a URL that contains the session variable of a user. If a user has disabled cookie support, that user is shit out of luck. The user will not be able to do anything with the web application that requires authentication or tracking.
Session Fixation
In a session fixation attack, the attacker gets the victim to connect using a session ID supplied by the attacker. The victim then logs in and that session ID is now authenticated.
The most common way this is accomplished is by getting the user to click on a link with the session ID as a GET variable. Since DOMBlogger does not honor session ID passed as a GET variable, it is not vulnerable to that method.
There may however be a bug in browser software that allows the attacker to forge a HTTP cookie on the victims machine as if it was sent by the target domain. In that case, if the forged session does not already exist, DOMBlogger’s session management will reject it and generate a new session, thwarting the attack.
However, if a session actually does already exist, DOMBlogger has no way of knowing the session was not created for the victim. To mitigate this type of attack, whenever a user authenticates themselves, the old session is destroyed and a new session is generated.
Cookie Theft
Cookies are sent by your browser to the domain they belong to whenever your browser requests a new page. They are sent using whatever protocol the request is made to. If the request is sent using the non encrypted http:// protocol, then the cookie is not encrypted. This means anyone on your subnet can sniff the contents of your cookie and extract the session ID.
There is even a FireFox extension that automates cookie theft and resulting session hijacking.
Where this tends to be a major problem is when connecting from the free open wireless networks that are popping up everywhere, but it can happen on wired networks as well.
The only way to thwart this is to use SSL/TLS so that the cookie is encrypted.
Sometimes session ID hijacking happens as a result of XSS attacks. DOMBlogger does set its cookies to http-only, reducing the likelihood that malicious JavaScript will be able to read the cookie, but it could happen.
Any action in the DOMBlogger CMS that requires a login requires the connection be secured via SSL. When you log in, your old session is destroyed and you get a new session, with your session ID stored in a secure cookie that will not be sent over HTTP.
Session theft of non encrypted connections to the CMS may happen, but since non HTTP connections do not have the ability to do anything to your content, this type of session theft can not harm you or your data.