Hi everybody!
I've found this possible security bug in open cart (or I have done some errors configuring paypal payment).
I have Firebug (a little Firefox addon for web developers) with I can modify the HTML in realtime, I think you know it.
I created an account test on Paypal sandbox. I tried to do a test payment from opencart. Before confirming the order, and getting to sandbox paypal page, I modified the total amount (ex. from 2000€ to 5€) of the order: on paypal checkout page I saw the modified amount (2€) and NOT the real one (2000€).
Why happened? How can avoid that?
I'm sorry for my bad english..I hope that you can understand my problem
Thanks in advance to all
P.S:I used Standard Paypal payment that require the only business login mail.
you can do this with any payment gateway and its not a security risk or bug
its up to the store owner to check the order totals match with paypals before shipping an order out.
all that it would confirm is that you have payed a small amount for an order but have not completed the full payment.
seriously do you think shopping businesses just send goods out without confirming how much has been paid?
I don't understand how some one who had the skill to do this would make an issue of this.
its up to the store owner to check the order totals match with paypals before shipping an order out.
all that it would confirm is that you have payed a small amount for an order but have not completed the full payment.
seriously do you think shopping businesses just send goods out without confirming how much has been paid?
I don't understand how some one who had the skill to do this would make an issue of this.
OpenCart®
Project Owner & Developer.
Easy now, easy... he's just bringing it up for others who aren't so technically inclined.
It is a common thing among all carts... The proactive thing to do is to confirm the payment ...but for things like downloads and such, where its all automatic, you really should have a proper check in place.
The easiest way is to add a simple conditional in the callback that takes the returned price and matches it with the order price. If they don't match, then don't update the status. I usually do this with my payment modules for the same reason.
I'll see what is involved to add it to pp_standard
It is a common thing among all carts... The proactive thing to do is to confirm the payment ...but for things like downloads and such, where its all automatic, you really should have a proper check in place.
The easiest way is to add a simple conditional in the callback that takes the returned price and matches it with the order price. If they don't match, then don't update the status. I usually do this with my payment modules for the same reason.
I'll see what is involved to add it to pp_standard
Thanks to Qphoria and Daniel.
My problem was born because if I would have a shop that receives 100/200 orders in the same day, it's difficult to check all payments and sometimes maybe elude the control (specially if the modified amount is from 200€ to 160€ or something like it).
I think that adding this new little feature that checks if the payment matches with the order price, would be an interesting thing.
Thank you very much again
My problem was born because if I would have a shop that receives 100/200 orders in the same day, it's difficult to check all payments and sometimes maybe elude the control (specially if the modified amount is from 200€ to 160€ or something like it).
I think that adding this new little feature that checks if the payment matches with the order price, would be an interesting thing.
Thank you very much again
This is how I did it, for my own payment module. I removed some of the code, but it should give a good idea of how it works. This way you don't have all the hidden fields on your confirmation page - however, you would probably still want the check Qphoria talks about, just to make it more secure for user inputs via Firebug/whatever.
Edit: Ok, the window is not wide enough to show it properly, copy it to a text editor if it doesnt make sense 
Code: Select all
<?php
class ControllerPaymentQuickPay extends Controller {
public function index() {
if (isset($this->request->post['process'])) {
ControllerPaymentQuickPay::quickpay_process();
} else {
$this->data['button_confirm'] = $this->language->get('button_confirm');
$this->data['button_back'] = $this->language->get('button_back');
$this->data['action'] = $this->url->http('payment/quickpay');
$this->data['back'] = $this->url->https('checkout/checkout');
$this->id = 'payment';
$this->template = $this->config->get('config_template') . 'payment/quickpay.tpl';
$this->render();
}
}
private function quickpay_process() {
(variables being set)
echo '<body onload="return document.quickpay_payment_info.submit();">
<form action="' . $this->data['action'] . '" method="post" name="quickpay_payment_info">
<input type="hidden" name="protocol" value="' . $this->data['protocol'] . '" />
(more hidden fields ofcourse)
</form>';
echo 'Please wait a moment. Payment page is being prepared...';
}
public function callback() {
(callback)
}
}
?>Request Reviews v1.0 released.
Ya, no I get what you did too.. You have the form post back to itself first to get the rest of the fields, then use body onload to submit the page. I've done that with the ajax confirm step a few times as well.
It really depends on the payment module, what security they offer, if its a hash check, it usually includes the amount in the hash and it would fail on their server side, or if its a verification match up then it can be done on the callback side. All ways are good as long as there is something there.
It really depends on the payment module, what security they offer, if its a hash check, it usually includes the amount in the hash and it would fail on their server side, or if its a verification match up then it can be done on the callback side. All ways are good as long as there is something there.
Who is online
Users browsing this forum: No registered users and 12 guests
