Today, the most commonly used type of web-hosting plan is shared web hosting. In shared web hosting, the client is given access to a limited number of resources which he can use to host his own web site/web application. In this presentation we will mainly focus on the security of session identifiers on shared hosting environments. Session identifiers are the mechanism which helps developers turn the stateless HTTP(S) protocol into a stateful one. The fist time that a user, visits a website/web application , he is assigned a session identifier (typically consisting of a long pseudo-random alphanumerical). On the server-side, the web applications binds the identifier with information about the user (such as if he is logged in, his administrative privileges, etc.). On every subsequent request, the client provides the web application with the ID that was first entrusted to him. This way the web applications can recognize the user amongst many requests and respond appropriately. Due to their great significance, session identifiers have been among the first targets of attacking when it comes to web application hacking. A successful capture and replay of a valid session identifier means instant authentication for the attacker. The most common attacks against sessions so far have been session stealing and session fixation both of which target the client. In the context of this presentation, we will present two new attacks against session identifiers that are specific for websites which make use of shared hosting plans. We have named the attacks, “Session Snooping” and “Session Poisoning”. The attacks are based on the fact that web applications that use the default functions for session creation and management are not able to distinguish between a session that was created by themselves and a session that was created by a different web application located on the same physical server. This, combined with the unfortunate fact that in most shared hosting plans session stores are common between all websites, provides the attacker with the ability to force web applications to use sessions that they didn’t create. It also allows his own applications to able to read and modify sessions created by other applications. In this way, an attacker can circumvent authentication procedures, steal private data, evade web application firewalls and use this attack as an intermediate step to launch other attacks such as SQL injection and command execution. We will also present some of the most popular Content Management Systems (CMS) and see how they respond to our attack. Out of the ten CMS tested, nine use sessions and two of these systems use the default session management functionality provided by PHP, and are thus vulnerable to the Session Snooping/ Session Poisoning attacks. Lastly we will discuss techniques that web programmers and administrators can use to protect their websites against these two new attacks.