response.redirect

[Todd Harvey]

I am integrating some web sites with a new third party payment processor.

The concept is that our site will prepare an amount to be charged and a code
to be called back, somehow transfer that information to the third party
processor, where a form will display, the credit card and other secure
information will be taken, and then if the charge was successful my receipt
form will be called back with the code I passed, and if it failed, the my
failure form will be called back.

The API I am supplied specifies that hidden variables are to be set in a
form which is posted to their site. The result is that the credit card form
then displays with the amount and other values I may have sent like
cardholder and address, etc. This is all perfect so far, and it all works.
Actually, PayPal used to work this way.

But, in case you didn't know, it is completely trivial for a hacker to
modify the amount going in to the third party site, and then to modify it
coming back out. There are some funny videos on YouTube explaining how to use
the FireFox add-in "Tamper Data" to do this. Here is an example:

And there are many, many videos on YouTube describing how to hack paypal.

So it looks like PayPay evolved, and there is an excellent tutorial series
on codeing PayPal with Ruby. (starting at 141, 142, 143
http://railscasts.com/episodes/archive )

But my question is, even if I prepare a url for the third party form at the
server side of my app and response.redirect to it, since response.redirect
hits the browser, I believe a hacker could potentially alter it at the
browser, and once again alter the call back to my site, so that similarly to
the funny video linked above, I could potentially be selling $500 items for
50 cents.

My question has two parts:
1) since I don't know how to use tamper data to show how to alter the URL,
can you explain to me how a hacker would change the url on the fly and hack
my site?

2) similarly, I am correct that even though I don't know how to do it,
response.redirect to a third party url is fundamentally insecure against a
hacker at the browser end?

 

[Guest]

I am integrating some web sites with a new third party payment processor.

The concept is that our site will prepare an amount to be charged and a code
to be called back, somehow transfer that information to the third party
processor, where a form will display, the credit card and other secure
information will be taken, and then if the charge was successful my receipt
form will be called back with the code I passed, and if it failed, the my
failure form will be called back.

The API I am supplied specifies that hidden variables are to be set in a
form which is posted to their site. The result is that the credit card form
then displays with the amount and other values I may have sent like
cardholder and address, etc. This is all perfect so far, and it all works..
Actually, PayPal used to work this way.

But, in case you didn't know, it is completely trivial for a hacker to
modify the amount going in to the third party site, and then to modify it
coming back out. There are some funny videos on YouTube explaining how touse
the FireFox add-in "Tamper Data" to do this. Here is an example:

And there are many, many videos on YouTube describing how to hack paypal.

So it looks like PayPay evolved, and there is an excellent tutorial series
on codeing PayPal with Ruby. (starting at 141, 142, 143  http://railscasts.com/episodes/archive )

But my question is, even if I prepare a url for the third party form at the
server side of my app and response.redirect to it, since response.redirect
hits the browser, I believe a hacker could potentially alter it at the
browser, and once again alter the call back to my site, so that similarlyto
the funny video linked above, I could potentially be selling $500 items for
50 cents.

My question has two parts:
1) since I don't know how to use tamper data to show how to alter the URL,
can you explain to me how a hacker would change the url on the fly and hack
my site?

2) similarly, I am correct that even though I don't know how to do it,
response.redirect to a third party url is fundamentally insecure against a
hacker at the browser end?

1) The PayPal code for Express Checkout or Payflow is a simple html
form. The server sends that form to a client and user submits it using
Pay Now button. Because the form is sent from the client, it may be
viewed, and modified by tools like Tamper Data. So, when you wonder
how a $500 item could be sold for 50 cents, look at the source code of
your page in IE or FF. You will find something like this

<form action=...paypal.com...'>
<input name='price' src='500.00'>
</form>

and this is what Tamper Data could modify before the HTTP request
would be sent to the remote server.

Conclusion: Never send your goods without getting full paid for it
first, always check the amount you get

2) Using response.redirect will not help here. You need to look into
IPN. It's a service you can use to check transactions on-the-fly

https://cms.paypal.com/us/cgi-bin/m...t&content_ID=developer/e_howto_admin_IPNIntro
https://cms.paypal.com/us/cgi-bin/?&cmd=_render-content&content_ID=developer/library_code

There is also a number of third-party tools you could easily integrate
IPN with your ASP.NET solution, for example

http://www.ipn-easy.com/