WebApp Sec mailing list archives
Re: On sandboxes, and why I ... don't care.
From: michaelslists () gmail com
Date: Thu, 30 Mar 2006 09:48:38 +1100
Just because no-one has told you, or you haven't seen it doesn't mean it doesn't happen. It's pretty concerning to me, as a java programmer, that the verifier is off by default and hence any jar running can run free or the contraints I've tried to enforce. Or that another j2ee app could possibly be viewing the data I was processing in a shared-hosting environment. I hardly think it's something to disregard because you don't care about it. It's probably not a discussion that belongs on webappsec anyway. And further, if your code _doesn't_ run properly with the verifier, then what the hell are you doing? Something you shouldn't be, that's for sure. If you want to modify private fields legitimately use reflection, otherwise .... -- Michael On 3/30/06, Andrew van der Stock <vanderaj () greebo net> wrote:
Hi there, I must have missed a memo or something. I don't know about you, but I've reviewed many J2EE apps which had far greater things wrong than not running in a verified / trusted environment. I've never seen an attack which is realistic or usable for such attacks. If I find (say) 100 things wrong, the business can afford the time and resources to fix 65 of these and the inclination to fix none. Any fix is a good fix from my point of view, but I need to be careful in what I strongly recommend to be fixed, and what I'll let go through to the keeper. I'm sorry, but I can't recommend turning on the verifier and asking the devs to go through the painful effort of figuring out exactly what perms their code will require when there are actual exploitable issues (those 65 - 80 or so) which may cause actual financial loss. Ditto asking for "final" and other modifiers to be used. Turning on the verifier / forcing the assertion of required privs requires a complete re-test. For many larger apps, testing can cost millions of dollars. How much has been lost with this attack? Ever? Remember, the mitigant to many risks may not be a technical control; it may be reactive (audit), legal (T&C's / contracts), or it may be process driven, such as settlement periods. I'm interested - has *anyone* seen an attack (.NET or J2EE) which aims at the trust model of the underlying VM? Has it lost anyone any money / reputation / shareholder confidence? I'm happy to hear if there has been, but otherwise, I'd like to think we have more important things to educate devland on than worrying about a risk which doesn't really rate. thanks, Andrew
------------------------------------------------------------------------- This List Sponsored by: SpiDynamics ALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl --------------------------------------------------------------------------
Current thread:
- On sandboxes, and why I ... don't care. Andrew van der Stock (Mar 29)
- Re: On sandboxes, and why I ... don't care. michaelslists (Mar 30)