[15020] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Another hole in Cart32

daemon@ATHENA.MIT.EDU (Clover Andrew)
Wed May 24 15:13:15 2000

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id:  <5F78AA062F6AD311A59000508B4AAF6D092B37@pcs02>
Date:         Tue, 23 May 2000 20:30:55 +0200
Reply-To: Clover Andrew <aclover@1VALUE.COM>
From: Clover Andrew <aclover@1VALUE.COM>
X-To:         BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM

sert sert <sert_is@HOTMAIL.COM> wrote:

> They seem to be relying on the client to properly use the security
> options available in the package.

The options they outline *do not* represent any level of security,
"properly" used or not. Anyone can get around the POST restriction
by simply creating a form themselves, and anyone can get around
the Referer check by connecting to the HTTP server either by hand
or using a non-web-browser tool and sending the Referer header
themselves.

Worse, the Referer check will break functionality on any browser
that does not support, or has been configured not to give (for
privacy reasons) referring page information.

A security policy that relies on trusting the user agent is no
security policy at all. With a shopping cart made entirely from
client-side JavaScript, such exploits are understandable. When
it's a server-side set of scripts, relying on trust is
inexcusable.

Michael Form <mike@SECTOR001.ORG> suggested:

> all Cart32 users should skim through the orders to see any
> noticeable price errors.

Indeed.

High-tech! E-commerce!! Let's go!!!

--
Andrew Clover
Technical Support
1VALUE.com AG

home help back first fref pref prev next nref lref last post