0

I'm working on a JAVA web application running on Tomcat. A session token is generated and stored in a cookie when a user authenticates. Unfortunately, when tracing is enabled, Tomcat dumps the value of the cookies of incoming HTTP requests. This includes the session token in the JSESSIONID cookie!

Extra information:

  1. The application runs on the customer's premises.
  2. Tracing can be enabled in production by the customer itself. That will not gonna change. I can't prevent it. This point is outside the scope of this question.
  3. Tomcat is dumping the secret (as a side effect), not my own code.
  4. I don't need the session token to be traced.

Questions:

  1. Is this a problem? Should I be concerned?
  2. How to prevent Tomcat dumping the cookie value?
  3. As far as I understand all applications in the world running on Tomcat have the problem. How the others applications handle the problem?

Note: Best answer will provide answer to question #3 with pointer to documentation/blog/article.

Improve this question
1
  • 1
    Logging sensitive information can be a problem, true. How severe this is, depends on the threat model. Generally speaking, an employee visioning the logs can impersonate any logged user, and this is bad. Unless the threat model allows that. You can mitigate this by making the app log what's actually needed for the debug sessions, eventually masking sensitive values. Maybe you can even set an higher logging level for the specific class that's dumping the headers. The only way to mitigate this would be to restrict access to the logs, which would be detrimental. Commented Jan 29 at 15:27

2 Answers 2

Reset to default
0

Yes, this is a problem. Unless you absolutely need the session tokens, you should not log them to avoid leaks. If you check the server documentation, I'm fairly sure you'll find a way to fine-tune the logging and only include data you actually need. Alternatively, remove all unwanted sensitive data from the raw server log before storing it anywhere.

If you do need the session keys, then you have to take extra care to protect the log: Restrict access to the people and processes who need it, don't let old logs sit around for too long, be careful with backups etc.

Improve this answer
3
  • It does not answer fully my question but it helps me to refine my question. Please, elaborate and update your answer with my updated question. Commented Jan 30 at 9:08
  • @Algiz: I think I've given you enough information to solve the problem: Either check the Tomcat documentation for a way to fine-tune the default logging mechanism. If you cannot find any option, then implement your own logging mechanism which omits the headers. How exactly this works is explained in the logging documentation. Note this isn't a Tomcat support forum, so it's not really our job to give you a step-by-step guide. Commented Jan 30 at 12:55
  • @Algiz: Your third question is irrelevant for the problem. And again, it's not our job to look up some blog post or article for you, just so that you can copy somebody else's solution. Commented Jan 30 at 13:02
0

It's working as designed and it's not a problem. What is a problem is to have tracing enabled when the application is in production.

During development and testing, you want to have as much information as possible during a trace, so having the session cookie on the logs is expected. Tracing can be configured to log POST parameters, SSL keys, and anything the application have access. And this is not a problem.

So if you are on the development phase, it's ok. If it's in production, disable the trace.

So, answering after your edits:

Is this a problem? Should I be concerned?

No, it's not a problem and you should not be concerned.

How to prevent Tomcat dumping the cookie value?

You cannot. It's on a layer outside of your control. If you cannot configure Tomcat, you cannot stop it from dumping anything.

As far as I understand all applications in the world running on Tomcat have the problem. How the others applications handle the problem?

It's not a problem. It's working as designed. Having strong tracing facilities is a selling point for an application server. The more tracing options, the better for developers to create better applications, troubleshoot and performance tune the applications.

If you don't trust the Tomcat admin, you will have to host your application elsewhere.

Even if Tomcat didn't had a trace setting on the configuration, the admin can load extra classes on your application to dump all request data to a file. Or run a reverse proxy before Tomcat, so your application does not even know someone dumped the data. Or run a packet trace on the OS (like tcpdump or wireshark) and grab anything, down to the TCP, IP and TLS handshakes.

There's nothing you can do except to tell the customer that using Trace on Tomcat is a security issue he must address before putting the application on production. It's not a technology problem, but a policy problem.

Improve this answer
1
  • Tracing can be enabled in production by the customer itself. That will not gonna change. This point is outside the scope of this question. Commented Jan 30 at 8:45

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.