Re: View and edit hidden HTML form fields (fwd)

["George W. Capehart" <gwc () capehassoc com>]

On Thursday 12 June 2003 03:02 pm, sirkus wrote:
> On Thu, 2003-06-12 at 12:22, Tim Greer wrote:

<snip>

> > I actually don't see how this reveals any weaknesses. Just seeing
> > the fields or arguments/values passed to a script/program doesn't
> > really mean anything. It can save a lame 'web site form based'
> > cracker some effort, but that's about it.

<snip>

> full explanation... Yes, tools like this can be used to test for
> client-side state weaknesses. (Or what ever you would like to call
> it.)  By modifying simple form field inputs, whether they are hidden
> or not-so-hidden, this can reveal logic weaknesses used by web-app
> developers to handle client-side-state information.  That's what
> parameter manipulation is about. If some ignorant webapp developer is
> still using hidden fields to store discount codes, shopping cart
> prices, or other sensitive state information, simple tools like this
> is all you would need to discover and exploit this type of
> "weakness". (And yes, this is still quite prevalent, even in many
> "secure" applications.) Beyond this, "Just seeing the fields or
> arguments/values passed to a program" DOES mean something.  This is
> the fundamental basis for black-box learning of how an application is
> built, and possibly how to assess it for security.

Indeed.  A real-world example follows:

Context:  an on-line banking application which allows the user to do 
account balance inquiry and transfer funds between accounts.  The 
application was poorly designed and naively trusted data from the 
browser.  When the user logged in, the application looked up all of the 
accounts to which the user had legitimate access and sent the account 
numbers out to the browser.  The user could then choose which account 
he/she wanted to access.  In the case of transferring funds, the user 
selected the "from" and "to" accounts.  Problem was, upon receipt of 
the form, the application did not validate that the accounts were owned 
by the user.  This meant that if the user could directly manipulate the 
contents of the POST, he/she could inquire about *anyone's* balance, 
and transfer funds from *anyone's* account to *anyone else's* account.  
This was tested and exploited using a tool such as is being discussed 
here during the Information Security audit before the application was 
actually put into production.

</gwc>
-- 
George W. Capehart

"With sufficient thrust, pigs fly just fine . . ."
 -- RFC 1925