7 Replies Latest reply on Sep 19, 2006 9:56 AM by bfagan

    Glaring Security Hole?

    bfagan

      Please correct me if I'm mistaken, but my impression from the Seam Reference document is that if you enable Seam Remoting then any Entity bean that you've given a Seam @Name has it's data model exposed.

      Let's say you have a large corporation and a developer uses a wonderful IDE wizard to turn their database model into a package of easy to use Seam-enabled entities. Next the developer enables Seam Remoting to use an @WebRemote enabled session bean.

      Any competitor to said large corporation can search javascript segments for Seam.Component.newInstance() methods, call out to the Seam Remoting URL garner information about the entities and reverse engineer a data model.

      It is clear that session beans require @WebRemote annotation. Why are entity beans automatically exposed without such an annotation?

        • 1. Re: Glaring Security Hole?
          shane.bryzak

          Entity beans (and in fact, any JavaBean objects that are returned or referenced in the return value by a session bean method) are represented by an equivalent Javascript "class" to provide the developer with a familiar object model to work with. Until now, no-one has expressed any issues with exposing the model (I guess it depends on the nature of the project), although I suppose that it wouldn't be difficult to annotate certain entities with @Restricted or something like this which would prevent it from ever being used in remoting. If you'd like such a feature, please raise a JIRA request.

          • 2. Re: Glaring Security Hole?
            gavin.king

             

            "bfagan" wrote:
            Please correct me if I'm mistaken, but my impression from the Seam Reference document is that if you enable Seam Remoting then any Entity bean that you've given a Seam @Name has it's data model exposed.

            Let's say you have a large corporation and a developer uses a wonderful IDE wizard to turn their database model into a package of easy to use Seam-enabled entities. Next the developer enables Seam Remoting to use an @WebRemote enabled session bean.

            Any competitor to said large corporation can search javascript segments for Seam.Component.newInstance() methods, call out to the Seam Remoting URL garner information about the entities and reverse engineer a data model.

            It is clear that session beans require @WebRemote annotation. Why are entity beans automatically exposed without such an annotation?


            They are only exposed if they are the return value of a method marked @Remote. And only their state is exposed, not their methods.

            • 3. Re: Glaring Security Hole?
              bfagan

              Is the documentation completely wrong then?

              In section 7.2.2 Seam.Component, the example shows an entity bean that implements serializable with @Name('customer') which is later called through:

              var customer = Seam.Component.newInstance("customer");

              customer.setFirstName("John");
              // Or you can set the fields directly
              customer.lastName = "Smith";

              • 4. Re: Glaring Security Hole?
                gavin.king

                That code instantiates a *new* object with empty values. Hence no security hole.

                • 5. Re: Glaring Security Hole?
                  bfagan

                  I'm not stating that the data is insecure, but that the model is.

                  A company's data model can constitute proprietary information or trade secret.

                  What I'm blatantly saying is that as much as sessions beans require @WebRemote to have their methods exposed under Seam Remoting, entity beans in the same distribution should be afforded the same level of preventative measure.

                  Instantiating a *new* object tells me plenty about how the database is modeled and in some cases can reveal proprietary information or trade secret.

                  A developer may wish to prevent various entity beans from having their model exposed. I'll go a step further and say that entity beans should not have their model exposed by default, but that they should be configured with @WebRemote as well. It fosters uniformity and errs on the side of security.

                  • 6. Re: Glaring Security Hole?
                    shane.bryzak

                    I wouldn't go as far as to constrain all entities by default, it would add another "speedbump" that a developer would need to be aware of when implementing remoting in their app. Section 7.9 in the remoting chapter of the documentation describes how object graphs returned by invoking a session bean can be constrained to exclude sensitive or unnecessary objects. I've got no problem implementing a similar exclusion for entity classes. Maybe @NonRemotable, or even @NoWebRemote would be a good annotation for this use case.

                    • 7. Re: Glaring Security Hole?
                      bfagan

                      I don't think it's any more of a hassle than creating a @Remote or @WebSerivce interface. In fact we're talking about just one tag, @WebRemote, in a class.

                      It would also be easier for developers who are new to Seam Remoting to follow if it is consistent. "I have to use @WebRemote on sessions, but @NoWebRemote on entities? Why'd that do that?"

                      If you're worried about existing developers or eliminating the speed-bump, you can always create a property in a config file somewhere that would enable/disable entity model remoting restrictions.

                      From a security standpoint, I think it's much better to err on the side of security, i.e. you have to specifically enable which entity models you want exposed.