--=-joks/e+GOqCDRe2aO2sd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Miva Merchant is one of the largest non-free online shopping carts used
by bulk web-hosting sites.  Miva allows small to medium shops to get
online and sell their products without the hassle of learning to code
custom scripts that would probably do much more for much less money.
All this simplicity comes at a price of security, however.

I have found a vulnerability where it is possible to bypass the tax
calculation functions in such an online Miva store when placing an
order.  I am not certain if this is due to common misconfigurations, or
the "enhancement" of the OpenUI extension.  In either case, for high
volume online retailers, this loss in taxes could add up if exploited.
For instance, there used to be a computer manufacturer named Go-L.com or
L-computers that sold very high price computers online ($80,000).  They
used Miva, and if it were possible to bypass say %5-10 of sales taxes,
that could mean a lot of money!  Following is a demonstration PoC
example.

Go to your favorite online Miva store by googling for "merchant.mv" or
"merchant.mvc".  Find one that does shipping tax calculation, which can
be verified by adding something to your basket and going through
checkout until right before you are asked to enter a credit card number.
It should display a tax calculation amount for your basket total with
shipping.  If you've found one, now go back to the previous page titled
"Checkout: Shipping/Payment Selection".  On that page is a hidden POST
form named OSEL and an input named "Action".  "Action" is set to values
"SHIP,CTAX".  If you remove the CTAX action from the form, then tax
calculation will never ensue -- and you have saved yourself some cash!
This is just stupid, so I hope it is not commonly exploitable even in
the new Miva 5!!?  Can anyone verify this?

There seem to be other various ways of doing the same sort of thing with
other hidden form values.  One specific value of interest is on the
"Checkout: Payment" page.  The input "Action" is set to "AUTH" for the
credit card, but I wonder what cool things could happen if this and/or
the previous hidden form was crafted in special ways ;-)  I leave the
ladder as an exercise in proper judgment for you.  Remember, all you
Jedi webmasters, that hidden forms are no _form_ of security (bad pun
exceptionally ill-intended).

http://www.miva.com/

*** This vendor was never notified because Miva Merchant sucks and is a
horrible rip-off product.  Use osCommerce instead, since it is also more
secure and Open Source.  If you want to be raped, economically and
mentally, use Miva.

http://www.oscommerce.com/
--=20
Kristian Hermansen <khermansen@ht-technology.com>


--=-joks/e+GOqCDRe2aO2sd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBClCOWISAslhPnyaURAus/AJ9b+HeR7hWEPrudAiWnuF9p8dS/bQCglTKn
z++L44nNi8g4aOlo9xh9KDo=
=g+3+
-----END PGP SIGNATURE-----

--=-joks/e+GOqCDRe2aO2sd--