tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Getting application root path before servlet is initialized?
Date Fri, 24 Feb 2017 22:03:22 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Martin,

On 2/24/17 12:32 PM, Martin Knoblauch wrote:
> On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz < 
> chris@christopherschultz.net> 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
>>> <markt@apache.org> 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?
>>>> 
>>>> https://wiki.apache.org/tomcat/FAQ/Password
>>>> 
>>>> 
>>> 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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsK2qAAoJEBzwKT+lPKRYQbEP/RamJmHnm+G3Pz4hCprsGrqA
n6xCcdCyU2jMqHpIdnhVHNLoMAYmeRDHpetn4GTWLff3TNjcljRfEdmPggQOy4Ei
bE7sq/1A79TS/Y+Xo2/QuYdMFHm0F0nAuyMsVdJ/XzoMuQtNlWjq3SlZQcYzkzGC
aofnpd7FjtePrCyBeSQfyAZ+lep8Tjvsg0tzH03eUMsgM6RJ5E0jcloBbqm7hsVP
oo6oS4cwts/Vq+PnNbmTiQaQA/wQWEvZRLQctflyeRYjvcLr5/ABJ1iBJc6tdTXA
zY8qd8Zx2DMOdsSvVLSdjATm1YvT+ucQl5O1TJ6AXJKRa+f76eM17kr7fafOyG4U
IeQgCwS9/q0UB4HH14bvsb9jhSXup3j5aNHMGgI6xyZtbaRoI8jrwQvGd/KNXDjQ
jXtr7xBBWFTxE6r3bk5afJvHC+A3n0KlBySoQ4S0Wg6B37QFW+ThU4sTpOKrH/Bs
NiM0r+qEDXA255O3LuvYJJUYPBGSL0AD7UaV14LWiFN9iPgWZyB633JW8Ngnm5ZO
9Ogp0udT4zjuZc2Q20MNuheR9LFKDcji0K92STGbhhHhsk/TBJBrijq2ApIAkeSH
CDU5jIVfzjwd5vVXzlGc44s2vIbMxaok6grbEl5fWvthqlO3kYfgozHS1k43qvFb
hPiAqnZv9E+e/fBqME4u
=uY5I
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message