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

  • #16
    spring security summary

    I think spring needs to have a separate page in the docs relating these security apects to the user. I am sure once people realise the problems fully they will be surprised spring doesn't address them as spring handles so many other headaches in life.
    Whether the implementation is a combination of spring techniques or improvements along with other solutions - so be it, it just needs to be clear. And I don't see why spring aren't adopting any of these mechanisms which hdiv solves very well with not that many classes, I can only think people aren't adopting hdiv because they don't know about the risks and assume spring handles it.

    summarising the problem
    -----------------------
    We generate a page which includes all the logic necessary for an accepted return. The problem is the client can send anything, so that means checking:

    disabled / hidden fields - that they haven't changed, (or aren't submitted given the session object holds the original value)

    drop downs / radios etc - that the return is part of the values available

    sub-objects - if we are editing a parent object, bind it then verify it, we need to verify sub-objects haven't been tampered with. Also if we use the same page and object with different roles we need to verify objects based on roles, eg Pupil has an address and a set of Score. The pupil is presented with Pupil to correct their name and change their address, but musn't be allowed to change their scores.

    others?

    solution in spring without hdiv
    -------------------------------
    must have acls: for object restriction

    for disabled/drop downs etc:
    restricting values: any returned parameter which isn't a domain id (which is handled by acls) should be checked against the allowed values which were sent to the user in the model. so any drop down lists, radio buttons etc.

    NB: perhaps spring should adopt a binding mechanism based on what is allowed from the session objects (eg mvc 3's modelattribute etc) then parameter fiddling would be solved, acl's wouldn't need to be in place and people who 'assumed' basic security would be safe.

    for sub-objects:
    use allowedFields to prevent them, but if conditional (say on roles) then need dynamic allowedFields.
    NB: from memory, acls, by default, work on top-level domain object (if you are allowed access to a 'Pupil' - it will allow the Score), so you would still need dynamic allowedFields.

    for dynamic allowed fields in webflow:
    "a custom ViewFactory that creates Views with a custom processUserEvent operation" - Keith Donald, for 'allowedFields' to be set based on the role/user

    for dynamic allowed fields in mvc/webflow:
    "use PresentationModel-style DTOs" - Keith Donald - one per role to specify what members can be bound by that role. Alternatively "not defining a public setter for a non-editable field" - but this is not really a practical approach since can potentially complicate hibernate or other bean frameworks.

    NB: perhaps spring should provide a more flexible binding mechanism which allows for role based binding?


    solution with hdiv
    ------------------
    I have still to implement hdiv and test it, but it would cover many of these aspects. Stopping parameter tampering alone means we can avoid acls and restricting values. If it prevents 'extra parameters' which aren't shown on the page then this would also prevent sub-object sub-object security problems. hdiv also covers other owasp security very simply.
    Last edited by adam_jh; Sep 10th, 2010, 08:39 AM. Reason: clarity

    Comment


    • #17
      please vote here to get hdiv more reliably integrated!

      https://jira.springsource.org/browse/SPR-7943

      Comment

      Working...
      X