When we discuss correct session management and how applications currently handle the session management of the user, we refer to this as "session management." There are a number of essential components that are typically utilised by apps, such as tokens that are stored in the header or in the cookie. It is necessary to make sure that the appropriate protection is being applied whenever utilising or adding any values to the cookie. If this is not done, the cookies can be compromised, which is why they require the appropriate protection. In today's post, we will delve deeper into the topic of cookie security and the factors that should be taken into account when securing them.
Securing the Cookie
What is Cookie
Each online application gives each user a one-of-a-kind session identifier that is kept on the client side, and the values that are assigned to this identity are kept as a variable in a cookie so that the application can identify the user and better serve them. The application is able to determine which user is currently logged in and provide that user with content that is tailored to their specific areas of interest. Every time a user accesses the application based on the path variable, a cookie is sent along with the request. This allows the application to verify the user and ensure that it is providing service in accordance with the requirements. In addition to ensuring that users are authenticated correctly, this can also be used to enforce any necessary authorization. These session tokens found in cookies can be thought of as a temporary username and password for the user's account. They become invalid as soon as the user signs out of their account.
Let's understand the different flags that can be used in the cookie to make it fully secure
HttpOnly
HttpOnly Flag is not set to true
It is necessary to set the HttpOnly flag in the cookie in order to prevent client-side scripts from gaining access to the contents of the cookie. If this flag has not been set on the cookie, then client-side scripts, including malicious JS payloads, will be able to readily access the cookie by using a straightforward attribute document. cookie.
Attackers always want to gain access to the cookie in Cross-Site Scripting attacks so that the cookie can be accessed and moved to a domain that is controlled by the attacker. After the cookie has been compromised, if additional protection measures are not taken, it is possible that the cookie can be used to take control of the user's account. Therefore, if the session token and other sensitive information are saved in the cookie, an attacker will have access to them and will be able to exploit them for unethical means. Accessing a user's account for malicious purposes, changing the user's profile, or compromising the user's entire set of information are all examples of malicious intents.
Application owners need to set the "HttpOnly" flag to "True".
There are a couple of attributes that need to be set in a Cookie, "HttpOnly" is one of them.
setcookie($name, $value, $expire, $path, $domain, $secure,$httponly);
At the time of setting the cookie, the value of the httponly flag should have to be set as "$httponly=True".
Example: In the snippet below, the HTTPonly is set in the cookie.
setcookie("userCookie", $userl, 0, "/", "www.example.com", TRUE);
Setting the Expiration time
Cookies that store sensitive information such as a session token and other information should be required to have an expiration time set on them. Because these cookies contain a session token that can be used to access a user's account, leaving them active for an extended period of time poses a security risk because a hacker who successfully compromises one of these cookies could gain access to the user's account for an indefinite period of time. Therefore, it is absolutely necessary for there to be a need that an expiration time be placed on the cookie. The majority of organisations, such as those that deal with sensitive data (such as banking websites), typically have a shorter expiration time, and they delete the cookie after approximately 15–20 minutes have passed since it was generated.
In order to set the expiration time you can use this technique
setcookie("userCookie", $user, time()+60*60*24*365*1);
Following this, a copy of this cookie will be kept on the user's computer for a period of one year. When the allotted time has been exceeded, it will terminate on its own automatically. Because doing so improves both the safety of the user account and the information it stores, it is always recommended that the expiration time be set to either 24 or 48 hours.
Secure Attribute
This is accomplished using the cookie's secure attribute. In the event that this characteristic has been changed, the cookie will not be able to travel across the encrypted channels (on http). When users connect to a public Wi-Fi network, an attacker who wishes to carry out a Man in the Middle Attack typically forces them to connect using unencrypted channels. This is because, if the connection is made using unencrypted channels, the attacker will be able to read all of the information that is transmitted from the user's computer. If the cookie does not include that attribute, it will flow via the unencrypted channels as well, making it possible for an attacker to compromise it and get access to the user's account.
The "Secure" flag for the application needs to be set to "True" by its owners. Therefore, even if the attacker succeeds in convincing the user to carry out the communication over an unencrypted channel, the cookie will not be transmitted along with the request, and the attacker will not be able to obtain it.
setcookie($name, $value, $expire, $path, $domain, $secure,$httponly);
While setting the cookie value, admin can set "$Secure=True".
Conclusion
Cookies play a significant role in application security so make sure to implement it carefully. In this blog, I discussed some basic techniques related to Cookie in the Source code review process. Either the security team can find the issue manually or they can use the automated tools for that. There are so many tools for secure code review available in the market.