1 / 20

Saving the World from Bad Beans

Saving the World from Bad Beans. Dave Clarke, Utrecht Michael Richmond, IBM ARC James Noble, VUW. Enterprise Java Beans. Component architecture for large-scale server-side computing Individual third-party components - Beans Large, complex environment - Server

lanza
Télécharger la présentation

Saving the World from Bad Beans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Saving the World from Bad Beans Dave Clarke, Utrecht Michael Richmond, IBM ARC James Noble, VUW

  2. Enterprise Java Beans • Component architecture for large-scale server-side computing • Individual third-party components - Beans • Large, complex environment - Server • Server integrity depends upon beans being well-behaved, obeying coding guidelines • What about Bad Beans?

  3. EJB Lifecycle

  4. EJB Structure and Containment

  5. EJB Structure • EJB Object (EJB) • Provides business functionality • EJB Interface (EJBObject) • Mediates access to EJB • Container • Offers server functions to Beans • Helper — aggregate subsidiary object • Transfer — moves data between EJBs

  6. EJB Interobject References

  7. EJB Interface and Container • EJB Interface and Container • Collaborate to provide services to beans • Security • Transactions • Persistence • EJB Architectural Assumption • All access to EJB Object is via EJB Interface • EJB Object contained within EJB Interface • Confinement breach breaks architecture

  8. Bad Bean Breaches Confinement

  9. Bad Bean Breaches Confinement public class CartBean implements SessionBean { protected SessionContext context; // Called once by container during Bean creation public void setSessionContext(SessionContext _ctx) { this.context = ctx; }

  10. Bad Bean Breaches Confinement // correct way to return reference to Bean public CartEJBI goodReturn() { return(context.getEJBObject()); } // incorrect way to return reference to Bean public CartEJBI badReturn() { return(this); }

  11. Bad Bean Breaches Confinement • Naïve class verification is not enough! class BadBean implements SessionBean { public Object exposeMyself() { return (Object) this; } Mole OopsIDidItAgain() { return new Mole(this); }

  12. Confinement Checking Confinement Checkers Prevent Exposure • Unit of confinement: Bean Instance • Inside: EJB Object, Helpers • Boundary: EJB Interface • Outside: everything else • Transfer objects may cross the boundary • Subject to restrictions • Server checks confinement during deployment

  13. Confined Bean Constraints • CB1 Classes implementing EnterpriseBean, and all Helper classes, are confined. Classes extending boundary interfaces are on the boundary. • CB2 No confined type can appear in the signature of a boundary method, nor in static fields, nor as an exception. • CB3 A confined type cannot be cast to a non-confined type. • CB4 A non-confined type cannot be cast to a confined type.

  14. Confined Bean Constraints • CB5 Fields, methods, and statics of non-confined classes having confined type are not accessible in confined code. Exceptions cannot be caught at confined types. • CB6 A confined class may only extend anotherconfined class or java.lang.Object • Reflects guidelines in EJB specification • Reflection and native methods ignored

  15. Checking Tool • We built a tool based on SOOT • Checks Bean class files at deployment time [dc] Processing class: mar.basicfail.SampleEJBI [dc] Class is on boundary - proceeding with boundary checks [dc] Boundary class has confined in interface (CB2). [dc] Offending Method (in return type): returnAsSessionBean [dc] Boundary class has confined in interface (CB2). [dc] Offending Method (in return type): returnAsSampleEJB [dc] Return statement violates CB3/4 [dc] Value type = mar.basicfail.SampleEJB [dc] Return type = java.lang.Object [dc] Offending statement: return r0 [dc] [dc] Deployment failed!!!

  16. Testing Existing Beans But can you use this on real Beans? • We tested this on a range of sample Beans • Case study: 15 Beans • All beans passed except one (see the paper) But is this fast enough for production servers? • 1.3-6.5s per bean • Bean deployment is 10 times as expensive! • Our prototype implement does not shareeffort with the server

  17. Evaluation • Simple for developers and EJB architecture • No change to development environment • No change to EJB architecture • No runtime costs • Asymmetric — only checks confined code • Parametric Polymorphism (e.g. Collections) • But need bytecode support (e.g. .Net) • More sophisticated analyses • Harder for developers to understand • Bean correctness should not depend upon strength of analysis

  18. Confinement and Ownership Boyapati et al

  19. Conclusion • EJBs are susceptible to confinement errors • Direct references bypass the EJBInterface • Confinement checking prevents these errors • Check server side, at deployment time • Fast and efficient checker • Empirical testing • Existing well-written EJBs will pass the test • Pragmatic customisation via Transfer objects

  20. Credits • Department of Computer Science, Purdue • DARPA F33615-01-C-1894 • Royal Society of New Zealand Marsden Fund • Ward 16 Wellington Hospital

More Related