OWASP TOP 10 - Security Vulnerabilities

[paulg]

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

[Luke Taylor]

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.

[rvelasco]

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)

[Luke Taylor]

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.

[nlif]

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

[stlecho]

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

[adam_jh]

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.

[paulg]

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

[Keith Donald]

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

[adam_jh]

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