
I just discovered major security flaws in my web store - billpg
http://security.stackexchange.com/questions/5701/i-just-discovered-major-security-flaws-in-my-web-store
======
pkteison
I wish I was surprised. I bet the shipping is calculated via Javascript and
people with Javascript turned off get free shipping too. Intro to CS courses
don't think they have enough time to get into the details of what code runs
where and who and what you can trust and what encryption really does and why
"oh just use https" doesn't solve everything, but it's one of the most
important topics that everyone exposed to a bit of programming should know and
consider. If a rewrite proxy can give your customers free stuff, it's somehow
at the same time both just unforgivable yet almost expected/par for the
course. I wonder how many sql injection and cross site scripting holes are in
the same site.

Obligatory please-educate-yourself link: Open Web Application Security Project
top 10 list:
[https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)

------
nbpoole
This is a fairly common issue when people are integrating with third party
payment providers:

\-
[http://checkout.google.com/support/sell/bin/answer.py?answer...](http://checkout.google.com/support/sell/bin/answer.py?answer=88180)

\- [https://payments.amazon.com/sdui/sdui/helpTab/Amazon-
Simple-...](https://payments.amazon.com/sdui/sdui/helpTab/Amazon-Simple-
Pay/Amazon-Simple-Pay-FAQ#malicious)

\- [http://letsearndollar.blogspot.com/2009/07/change-any-
paypal...](http://letsearndollar.blogspot.com/2009/07/change-any-paypal-price-
with-data.html)

------
mrspandex
I hate when the top answers on stack exchange sites are suggestions to do
something completely different (don't write your own web store). I wonder how
that could be avoided. Should he have worded the question differently? Should
there be separate upvotes for "answers question" and "useful information"?

~~~
MostAwesomeDude
On help groups, it has become common to address the XY problem: A user cannot
solve problem X, but thinks that problem Y is equivalent and tries to solve
that. The user can't solve Y either, and goes to ask for help on problem Y,
without mentioning problem X.

Of course, this doesn't apply to this particular question, but I figured I'd
explain why people do this.

~~~
alttag
Mmmm... I think it's more than that. It's been my experience that questioners
don't always ask the right question. For example, consider the (not entirely)
hypothetical "How do I implement drop-down menus?" What the person typically
needs is some sort of navigable interface for a web site--but that's not what
they ask for.

How is the root question uncovered? By asking questions. (Why do you need it?
How far along is the project?)

The best solution answers both what they asked and what they should have
asked.

The reason people do this (as you say) is that they sometimes have enough
experience to suggest a different path altogether.

------
tedunangst
Is HTTP header just a codeword for cookie? How does a website get the browser
to send custom headers?

~~~
midnightmonster
HTTP header is code for "POST data".

~~~
tedunangst
That makes sense. It was worth the negative karma to solve the mystery. :)

------
danso
Hmmm...is this a problem of someone who was hired to do the front and the
backend? Why would freight and total price be calculated client-side, instead
of the backend taking in quantity as input and then doing the calculation
against the inventory db?

------
midnightmonster
Ahhhhhh... Someone is wrong on the Internet!

The card thing is really No Big Deal. It's actually a pretty smart integration
with one shortcoming.

Whatever gateway they're using has some support for you maintaining control of
the checkout experience while not actually receiving or transmitting card data
--a great thing for PCI compliance. So the form is on an HTTPS page on the
merchant's site, but instead of posting to the merchant's app, it posts
directly to the gateway. The gateway communicates status with the merchant via
a synchronous HTTP request or signed data in a redirect URL, and the
merchant's software processes the transaction without ever seeing card data.

As the OP says, "they're using HTTPS"--yes, this makes _all_ the difference.
The only reason the info appears to be clear text to him is that he's using
Tamper Data, a browser extension that lets you play with your own POST data
_before_ you send it over HTTP(S).

This is the Right Way to do it for a site that doesn't get some compelling
advantage out of building the infrastructure necessary to be PCI compliant.
Done this way, PCI compliance requires just the trivial SAQ A. The only
problem with this is that either the gateway does not support (sadly, the most
common case) or the developer did not implement signing the transaction
details on the merchant side.

~~~
pavel_lishin
It's No Big Deal until someone orders $10,000 worth of merchandise, pays $1
for it, and it gets shipped to an empty house in a subdivision before someone
notices.

Then it's a Really Big Fucking Deal Oh God How Will We Pay Rent.

~~~
narcissus
So admittedly I've only ever dealt with Paypal as a third party taking payment
(as opposed to a few other systems where my server talked directly to the
payment gateway).

One thing I noticed that the OP did not mention was whether or not the
website's own 'transaction ID' was part of the transaction details being sent
and / or whether or not the third party site returns a transaction ID
themselves. At least with Paypal, the client makes the payment then they are
returned to the original site with a 'receipt' transaction ID and it is then
up to the original site to take that receipt number and do their own look up,
back to Paypal, to ensure that the amount paid was actually the amount it
wanted to be paid...

If that is happening with the OP's site, then I don't think there's anything
stupid going on (or, at least, it's relatively simple to resolve).

~~~
midnightmonster
I used a lot of systems. AFAIK, they all give some way for you to set your own
transaction ID, and they all provide you with a gateway transaction ID, too. A
good system will have a backend process to reconcile records based on one of
these and would of course flag anything where the dollars don't match. This is
the (inadequately explained) basis of my contention that the price editing is
not a big deal. Of course, it could be a big deal if they botched a lot of
other things, but by itself it doesn't mean there's an actual serious problem.

