HTTPS client certificate authentication security issues. Part 2/3

In the first story, I described some issues related to client certificates authentication implementations in environments with load balancers. This time I’d like to mention some typical issues in custom certificate validation processes when a developer is doing this itself in application code.

Let’s formalize the task as a custom authentication based on user certificates. Now, let’s divide this task from the architecture perspective:

  • all the crypto things should be solved by 3-rd party libraries
  • all the business logic should be implemented by yourself

Or more technical:

  • PKI library will check the certificate to give you some details about the user
  • everything else you should do by yourself, including authentication, user management, and even certificate validation sometimes

The first pitfall is PKI implementation, means in particular how to configure your library to avoid all the risks.

The second one is how to do your own business logic in the right way.

PKI libraries implementation issues

First of all, you need to understand that PKI (crypto) library is not a function implemented by somebody to solve your authentication task, but a framework that allows you to deal with cryptography and public keys somehow for whatever you want. It could be authentication, hashing, encryption, digital signatures or other needs.

The most popular mistakes here are:

  • incomplete certificate validation. Various issues, from incomplete status validation like avoiding OCSP to accepting self-signed certificates and pinning issues. I even saw once the case, when any certificate was valid if it was signed by ANY root certificate with a particular certificate ID (series number).
  • incorrect certificate validation process. The only example I would like to share here is my favorite SSRF scenario when OCSP/CRL validation stage goes prior to signature validation phase. As a result, attackers can do SSRF with any-signed client certificates right during the certificate validation process.

Authentication business logic issues

The second group of mistakes comes from authentication business logic, in a fact, from your own way of using PKI.

I’ve seen all the following issues:

  • trusting untrusted data. For example, if the certificate was invalid, put some details from it to the logs database table (and sqli during that of course).
  • hardcoding. Serial numbers, OIDs, names, and other data that placed right inside the code.
  • subject matching/mapping issues. There are no users (subjects) inside client certificates, just some information about them are there. You need to use this information to understand who is here. It’s still the case when overlaps in email or names could affect authentication.

I hope it was at least interesting for you if not useful ;) Cheers!

CEO at Wallarm. Application security platform to prevent threats and discover vulnerabilities in a real-time.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store