Announcement Announcement Module
Collapse
No announcement yet.
OWASP TOP 10 - Security Vulnerabilities Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • OWASP TOP 10 - Security Vulnerabilities

    I posted this back in Feb and got no response.

    Has anyone had any experience using the HDIV package within Spring? Are there any plans for Spring security to offer similar functionality in the future? The security checks offered by HDIV is an area of security that is currently missed by all major frameworks but is always in the OWASP TOP 10 of web site vulnerabilities.

    Does this mean the Spring Security team does not think the OWASP TOP 10 and the HDIV principle worthy of a comment or do you feel this is outside the scope of Spring security and should be part of Spring MVC?

    Paul

  • #2
    From my understanding (though I haven't used it myself), the HDIV package is mainly about prevention of XSS and CSRF. Hence the focus is on validation of input/output and the use of random synchronizer tokens to prevent out of sequence requests.

    Spring Security is mainly about authentication and authorization and is pretty much agnostic where view technologies are concerned. So I'd say HDIV is a complementary tool rather than something we should be seeking to build into Spring Security.
    Last edited by Luke Taylor; Jun 11th, 2008, 12:37 PM. Reason: typo

    Comment


    • #3
      About HDIV:

      HDIV (Http Data Integrity Validator) is not mainly about prevention of XSS and CSRF. These functionalities are the less important part of HDIV
      because they are part of editable data generic validations HDIV's module.

      The main advantage of HDIV is related with non editable data integrity validation (all excepting textbox and textarea data). This vulnerability
      is related specialy with the A4 vulnerability within OWASP top ten.

      This vulnerability (A4) is very difficult to solve because it needs data integrity validation and not a type validation (is an integer,...).
      In other words, if you have a link or a hidden field within a form , for example mybank.com?idAccount=50,
      how do you validate that the client hasn't tampered this value before sending it to the server?

      Web frameworks such as Struts 1, Struts 2 and Spring MVC don't offer any solution for this problem and here is where HDIV provides a very important
      security functionality.

      Of course, you can solve this vulnerability in some cases using an instance level security solution like Spring security
      (I don't know any other transparent solution for that).

      But if you have to develop a web application with a legacy database (where there isn't any registry level right access data) or your database
      has many registries (the usual case), it is very difficult to apply Spring security instance level solutions.

      We usually use Spring security for Authentication and Authorization (url and method level) and HDIV for web application vulnerabilities (OWASP to ten) and
      instance level security.

      As you say, I think Spring Security and HDIV are complementary solutions and in my opinion HDIV should be part of Spring MVC and not Spring security
      (Currently there is an open process to integrate HDIV with Struts:wiki.apache.org/struts/HDIV).

      Anyway people usually see Spring security as a good security reference and I think it's a good idea if you add a reference in the
      Spring security documentation about OWASP to ten vulnerabilities and their possible solutions.

      Roberto Velasco (HDIV team)

      Comment


      • #4
        Thanks very much for the information (and clarification).

        You're probably right that we should add a some extra pointers in the reference manual and website to general information on web application security (such as the OWASP) site. That way people are more likely to be made aware of these issues, even though they aren't necessarily covered by Spring Security itself.

        Comment


        • #5
          Addressing all top-10 OWASP vulnerabilities

          OWASP provides ESAPI, which is a security framework, that claims to address all top-10 OWASP vulnerabilities. I've never used ESAPI myself, so I cannot testify on its maturity or quality, but it seems to me that the Spring Security framework may benefit from integrating with ESAPI to add to its offering.

          I'd be happy if someone from the Spring Security developers could comment on whether there is any intention to address all top-10 OWASP vulnerabilities in Spring Security (either via integrating with ESAPI or writing your own).

          Thanks,
          Naaman

          Comment


          • #6
            I would be pleased if someone could clarify "I'd be happy if someone from the Spring Security developers could comment on whether there is any intention to address all top-10 OWASP vulnerabilities in Spring Security (either via integrating with ESAPI or writing your own)."

            Comment


            • #7
              And again, in 2010, is this issue deemed not important to be integrated?

              With spring security I offer a page which has different input fields and shows different info depending on the authority. However, that security is MEANINGLESS when a request comes in since parameter binding needs to be restricted depending on the authority. I went to look at creating a custom binder, but realise that the HDIV filter tracks changeable inputs and only allows them to change - an idiot-proof (ie I'm not required to be relied upon) and uncomplicated solution.

              I think its unlikely that everybody using spring security has forseen this scenario - and given how simple this solution can be, it is very surprising it is not in spring already.

              Especially with the default mvc towards webflow, the fix seems to be buried even further. To create a custom binder requires re-inserting the now defunct FormAction to specify a binder or somehow utilising the useSpringBeanBinding. Keith himself says to use the validators (https://jira.springsource.org/browse/SWF-539) but this doesn't suffice.

              Attending a spring exchange once in London a year or so ago and this specific question was asked, and it was not met with enthusiasm - which surprises me no end.

              Comment


              • #8
                That person asking the question at the spring exchange was me and like you say not a good response. 18 months on and still no full security solution is provided by the Spring portfolio.

                Springsource and security = fail

                Paul

                Comment


                • #9
                  In Web Flow 2, simply declare bindings explicitly using your view-state's <binder> element. Only what is declared can be bound. That's pretty simple to do, and is documented in the reference manual since 2008. That's for fixed binding rules. Now, allowing the set of bindings to vary dynamically based on security context is not supported out of the box, but a request for this feature hasn't been raised before AFAIK, either. In any case, it's doable by providing a custom ViewFactory that creates Views with a custom processUserEvent operation.

                  With Spring MVC, simply restrict bindings using DataBinder.setAllowedFields in a @Controller @InitBinder callback. Alternatively, use PresentationModel-style DTOs instead of binding to internal, and more complex domain objects directly. Finally, it's also possible to restrict binding to a domain object simply by not defining a public setter for a non-editable field.

                  Security is obviously an important topic. What I and the rest of the community would find most beneficial would be requests for and discussions about concrete improvements in this area.

                  Keith
                  Last edited by Keith Donald; Jan 22nd, 2010, 10:41 AM.

                  Comment


                  • #10
                    Thanks for your input Keith!

                    Yes - the <binder> has been there for a while. As an aside, I would probably use another approach anyway as I understand the reverse, setDisallowedFields, was not adopted in webflow, but in most of my apps I only care about the id and a usersId not changing - the rest of the command object I don't care about.

                    In the case of dynamic allowed bindings in my current app....Thanks for the entry points - though I still consider a filter the only do-able approach.

                    - Defining the allowed fields based on the authority would be cumbersome.
                    - A different 'model' in webflow or 'command' in mvc depending on the authority still seems a more complicated appraoch than an automatic filter.
                    - This approach does not help if a hidden value is used but shouldn't be changed [granted this wasn't the initial request, but its owasp related]. Off the top of my head, this would be a good approach in reconnecting after a session-timeouts since all info could be carried on the client not server.

                    +1 for a filter
                    -------------
                    The hdiv filter looks at the output and so understand which fields are editable and which aren't (eg hidden), so whatever you show in the view as editable to the authority will be editable and nothing else. In fact the nothing else can't be tampered with because hdiv understands those non-editable values and compares them on return to check nothing has changed. Through a filter approach, it also offers the ability to obscure the other info so you don't see db identifiers etc.

                    Perhaps others can comment. I'm putting hdiv in at the moment but its not straight forward, eg not latest jars in maven, jars go to webflow 2.0.4 and it depends on webflow 1.5 - so is it compatible with 2.0.8??

                    Spring handles so many concerns that people don't understand well. This is one [OWASP] that has lagged too far behind.

                    Cheers
                    Last edited by adam_jh; Jan 22nd, 2010, 01:18 PM.

                    Comment


                    • #11
                      p.s. I get your point that dynamically allowed fields hasn't been a jira. I'm not saying that spring should have thought of (though that would have been nice) but this would have been solved if spring already provided a security filter like HDIV. Obviously this thread is about the whole OWASP - I just hijacked it with another example of why we need it - of which dynamically allowed fields are perhaps the least obvious reason, but still important if spring offers a security solution that allows the approach I have implemented.

                      Comment


                      • #12
                        Keith,

                        I have raised the issue of OWASP Top 10 a few times now, the features that would be needed in Spring Security/Spring MVC/Spring Webflow are not that hard to work out. The Spring team, just needs take the OWASP Top 10 and see the missing gaps and then fill those gaps. You only have to look at the frameworks out there already such as HDIV, ESAPI and JSecurity to see what has been done before.

                        The key requirement here is the security controls should be as light touch as possible in terms of what each and every developer has to do. It should be layered on top of an application very much how some of Spring security works today. If you have to rely on developers to set binding and all that sort of stuff holes will appear.

                        Happy to dig deeper and discuss when the you Springsource guys have given it some time and thought to come up with a straw man of what needs doing and the options available.
                        Paul

                        Comment


                        • #13
                          adam_jh,

                          what was the outcome of your implementation of Web Flow with HDIV?

                          Comment


                          • #14
                            Originally posted by rvelasco View Post
                            About HDIV:
                            In other words, if you have a link or a hidden field within a form , for example mybank.com?idAccount=50, how do you validate that the client hasn't tampered this value before sending it to the server?
                            Simple, you don't trust the client, and implement RBAC on the server. If the authenticated subject submitting the request has a role/permission entitling him to modify the account which the request identifies, then it does not matter if he forged the HTML to submit the request or pulled a different account from a dropdown -- the determination of canModify(User U, Account A) is totally dependent on the roles that user U has (and totally domain model specific).

                            Web frameworks such as Struts 1, Struts 2 and Spring MVC don't offer any solution for this problem and here is where HDIV provides a very important security functionality.
                            That is because such 'solutions' are application specific and not explicitly something a framework can address.

                            But if you have to develop a web application with a legacy database (where there isn't any registry level right access data) or your database has many registries (the usual case), it is very difficult to apply Spring security instance level solutions.
                            Sounds like you want to put authorization checks into your service, not into your web framework.
                            Last edited by honeybunny; Apr 27th, 2010, 06:46 PM.

                            Comment


                            • #15
                              Am revisiting this thread as I'm revisiting hdiv...

                              jglen - After my initial research I'm only just revisiting hdiv integration. I was working on upgrading hdiv to a more recent version (spring mvc 3 and webflow 2) but I emailed the hdiv team and they said they'd got an alpha release so they are releasing it this or next week. I will post back if there are any problems.

                              honeybunny - pure role based access doesn't solve which account you can access - you'd need acl's for that, which you mention. acl's add a level of complexity not many people want. Also, do acl's by default handle child filtering? Further, that doesn't stop parameters within an object being within allowed values. Sure this can be checked again on the server, but there then becomes a very significant number of checks. I see what you are saying that the place for validation is on the server and helps if code goes out over other mechanisms such as atom, but there is a lot of work for this cost (see next post).
                              Last edited by adam_jh; Sep 10th, 2010, 06:08 AM.

                              Comment

                              Working...
                              X