tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Donahue <donahu...@gmail.com>
Subject Re: Is there a way for code running on Tomcat 7+ to determine the URL of the Web App it's running under?
Date Tue, 16 Feb 2016 17:20:16 GMT
On Feb 16, 2016 10:50 AM, "Dougherty, Gregory T., M.S." <
Dougherty.Gregory@mayo.edu> wrote:
>
> On 2/16/16, 9:13 AM, "Christopher Schultz" <chris@christopherschultz.net>
> wrote:
>
>
> >Gregory,
> >
> >On 2/15/16 11:18 AM, Dougherty, Gregory T., M.S. wrote:
> >> How to trade information with a specified URL calling java code in
> >> tomcat/lib:
> >>
> >> 1: Servlet calls Decryptor.start (String whoIAm, int validator, int
xOr)
> >
> >What prevents the servlet from specifying whoIAm="someoneElse"?
>
> Absolutely nothing.  That’s why the decrypt code does an HTTP get against
> whoIAm, to validate that claim
>
> >> 2: Code calls Servlet http get with id=randomly generated int
> >
> >Which code calls Servlet HTTP?
>
> HttpURLConnection, called from within the decrypt code
>
>
> >
> >> 3: Servlet returns validator in response to the http get call.  0 is
> >>not a
> >> valid validator, it¹s what the Servlet returns if it doesn¹t have an
> >> outstanding call to Decryptor.start
> >
> >But the whole point is that you don't trust the servlet, right? What is
> >the servlet always returns the same value? Any servlet could impersonate
> >any other one.
>
> I trust each servlet to act in its own best interest.
>
> An honest servlet will 1: Pass in real random numbers for validator and
> xOr, 2: React correctly to this http get call.
> An incompetently written or dishonest servlet can only give away its own
> passwords by doing the wrong thing.

Give them away?  Are you logging the passwords used?

That’s their problem, not mine.
>
> >> 4: Having received the random number from the http get call, Servlet
> >>xors
> >> it with xOr, and calls Decryptor.decrypt (String whoIAm, String
> >>password,
> >> int xOred)
> >
> >So, the servlet makes the HTTP request and manages the checking? I
> >really don't get it.
>
> Servlet (calles Decrypt.start): Sends whoIAm, validator, xOr
> Code (calls http get on whoIAm): Sends cValid
> Servlet (response to HTTP get): Sends validator (same as was send in call
> to Decrypt.start). This validates whoIAm
> Servlet (calls Decrypt.decode): Sends whoIAm, password (encrypted), xOred
> (= xOr ^ cValid)
> Code (return value from Decrypt.decode): password (decrypted)
>
> >
> >> 5: Code checks xOred against whoIAm.  If gets a match decrypts the
> >> password and returns it from Decryptor.decrypt.
> >
> >After all that, it's okay for the servlet to be able to read its own
> >database password? Why not just give the servlet access to a DataSource
> >with the password already set inside it?
>
> Because it’s the Servlet’s password?  How many times do I have to save
> that before you’ll believe it?
>
> The data belongs to the servlet.  The servlet is working with the
> decryption code so that the data can be safely stored with the servlet.
>
> Every servlet trusts itself.  None of them should be required to trust any
> other servlet running on that instance of Tomcat.  None of them should be
> required to trust that data saved in the source control system won’t be
> abused, if it can be abused.
>
> >>But so long as I can make the following two calls from my code:
> >>
> >> URL theURL = new URL (urlString);
> >>  HttpURLConnection   uc = (HttpURLConnection) theURL.openConnection ();
> >>
> >> I think I¹m good.
> >>
> >> Flaws?
> >
> >Let's see:
> >
> >  Constructed dubious use case? CHECK
> Wrong.  This use case is my current work situation.
>
> >  Rolled your own security code? CHECK
> >  Used highly-secure XOR algorithm? CHECK
> >  Complicated enough to seem plausible? CHECK
> >  Confused objective leads to trivial attacks? CHECK
> >
> >I think you've got all the bases covered, here.
> >
> >I still don't understand what's being protected from whom, here. It
> >looks like the code is very complicated in order to keep the password
> >from the code, but then the code is given the password anyway. If you
> >trust the code but not the admin, then why bother with the complex code?
>
> The problem, Chris, is that you don’t understand the situation, and rather
> than try to understand the situation you’re spending all your time and
> effort sniping at things you don’t understand.  Let’s try one more time:
>
>

If you led with the information below in your original post, it would have
helped.

> My servlet is running on a Tomcat instance that is hosting 5 other
Servlets
>
> I completely and totally trust my servlet with my data.  I do not in the
> least bit trust any  other servlet running on that Tomcat instance
>
> I am willing to trust a Jar file that I’ve written / reviewed, and the
> administrators have added to tomcat/lib
>
> I have data that my servlet needs to use.  I am not going to try to go to
> a page on my servlet and personally type in that data every time it runs.
> Therefore I’m going to have to save that data.  I’m not going to save that
> data somewhere on the server hosting the Tomcat instance, because I just
> don’t’ trust the administrators that much.
>
> This means I have to save the data with my web app.  Everything saved with
> my app is available to a pool of people, large enough that I can not trust
> that the data is secure.
>
>
> This is the current situation.  Neither you nor I get to change any of the
> above parameters.  Is anything about the above unclear (other than why
> this is so)?
>
> When I say “I do not trust the Servlet calling the jar code” what I mean
> is that I absolutely trust my own servlet when it’s calling the jar code,
> but I do not trust any of the other servlets (and I’m sure they all feel
> the same way about me).  Any of the other Servlets could pretend they are
> my servlet.

This is why the jar needs to be tied to ldap accounts/roles.  I know it is
not in your ability to do this, but unless you do this or take Mark's
advice about using a security manager, nothing else is going to get you
what you need.

Decryption code that lets them get away with that pretense is
> worse than useless.
>
> Until a user has logged in, you don’t trust them.  After the user has
> logged in, you do.  I need a way from my Servlet to “log in” to the
> decryption code, but I can’t give it a useable password with which to log
> in.  Thus the need to validate that the servlet is the servlet it claims
> to be.

I suppose asking for your own Tomcat instance is out of the question?

>
> Greg

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message