[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3972579#3972579 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3972579 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3972331#3972331 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3972331 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3972452#3972452 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3972452 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
That code instantiates a *new* object with empty values. Hence no security hole. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3972152#3972152 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3972152 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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;
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3971913#3971913
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3971913
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3971497#3971497 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3971497 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Glaring Security Hole?
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. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3971438#3971438 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3971438 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
