[Owasp-topten] Missing Top 10 Issue

Dave Wichers dave.wichers at owasp.org
Mon Dec 7 22:59:56 EST 2009


Sorry for the very long delay in responding.

 

I know this can be a big problem for some apps, but it's pretty subtle.

 

I think this item would probably fall into one of the top 10 categories, or
possibly several depending on the exact nature of the flaw. 

 

Do you think this could be wedged into one of the top 10 as an example, and
then expounded upon in more detail in an OWASP article on the subject that
the top 10 could point to? If so, would you be interested in writing that
article :-)

 

Otherwise, if it doesn't fit, then I don't think it makes the top 10 itself,
but we could list it in a new section on up and coming security issues and
at least mention it there, and provide some references to papers like Dinis'
or the article (that you are going to write J), at OWASP.

 

What do you think?

 

-Dave

 

From: Honest Abe [mailto:honest.expert at gmail.com] 
Sent: Sunday, November 22, 2009 4:35 PM
To: OWASP-TopTen at lists.owasp.org; dave.wichers at owasp.org
Subject: Missing Top 10 Issue

 

I am a security code reviewer in large financial institution.

 

There is one thing I see as a trend which is not reflected in the OWASP Top
10.  

 

Parameter Tampering.  When I say parameter tampering I am not just
mentioning the normal parameter tampering.  

 

As developers have been adopting Open Source Web Frameworks (Struts 1.x and
2.x, SpringMVC, JSF, etc.) they inherit the programming paradigms of these
framework.  The problem is that developers do not understand the security
implications of following the patterns of these frameworks.

 

One example is the parameter tampering caused by the dynamic binding
mechanism of request parameters to Command, ActionForm, Action, or other
request processing  objects.  Dinis Cruz and Ryan Berg discuss this in their
excellent paper:

 

http://www.ouncelabs.com/writable/resources/file/ounce_springframework_vulne
rabilities.pdf

 

The problem that developers are doing is placing sensitive objects
(ApplicationContext, list of Accounts, etc.) directly in these request
processing objects.  These objects can be tampered with either through
insider information or looking at the source of the generated html pages.

 

The problem is further compounded by the fact that many frameworks which
facilitate development with these open source frameworks advocate a merging
of the persistent model objects and the request processing objects.

 

See Appfuse (which is a great productivity enhancer asides from the security
vulnerability it introduces):

 

The Person object persistent entity created here:

 

http://appfuse.org/display/APF/Persistence

 

Has its attributes set by request parameters here:

 

http://appfuse.org/display/APF/Using+Spring+MVC

 

This ultimately compounds the issue because any persistent entity attribute
can now be modified through request parameters.  These persistent entities
are passed to a DAO (Data Access Layer) and have their attributes and any
sub object attributes persisted to the database.

 

Most applications follow this pattern to get away from duplicating DTOs
(DataTransfer Objects). 

 

This is a problem that most developers are unaware of.  Some are under the
mistaken belief that the dynamic binding only works with Strings and
primitive types but this is not true.

 

For example, an attacker can attack List and Array attribute types (in this
case accounts is a List or Array) of a command object by creating a request
parameter like the following:

 

commandObj.accounts[0].accountNumber=#attacker's Desired Account Number#

 

<input type="hidden" name="commandObj.accounts[0].accountNumber"
value="#newValue#">

 

Regards,

Honest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-topten/attachments/20091207/ef1285ed/attachment.html 


More information about the Owasp-topten mailing list