OWASP TOP 10 - Security Vulnerabilities

[adam_jh]

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.

[paulg]

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

[jglen]

adam_jh,

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

[honeybunny]

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.

[adam_jh]

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

[adam_jh]

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.

[adam_jh]

please vote here to get hdiv more reliably integrated!

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