-
1. Re: Security Check for URL Hacking
superfis Feb 10, 2010 8:09 AM (in response to arkmobile)Hi Aaron,
I think that standard Seam Authorization should meet your needs or I'm not understanding your problem enough.
During authorization you can check if logged-in user has permissions to see the data related to page_parameter. Authorization implementation in Seam easily can be adopted to do what you want to do.Slawek
-
2. Re: Security Check for URL Hacking
babazs Feb 10, 2010 10:32 AM (in response to arkmobile)You can define security rules/roles based on the appropriate objects, then you should use restrictions with pages.xml.
<restrict>#{s:hasPermission(object,'viewCurrentPage')}</restrict>
-
3. Re: Security Check for URL Hacking
arkmobile Feb 10, 2010 6:24 PM (in response to arkmobile)Guys, thanks for the quick feedback. I think i may need to clarify my issue further. The user has permission to view the UserProfile.xhtml page but only when the data on the page is associated with the user. There is a request parameter in the page url http://www.company.com/UserProfile.seam?userId=10 which determins what data is loaded into the UserProfile.xhtml page. I want to block the user if they manipulate the URL by changing the userId parameter. -
4. Re: Security Check for URL Hacking
nimo22 Feb 10, 2010 7:24 PM (in response to arkmobile)you can use a rewrite filter with an regex-expression.
however, this only hides the actual url.A secure solution would be: not put request-param in the url and do a post-submit.
-
5. Re: Security Check for URL Hacking
arkmobile Feb 10, 2010 7:28 PM (in response to arkmobile)I'll give the post submit a shot, i was probably making it more complicated than necessary by trying to build some type of custom record level authorization.
-
6. Re: Security Check for URL Hacking
niox.nikospara.yahoo.com Feb 10, 2010 7:56 PM (in response to arkmobile)Hello,
Relying on request parameters, even POST ones, is inherently insecure. It is trivial for any user to tamper with the request.
So all incoming data must be validated. JSF provides the validators for this reason, Seam can even validate request/GET parameters (see pages/page/param/@validator in pages-X.X.xsd). If you really need to put the user id for the customer data page in a request parameter, you may also install a validator that checks that this id is the same as the one taken from Seam's authentication mechanism.
However, the most appropriate solution (IMHO) would be to put the bean containing the sensitive data of the current user in session or narrower scope, and use that from the details page. You can @Name the bean, use a factory or a page action to outject it.
Nikos
-
7. Re: Security Check for URL Hacking
jeanluc Feb 10, 2010 9:06 PM (in response to arkmobile)
A secure solution would be: not put request-param in the url and do a post-submit.Not at all - I'd like to second the comment Nikos made. Considering POST secure is utterly wrong. I'd suggest you read the OWASP guides to get yourself familiarized more with web/application security.
In your case, since you have the identity of the user in your session, it's easy to add a filter in the db queries that retrieve the data. Not only will that really get only the data the user should see, but you also prevent the loading of records for the other N-1 users, so there's less load on the db.
-
8. Re: Security Check for URL Hacking
arkmobile Feb 10, 2010 11:22 PM (in response to arkmobile)Thanks for the feeback. I am using EntityHome to load the user profile (UserHome). When the user has the role of admin, manager, or agent they are allowed to view other user's profiles so I came up with the following solution to enforce record level security based on roles. I would be interested in knowing if you guys think this is an approperiate way to handle my situation.
@Override protected void initInstance() { if(identity.hasRole("admin") || identity.hasRole("manager") || identity.hasRole("agent")){ super.initInstance(); } else { setId(currentUserId); super.initInstance(); } }
-
9. Re: Security Check for URL Hacking
niox.nikospara.yahoo.com Feb 11, 2010 9:54 AM (in response to arkmobile)It looks most probably OK.
There might be more elegant ways of implementing it, though. Perhaps by not hardcoding the role names or implementing security logic AOP-style. But that is personal opinion and entirely optional.
-
10. Re: Security Check for URL Hacking
arkmobile Feb 11, 2010 9:50 PM (in response to arkmobile)Nikos,
I'm open to suggestions if you wouldn't mind suggested some pseudo code that accomplishes the APO-style you speak of.
Aaron
-
11. Re: Security Check for URL Hacking
niox.nikospara.yahoo.com Feb 11, 2010 10:29 PM (in response to arkmobile)Aaron,
The simplest case of AOP is the standard EJB interceptor (take a look at the seam-gen'ed ejb-jar.xml for an example). Then there is jboss-aop and AspectJ. I haven't really used any of them more than a few examples with jboss-aop but I do know they are far more capable and complex than EJB interceptors. Seam offers its own specific ways of dealing specifically with security.
The advantage of AOP-like methods is that you can gather cross-cutting concerns, like security, in one place.
Please note however that if this is the only security-related code, using the above methods is an overkill.
-
12. Re: Security Check for URL Hacking
cash1981 Feb 12, 2010 4:31 PM (in response to arkmobile)As Nikos is saying you can use an interceptor to do this for you. It is quite easy and very handy.
I am planning on blogging about this very very soon. (Will start work today). So check out my blog and you should be able to copy and use that code.
I can't promise anything, but hopefully I will have part 1 (interceptors) of my seam advance series in place -
13. Re: Security Check for URL Hacking
arkmobile Feb 12, 2010 9:12 PM (in response to arkmobile)I look forward to reading your blog.
-
14. Re: Security Check for URL Hacking
cash1981 Feb 13, 2010 12:44 AM (in response to arkmobile)Done! I hope it wasn't too much code and too little explanation. If anything is unclear, don't hesitate to leave a comment and ask.