Vulnerability Development mailing list archives
e-commerce site security (was: Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days)
From: sinster () BALLTECH NET (Jon Paul, Nollmann)
Date: Tue, 18 Jan 2000 11:24:36 -0800
Sprach kay <kay () PHREEDOM ORG>:
And perhaps this is not the biggest/onle danger! There are numerous "e-commerce" sites on the Internet with surprisingly weak security that just wait for someone to crack them.
Very true. I've been contracted to implement a secure e-commerce site by one of my clients, and I've discovered a number of very interesting tidbits. First off, very few e-commerce sites actually do their own credit card processing. Nearly all of them license a credit card processing service from one of only a handful of such companies. These companies generally provide an executable client and/or a library against which you can link your own programs. That client/library actually makes the requests to the credit card processor, who makes the billing request of one of the "meatspace" credit card processing centers, as would be appropriate for the specific type of credit card the customer is using. The choice of CC processing service provider makes more of an impact on a site's security than anything else I've seen. Some of these providers have truly horrible security in their client/library, and some have good security. The best I've seen (and the provider I'm licensing for my project) is Signio (www.signio.com), formerly known as PaymentNet. These guys ship a client and library that are based on SSLeay, and use SSL-3 to communicate with Signio's servers. Since the server key can be hardwired to the client, that neatly avoids the biggest problem with SSL-3. Signio also, in their documentation, strongly urges that clients _not_ store actual credit card numbers anywhere, that they instead store only the verification code returned by the transaction. This code is a limited-use credit card equivalent, to the extent that other than queries (which don't return the credit card number), it only allows you to void a transaction. Also to their credit, Signio is good about allowing us licensees evaluate their security. [ Unfortunately, Signio has recently been bought by Verisign, so I expect them to start doing The Wrong Thing. ] This brings us to the second point: a tremendous number of sites out there store not just the verification code, but also the actual credit card numbers. Often that's stored in domain-wide cookies on the customer's machine, but more often they're stored in a log stored in a database table. And a disturbing number of those databases have, for instance, the old scott/tiger account enabled, or sa/sa, or sa/<no password>, or system/admin, or what have you. Some have good passwords, but the database device is a publicly readable file! Sometimes, the database is even bound to an externally visible interface! For those sites that use a processing client (instead of a library), the credit card number is nearly always a command-line argument, visible with simple tools like ps. So get SNMP access to the box, or (heaven forbid) a login shell, and you can snarf whatever credit card numbers you want without any special privileges. -- Jon Paul Nollmann ne' Darren Senn sinster () balltech net Unsolicited commercial email will be archived at $1/byte/day. A lawyer has no business with the justice or injustice of the cause which he undertakes.... The justice or injustice of the cause is to be decided by the judge. Samuel Johnson, "Tour of the Hebrides", 1773
Current thread:
- Re: Secure coding in C (was Re: Administrivia #4883), (continued)
- Re: Secure coding in C (was Re: Administrivia #4883) K Martin (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Paul Cardon (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) K Martin (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Bennett Todd (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Aviram Jenik (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Craig H. Rowland (Jan 17)
- Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days Solar Eclipse (Jan 17)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days Blue Boar (Jan 17)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days kay (Jan 18)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21Days Blue Boar (Jan 18)
- e-commerce site security (was: Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days) Jon Paul, Nollmann (Jan 18)
- Re: Secure coding in C (was Re: Administrivia #4883) Warner Losh (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Tellier, Brock (Jan 20)
- Re: Secure coding in C (was Re: Administrivia #4883) Marco Walther (Jan 20)
- Re: Secure coding in C (was Re: Administrivia #4883) Seth R Arnold (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Blue Boar (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Mikael Olsson (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Marco Walther (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) CyberPsychotic (Jan 22)
- Re: Secure coding in C (was Re: Administrivia #4883) Marc Esipovich (Jan 21)
- Generalized List of Threats and Vulnerabilities Dave Drake (Jan 21)