[Owasp-o2-platform] Fwd: Reply to thread 'Security Vulnerabilities with JPetStore and visualization of the AutoBinding Issues'

Dinis dinis at ddplus.net
Fri Jul 15 08:18:29 EDT 2011

Great answer at my post on the Spring Framework forums.

THIS is the type of dialog that we need to establish with developers

Dinis Cruz

Begin forwarded message:

> From: "Spring Community Forums" <webmaster at springsource.org>
> Date: 15 July 2011 10:10:17 GMT+01:00
> To: dinis at ddplus.net
> Subject: Reply to thread 'Security Vulnerabilities with JPetStore  
> and visualization of the AutoBinding Issues'

> Dear Dinis Cruz,
> rvelasco has just replied to a thread you have subscribed to  
> entitled - Security Vulnerabilities with JPetStore and visualization  
> of the AutoBinding Issues - in the Security forum of Spring  
> Community Forums.
> This thread is located at:
> http://forum.springsource.org/showthread.php?111901-Security-Vulnerabilities-with-JPetStore-and-visualization-of-the-AutoBinding-Issues&goto=newpost
> Here is the message that has just been posted:
> ***************
> In my opinion a solution based on "form models" is a valid solution  
> but it is not an effective solution in practice and doesn't follow  
> Spring's philosophy: reduce Java complexity (automating the  
> programmer's job).
> This kind of solutions, hand-coded solutions delegated to  
> developers, reminds me the times when we managed JDBC connections by  
> hand. At that time people knew they had to close JDBC connections  
> but always there were cases where someone forgot to close a  
> connection.
> Thanks to Spring (SpringJDBC for example), we don't manage JDBC  
> connections (getConnection, closeConnection) by hand any more, and  
> today we never have this kind of problems. In this case the  
> architecture (Spring JDBC) implements the rule automatically and at  
> the same time, we reduce the developer's work.
> It's important to note that most web application developers usually  
> don't know about these kind of web vulnerabilities.
> I think we should follow Spring's philosophy in order to solve all  
> web vulnerabilities (not only auto binding vulnerability).
> How can we solve some of the most important web vulnerabilities  
> automatically?
> Many of these vulnerabilities have the same source, users can but  
> they shouldn't:
> - Update a parameter value (for example a parameter included within  
> a link,
> hidden parameter,..)
> - Add a new parameter
> - Request an unexpected url
> - Update a cookie
> -....
> In other words, users should edit only editable data (textbox and  
> textarea data) but they can edit and create all kind of data.
> This reality creates a big problem for the developers because they  
> must validate all request data by hand, programatically.
> At the same time we have another big problem, many developers don't  
> know these web vulnerabilities.
> How can we avoid this problem? How can we validate a web request  
> automatically without developers intervention?
> Using the programming model offered by Spring MVC (or other web  
> frameworks) developers tell us very important information through  
> web frameworks's tags. In other words, custom tags generate all  
> parameters and urls sent to the client.
> If we store this data on the server (for example within HttpSession)  
> and extending web frameworks's tags functionality we can validate a  
> request automatically (some of the most important vulnerabilities).  
> We can validate a request using the data we have stored before.
> We have implemented this idea or pattern in HDIV project. HDIV  
> extends Spring MVC, JSF 1, JSF 2, Struts 2, Struts 1, custom tags  
> functionality in order to implement automatically some of the most  
> important security validations.
> This idea follows Spring's Philosophy and at the same time the most  
> important security pattern: security by default. It's important to  
> note that HDIV doesn't change Spring MVC programming model and it's  
> applied declaratively using Spring's configuration.
> Of course, there are validations like editable data validations  
> (textbox and textare data) that we will have to validate by hand  
> (using whitelists as much as possible) but we can't automatize  
> totally this kind of validations because depends on the application.
> In this kind of validations HDIV offers a generic editable  
> validations module that offers a generic validation system for all  
> editable data (data generated on textbox and textarea components).
> Regards,
> Roberto Velasco
> **************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-o2-platform/attachments/20110715/566fecff/attachment.html 

More information about the Owasp-o2-platform mailing list