On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz < ch...@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 <ma...@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. But of course - how good is the decryption key protected - what about the in-memory copy of the credentials once the datasource has been initialized - what about snooping them on the network when the DB connection is built. OK. We are using SSL there. 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... Thanks Martin -- ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
