tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Getting application root path before servlet is initialized?
Date Fri, 24 Feb 2017 22:03:22 GMT
Hash: SHA256


On 2/24/17 12:32 PM, Martin Knoblauch wrote:
> On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz < 
>> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> Martin,
>> On 2/22/17 5:19 AM, Martin Knoblauch wrote:
>>> On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas
>>> <> wrote:
>>>> On 21/02/2017 13:31, Martin Knoblauch wrote:
>>>>> Hi,
>>>>> is there a way to find the absolute path of the
>>>>> application root before the servlet is initialized?
>>>>> Alternatively: is there a way to defer the initialization
>>>>> of a datasource until the servlet is initialized?
>>>>> Background: I have extended "org.apache.tomcat.jdbc.pool.
>>>> DataSourceFactory"
>>>>> to automatically set credentials so that they are not
>>>>> stored in the "Catalina/localhost/XXX.xml" file. Instead
>>>>> they are taken from encrypted values in a file below the
>>>>> application root. Works fine if I know that
>>>> path
>>>>> at "createDataSource" time.
>>>> And the decryption key for that file is stored where?
>>> Thanks for link. It clearly reflects my opinion as well
>> Good. At least you know this is all a farce.
> Not sure I'd call it a farce, but yes this is all hide and seek
>>> , but the customer demand is:
>>> - no plain-text credentials (Big multinational company
>>> security policies - fight them if you need the fun). And yes,
>>> this is all about making auditors happy
>> Obviously, you are still failing this requirement. The only 
>> requirement you are satisfying is "no plain-text credentials in
>> a standard configuration file". What you are doing is moving the 
>> plain-text credentials into a non-standard configuration file.
> No, there are no plain-text credentials stored anywhere. They are
> stored crypted with an api to decrypt them.

... and the keys passed-into the API.

> But of course
> - how good is the decryption key protected

It must be plain-text somewhere. You can obscure it all you want, but
you are just buying yourself a small amount of time.

> - what about the in-memory copy of the credentials once the
> datasource has been initialized

They are always available, since the connection-pool manager may have
to open a new connection at any moment.

> - what about snooping them on the network when the DB connection is
> built. OK. We are using SSL there.

TLS should do your job, here. Of course, nobody needs your credentials
if they can sniff the network traffic. So TLS is important to ensure.
I would even require it as a condition of all non-local connections.

> This makes most auditors and penetration testers sufficiently
> happy.
>>> - minimize the locations where credentials are stored. This is 
>>> only lightly related to the decrypt issue. Having to store 
>>> identical stuff in more than one place is opening up all other 
>>> sorts of practical issues
>> This is a reasonable requirement, as it helps reduce the attack 
>> surface. But when the attack surface is "a file on the disk",
>> getting owned means you are owned, regardless of the location of
>> the file(s).
>> As for the location of the secrets file, would it be possible to
>> store it *outside* of the web application's on-disk footprint?
>> That will in fact make you more secure. Let's say for example
>> that a vulnerability exists in the DefaultServlet, or one of your
>> application's own servlets. It allows path-traversal or whatever.
>> A file living in your application will then be potentially
>> remotely-fetchable :( If you move that file outside of the web
>> application, you have a better change of preventing that kind of
>> thing.
> There is no secrets file. As I said before - the app has obfuscated
> the key deep in the source...

So the secrets file is called MySecrets.class :)

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message