Hướng dẫn is php session secure?

Nội dung chính

• HTTP and state
• Keep Your Apps Secure on Cloud
• PHP Sessions
• Using Sessions in PHP
• PHP Sessions security issues
• What is a Session Hijacking Attack?
• Types of Session Hijacking Attacks
• What Can An Attacker Do With a Session That Was Successfully Hijacked?
• PHP Session Security Best Practices, and importance of PHP session.cookie_secure flag
• Improve Your PHP App Speed by 300%
• “Is a PHP session secure?
• Can PHP session be hacked?”
• Share This Article
• Is PHP session secure?
• Can PHP session be hacked?
• Which are the best practices for secured session management?
• How do you use sessions to provide security in a PHP page explain?

HyperText Transfer Protocol started off as a stateless protocol. This means that every request to the server is self-contained, it carries all the context that the server needs to serve the requested web page. Every message that the client sends to the server can be processed on its own – the server does not maintain the state, nor information about the connection.

Web applications need a way to preserve a context about the visitor – from logged-in user identity, shopping cart in ecommerce stores, to longer-lasting data like purchase history or chat history in social network applications.

This is why it was necessary for HTTP, and all the applications building on top of it, to find solutions to manage this inherent statelessness in HTTP. The main solution is cookies.

PHP is maybe the most used programming language for the web (w3techs give it almost 80% ) and it has its own solution for this – PHP sessions. In this article we will describe PHP sessions mechanisms, we will explore PHP session security, and how to secure PHP session cookies.

We will see what are potential vulnerabilities, and php session security best practices.

HTTP and state

HTTP has been made extensible through its headers from the early days. This means that functionality can be added to HTTP requests and responses through user-definable headers.

Headers are fields in every request and response that can contain various pieces of metadata.

Cookies have been published as an addition to the HTTP standard by the IETF in 1997 , and the specification has advanced since then to be finally defined in RFC 6265 , titled HTTP State Management Mechanism .

Cookies are defined by IETF as a mechanism that consists of HTTP header fields that can be used by the servers to store pieces of data (state) in HTTP clients. This makes it possible for the server to keep a stateful context, called session, across multiple HTTP requests.

The user’s browser (the client) then sends back these cookies to the server on subsequent requests, making it possible for the server to reconstruct states, such as buyer’s journey, a shopping cart, or a social media account.

We can distinguish between session cookies and persistent cookies. Session cookies are transient – they only last for the duration of that particular browser session. They live in the browser memory. Because they expire when the current browser instance is shut down, they do not have an expiration date.

Persistent cookies have an expiration date, they are meant to last for a specific length of time.

They are used for things like the personalization of user experience, session management – including users logged in / logged out state, carts, and for tracking of user’s behavior.

Cookies usually store a very limited amount of data (maximum is 4096 bytes per website), and they are stored on visitor’s machines. This makes cookies limited and insecure – not enough to provide for the session needs of modern websites on their own.

Keep Your Apps Secure on Cloud

Cloudways offers 2FA, free SSL, and more advanced security features on managed servers that keep your application safe.

PHP Sessions

PHP as a web programming language belongs to the application layer. PHP builds on HTTP cookies to provide a mechanism to maintain context across multiple requests. For this, it combines custom, specific cookie header with its own session handler class:

SessionHandler implements SessionHandlerInterface , SessionIdInterface {
/* Methods */
public close ( ) : bool
public create_sid ( ) : string
public destroy ( string $id ) : bool
public gc ( int $max_lifetime ) : int|bool
public open ( string $path , string $name ) : bool
public read ( string $id ) : string
public write ( string $id , string $data ) : bool
}

This mechanism can be extended or completely rewritten by inheriting the SessionHandler class or by implementing SessionHandlerInterface.

In PHP, sessions are by default persisted as files on the server. Files carry names of their respective session ID-s. When the session is initiated, PHP sets a PHPSESSID cookie with a session id. Later, when the visitor’s browser returns that cookie on each request, the server associates it with the session data in the file related to that session. The result is a continuous session state across multiple pages on a website.

Using Sessions in PHP

A session in PHP can be started with a call to a function session_start() . This function either starts a new session, or restores an existing session passed to the server in a cookie, or in POST or GET request parameters. $_SESSION superglobal array is then used to set or to get variables in a session.

If we then want to use session variables on other pages of the same website, another PHP document needs to use session_start() . This will make $_SESSION variables, which may have been set on other web pages/documents, available on the current one.

