> 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:meganmcat_private] > Sent: vrijdag 4 januari 2002 1:12 > To: vuln-devat_private > 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 <keithat_private> > To: <vuln-devat_private> > 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! > > > > > > >
This archive was generated by hypermail 2b30 : Fri Jan 04 2002 - 10:56:51 PST