> I think the solution is very easy.
> Don't post from the browser to Verisign, but to the server that will
> forward
> the request to Verisign and then back to the browser. In that way the
> server
> controls everything and the client is unable to change the outcome.
Agreed, but that's not how PayFlow Link works. Verisign has another product,
called PayFlow Pro, which I believe does do this. So instead of fixing it,
such as with a "shared secret" solution mentioned previously, they plan to just
encourage people to upgrade to the Pro version.
> -----Original Message-----
> From: Megan McRee [mailto:meganmc_at_mail.ru]
> Sent: vrijdag 4 januari 2002 1:12
> To: vuln-dev_at_securityfocus.com
> Subject: Re: Vuln in Verisign PayFlow Link payment service
>
>
> I hate to see this post. From a developer's perspective, this is one of the
> easiest and most flexible card processing systems to integrate with my
> software that I have
> found.
>
> Perhaps a fix for VeriSign would be to passback a secret code (configurable
> through the PayFlow Link admin panel) that does not originate from a cart
> input value, but is stored and sent from PayFlow. Then a simple 'if'
> statement in the cart software could weed out the bad along with an e-mail
> sent to the admin. That would surely slow someone down if they have to
> guess
> the secret code's input value.
>
> I would hate to see them change the way the current system of passing back
> values works. Does anyone know of any other card processing services that
> pass back variables to software/scripts in the same manner?
>
>
>
> ----- Original Message -----
> From: Keith Royster <keith_at_theroysters.com>
> To: <vuln-dev_at_securityfocus.com>
> Sent: Thursday, January 03, 2002 5:39 PM
> Subject: Vuln in Verisign PayFlow Link payment service
>
>
> > Hello! I'm very new to this list and am looking for advice on how and
> where
> > to properly post information regarding a vulnerability I have identified
> > with Verisign's PayFlow Link credit card payment service. I would
> > ultimately like for this information to get into the Vuln Database at
> > BugTraq, but do not know the proper procedures and requirements for
> getting
> > it there. Below is a brief(?) description of the service and the
> exploit...
> >
> > THE SERVICE: The final checkout page of various online shopping cart
> > applications presents the shopper with a form asking for credit card
> acct#,
> > exp date, etc. When the shopper submits the form, the data is sent
> directly
> > to the vendor's PayFlow Link account at Verisign for validation. If the
> > credit card information if validated, Verisign authorizes payment and
> > submits the data back to the vendors shopping cart application. When the
> > vendor's shopping app receives this data, it assumes payment was
> authorized
> > and finalizes the order for the vendor to fill and ship it.
> >
> > EXPLOIT #1: On the final checkout page, save the HTML to disk and edit
> the
> > ACTION= portion of the form to direct the data back at the shopping cart
> > instead of to verisign. The exact URL should match that which verisign
> > would submit a validated order to. Save the edited HTML, reload in your
> > browser, and submit bogus credit card info with your order. Since there
> is
> > no authentication between Verisign and the shopping application, the
> > shopping app will think that the card was authorized, and so it will
> > finalize the order.
> >
> > EXPLOIT #2: Sign up for a free demo PayFlow Link account at Verisign.
> While
> > in demo mode, this account will "validate" almost any credit card info
> > submitted to it. This account should be configured to send the
> confirmation
> > information to the exploitee's shopping system. Then perform a similar
> HTML
> > edit of the final checkout page as above, only this time change the
> hidden
> > form tag to direct the payment to your demo PayFlow Link account. Save
> the
> > HTML, reload in your browser, and submit bogus credit card info.
> >
> > THE RISK: Vendors that do no validate payment in their Verisign acct
> prior
> > to shipment, or those that offer immediate downloads of software upon
> > payment, are vulnerable to theft.
> >
> > WHAT I KNOW: I have successfully performed both exploits on a Miva
> Merchant
> > 3.x shopping cart. I have not had the opportunity to test other shopping
> > cart applications or other versions of Merchant. I have communicated
> this
> > information to both Miva and Verisign. Verisign tested and confirmed
> both
> > exploits as well. They then responded that they do not intend to fix it
> -
> > that instead they will educate their customers regarding the risks and
> > encourage them to upgrade to the more secure (and costly) PayFlow Pro
> > product.
> >
> > WHAT I DON'T KNOW: I don't know what other shopping cart applications (if
> > any, besides Miva's) are vulnerable. But I am highly suspicious that
> others
> > are. I also have not verified any other version of Miva Merchant besides
> > 3.x. Merchant 4.x is the most current version, but I think it's PayFlow
> Link
> > module is the same and so it should be vulnerable as well. I would be
> > interested in working with others that have access to other shopping cart
> > apps that can interface with PayFlow Link.
> >
> > TIA!
> >
> >
>
>
>
Received on Jan 04 2002
Intro