session_close() commits the changes to $_SESSION to the disk

session_destroy() function will destroy all the session data. To fully remove the session, it is also necessary to unset the session ID, and explicitly delete the session cookie. Beyond these basics, PHP has a host of other functions for session handling .

The functionality that PHP sessions try to provide – persistent data across the visits to pages of a website – is indispensable to modern websites. PHP sessions implementation however is a point of contention.

Since session data in PHP is written to a file on the server by default, and the file is locked during the script execution, this can present challenges in terms of performance and scaling.

PHP sessions also present challenges to the normal caching mechanism – caching pages with PHPSESSID cookie set could seriously compromise the website while bypassing the cache for pages with PHPSESSID would mean bypassing cache on the entire website.

And then, there are security issues.

PHP Sessions security issues

PHP sessions are a step forward in regards to security compared to a system where all the session data is stored within cookies. PHPSESSID cookie merely stores a reference ID for a session file that lives on a server.

PHP default setting for a path to save session files, which we can find in php.ini configuration files is session.save_path = “/tmp” . This means that session files could effectively get compromised by other users.

This issue is particularly alarming when we recall that the majority of PHP-powered websites live on shared servers with multiple tenants.

The most common of all session exploits is Session Hijacking.

What is a Session Hijacking Attack?

Session Hijacking happens when a malicious party gains illegal access to another user’s session. The attacker will first obtain the session ID belonging to another user. Then he will use this ID to gain full access to the other user’s session. The session ID is enough for the server to give access to the respective account.

Theoretically, the Session ID could be obtained by prediction or guessing (brute force), but the most likely way is for the Session ID to be stolen. Both brute force attack, or predicting the ID is much less likely to happen.

There are several vectors by which an attacker can gain access to users’ Session ID.

Types of Session Hijacking Attacks

Session Hijacking can happen in many different ways – here we mention only those which are more notorious:

• XSS or Cross-Site Scripting – this is an attack that happens when a third party succeeds to inject javascript into the body of a website visited by the victim. Let’s say that a website XY uses GET variables, and does not properly sanitize them.An attacker can use javascript in a GET request and get it injected into the body of a web page, gaining the same level of access as the website’s own javascript. For example, it can get the content of the PHPSESSID cookie, and then send it to the attacker.

• Session Sidejacking – this type of attack happens with Man In The Middle attack vector – in situations when the attacker is positioned between the source and the destination of the traffic. The attacker will listen to requests and responses, and, unless the traffic is encrypted, he can capture the Session ID.
• Session Fixation happens with vulnerable web applications, which don’t insist on always setting a new Session ID upon user authentication, but instead accept an existing Session ID when it exists. In this type of attack, the attacker will forge a valid, but unused Session ID, and then, through various schemes, make a valid user authenticate using that ID. After that, having possession of the authenticated user’s ID, the attacker gains access to the user’s session.
• Session Prediction – in this type of attack, the attacker will usually have some knowledge of how the application generates Session ID-s, and will then try to guess other user’s IDs using the same method. This is where the randomness of Session ID-s generation plays a big role.

What Can An Attacker Do With a Session That Was Successfully Hijacked?

Once an attacker gains access to the session that belongs to a legitimate user, the server will grant him all authority that the original user has. As such, the Session ID can be likened to a key that grants its owner access to the house, regardless if he was the house owner or not.

This attack will often be focused on users & sessions with administrative access, so in those cases, the attacker will gain administrative rights on the compromised website.

PHP Session Security Best Practices, and importance of PHP session.cookie_secure flag

Before continuing to different measures we can take to prevent our sessions from being exploited by attackers, it is important to say that vulnerabilities connected to PHP sessions are not something specific to the language itself. They are not an inherent flaw of PHP – other technologies require similar measures to mitigate these same vectors of attack.

So what are common-sense measures we can take to mitigate Session hijacking attacks?

• XSS (Cross-Site Scripting) Attack – mitigation against this type of attack is not sessions-specific. The website needs to prevent any kind of user input from being executed in the visitor’s browser. This simply means that any user input, through forms or GET parameters, or other needs to be sanitized before it is used. This is a general security measure for web applications, for this and other types of attacks (e.g., SQL injection). The main two functions in PHP used to sanitize strings are htmlspecialchars() and strip_tags(). htmlspecialchars() converts special characters into html entities, and strip_tags() will simply remove all the HTML tags, including