The new PCI-DSS 3.0 has introduced a number of new requirements. While some of the changes like penetration testing are getting most of the attention, there are numerous less obvious updates that are equally important. One of the new requirements that is that flying under the radar is 6.5.10: Broken Authentication and Session Management.
This requirement states:
Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include:
-
Flagging session tokens (for example cookies) as “secure”
-
Not exposing session IDs in the URL
-
Incorporating appropriate time-outs and rotation of session IDs after a successful login.
While this change may seem minor, it has some significant implications for web applications. This article is meant to guide you through requirement 6.5.10, to assist with your next PCI audit, and to help make your application that much more secure.
Session Obsession
HTTP is a stateless protocol. When you open a web browser and go to a URL the browser opens a connection to the server, downloads the page, and then closes the connection. When you click a link that whole process starts over. The web server does not understand that the clicked link, and the initial site visit, were performed by the same person.
A session allows the server to remember a user from the time he/she initially visits a URL, to the time they log off or close the browser. PHP, ASP, Java and all other server technologies have built-in functionality to create and manage session data.
To create a session, the server creates and assigns a session token to the client. A session token is a random string of characters of varying length depending on server configuration and development language. Each time a user clicks a link or visits a page within the application, the client must send that session token back to the server. This is how the server associates a user with an application session.
If a malicious user obtains the token for a live session they can replay that session, or worse, login as the user whom the token belongs. As such, protecting the session token is key to preventing numerous different attacks against web applications. Two of the three items mentioned above in requirement 6.5.10, deal with the handling of these session tokens.
GET It?
A session token can be passed between client and server in one of two ways. The first is via the HTTP GET method. In other words: in the URL string. This is a bad way to pass this data since a URL is not encrypted. This causes the session token to be recorded in web server logs, browser history and other places which an attacker could easily obtain. Additionally, the session token is readily visible to any malicious person performing a man-in-the-middle attack. To mitigate these vulnerabilities, it is best to pass session tokens via cookies.
The Cookie Monster
When placed in a cookie, the session token is sent to the server along with all the other pertinent data in the cookie. This data is sent as a part of the HTTP request and can be encrypted when SSL certificates are used. Unlike passing it in the URL, this makes it much more difficult for attackers to obtain the token.
A cookie with default settings, however, is not good enough. Requirement 6.5.10 states: “Flagging session tokens (for example cookies) as secure”. This means you should set the “secure” flag on the cookie. This ensures the cookie is only sent over an HTTPS connection which prevents it from being intercepted and captured.
As an added layer of security, Anitian recommends adding the “HTTPOnly” flag to the cookie. Doing this prevents Javascript from reading the cookie. This helps prevent malicious users from obtaining the session token via client-side attacks.
Timeout
A time out value, or expiration, is the amount of time that a session remains active while the user is idle. If set too low, users may complain about frequent re-logins. If set too high then a malicious user has plenty of time to compromise the session token and take control.
Ensuring the session expires after a certain length of time is critical to securing the session. The exact time required should be determined by business requirements and is different for each application. 30 minutes is the most common value used for timeouts
When a session expires, the token should be destroyed along with all the data which was stored in the session. This applies to data on both the client and the server.
Spin the Token
The last dimension of the new requirement states the application must rotate, or obtain a new, session token when we log in. Typically, a session is created as soon as a user visits the homepage of the application even before logging in. This means the session token is being passed in clear text regardless of the method used to pass it. Most often, SSL is only employed during and after successful authentication.
Unless your entire site is encrypted, a new session token should be generated after successful authentication. This ensures that the new token has only been sent over an encrypted channel and was never transmitted in clear text.
Conclusion
PCI DSS version 3 contains a new requirement 6.5.10, which has not received as much attention as some other requirements. Though less talked about, it is no less important to your PCI compliance or your organization’s overall security posture. Hopefully, this article will help you achieve your PCI and security goals.
