-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 2/12/16 3:10 PM, André Warnier (tomcat) wrote: > On 12.02.2016 20:49, Dougherty, Gregory T., M.S. wrote: >> You can honestly tell who¹s calling you, since you can throw an >> exception, catch it, then look at the stack trace. >> >> If you have an object, you can get its class, you can get what >> methods it implements, and you can get its parent class and >> recurse. >> >> So that should let you figure out which class will be >> implementing the emthod you¹re calling, unless I¹m totally >> confused. >> > > I can be confused easily too, in matters Java. Just don't start talking about Perl. It's just as confusing from the other side of the fence. ;) > But let's just speculate, and someone undoubtedly would correct me > if I'm wrong. Since 1) you do not necessarily trust the code which > is (directly) calling you. But you would trust it if you were sure > that it is the original Tomcat code. 2) if I remember correctly, a > HttpServletRequest object is immutable, so nobody can have modified > the original data of the request, as it came in and was parsed by > Tomcat. It's true, the HttpServletRequest doesn't have any mutators, but that doesn't mean that the class implementing the interface must be immutable. Neither the interface itself nor the javadoc make any such assertions. > 3) What they could do however, is wrap the original object into > another, and override the methods so that they would return other > data than the original when you call getRequestURL There is no difference as far as this hypothetical library is concerned between cases #2 and #3 above: the code can only call methods defined in the interface. The fact that the runtime method returns something potentially suspicious is undetectable, and the mechanism by which it does that doesn't matter. > 4) but you can climb up the object hierarchy, until you find the > original (Tomcat) HttpServletRequest object and its methods No. You can't unwrap the HttpServletRequest object to find out what its "parent" (or wrapped) request is (unless you happen to have a known runtime type which supports a method like getWrapper()). The wrapper is an object which encapsulates the original request, it doesn't "extend" it in the sense that you can call Class.getSuperclass() . Even if you *were* able to navigate up some magic class hierarchy (which doesn't exist for class-composition of this type... but IF YOU COULD!), if you tried to call something like EvilRequestWrapper.super.super.super.getRequestURL() you'd find that Java just calls EvilRequestWrapper.getRequestURL anyway -- because that's how virtual method dispatch works in object-oriented systems. Without hacking the JVM, there's no way to call EvilRequestWrapper.super.super.getRequestURL(). > yes ? > > Then I would imagine that there must be a way for you to retrieve > the data as provided by the original HttpServletRequest > getRequestURL, no ? Nope. And any way I can think of for Tomcat to stash it somewhere "safe" can also be compromised by the webapp's code (previously determined to be untrustworthy, and potentially hostile... or at least underhanded). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAla+Y1oACgkQ9CaO5/Lv0PB19wCeJ3HJ5mJx7Ywv4HZap/P6HT6T GGkAn0sA0jW08UTPkMOmRI0Bn4X0ARee =XY5u -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
