Payment Application Processing Interfaces (API)’s are created to get some sort of task performed and if exposed to the internet can allow unscrupulous people to attempt to call your API to do work for them instead as a valid user.
Therefore, it’s always important to authenticate users to services. To do this, an API needs to send a unique identifier to the user or key. The goal for the application server is to match a specific user to a resource during the duration of the visit. However, it still serves a purpose as a secret token for authentication and privileges are associated by the application server with the key.
Here’s what a session token or cookie looks like:
GET /something HTTP/1.1
Cookie: X-API-KEY=abcdef12345
See that key and equals sign up there? Doesn’t it look like a password? It is in a way. We can think of keys as a special password per browser session. For most of the life of the internet, these keys have traditionally never been marked as “secure” allowing them to be easily stolen and they never expire. This whole time they have been sent in clear text in billions of browser sessions for years. A big problem.
The purpose of PCI DSS requirement 6.5.10 is to help facilitate wise authentication and session management.
Without proper session management it would be possible for unauthorized individuals to sniff traffic traversing the internet and steal the API session key, user credential or session token and inject it into a new session thus fooling the application server. PCI DSS requires us to flag session tokens as “secure” so we can protect this mini session password.
Setting the secure flag is usually accomplished on the server’s side of the client/server model.
The application server usually generates this key and sends it to the user’s browser. When this happens the application server can either send this password in clear text or mark it as “secure” and use an encrypted tunnel to send it. Qualified Security Assessors often interview clients and usually must take the developers word that they mark cookies as secure. Thanks to the OWASP project, QSA’s can inspect these specific web development technologies of the cardholder data environment to ensure that indeed this requirement is in place.
We’ve observed that in the payment card industry developers love to use Java for creating their payment pages. For Java, its useful to inspect the ‘java-web.xml” file and look for a “true” setting in the “session-config” header:
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
Similarly, payment API developers also host java code on Apache Tomcat web servers.
Most of the time they set the secure attributes on cookies automatically (in Tomcat versions 6 and above). However, if you’re inspecting an older version of Apache Tomcat, the JSESSIONID response header may have to be manually configured where:
response.setHeader(“SET-COOKIE”, “JSESSIONID=” + sessionid + “; HttpOnly”)
Many web pages also can use ASP.NET to develop a payment page containing a credit card number. In this case ask the administrator to display the contents of the “Web.config” file and look for the, “<authentication mode=”Forms”>” header. There should be an object named “requireSSL” and should be set to “true”. It should look like this;
<system.web>
<httpCookies httpOnlyCookies=”true”/>
<httpCookies requireSSL=”true” />
</system.web>
For clients who use PHP programming language for web development you can forever set session cookies as secure in the “php.ini” file using the “session.cookie_httponly = ‘True’” parameter.
Lastly, the OWASP.org team encourages everyone to validate that web application set session flags as secure by using the OWASP Zed Attack Proxy (ZAP) tool. Please recommend it to your clients. It’s a free, community-led open source software organized into comically enough, “Breakers” and “Builders”!
Ref: https://owasp.org/www-community/controls/SecureFlag
Ref: https://owasp.org/www-project-zap/
Ref: https://en.wikipedia.org/wiki/Application_programming_interface_key
Ref: https://en.wikipedia.org/wiki/Session_ID
Ref: https://www.troyhunt.com/owasp-top-10-for-net-developers-part-9/
____________________
SecureTrust, a Trustwave division, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.
CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.
____________________
Written by Dennis Steenbergen
Dennis Steenbergen is a Qualified Security Assessor (QSA) working for SecureTrust’s EMEA Global Compliance and Risk Services as a Security Consultant. He holds a Master of Arts in Information Management from Webster University and Bachelor of Arts degree in Economics from Colorado State University.