14 Replies Latest reply on Feb 13, 2010 12:44 AM by cash1981

    Security Check for URL Hacking

      We would like to prevent users from changing the requrest parameters in the URL so that they cannot access other user's data.


      For example, we have a page which shows sensitive customer data and we use a page parameter in the GET request to load the data for the page.  If a customer changes the parameters in the request then they can view other customer's data (i call this URL hacking for lack of a better term).


      If anyone has an elegant solution to this problem we would appreciate any advice you can provide to help us reach a solution.


      Thanks,
      Aaron

        • 1. Re: Security Check for URL Hacking
          superfis

          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

            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
              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

                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

                  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

                    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

                      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

                        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

                          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

                            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

                              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

                                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

                                  I look forward to reading your blog.

                                  • 14. Re: Security Check for URL Hacking
                                    cash1981

                                    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.