Post by Xsecrets » Wed Oct 27, 2010 8:46 am

Demon5 wrote:
rph wrote:But PCI compliance isn't about OpenCart. There are all kinds of things you have to do online and off that have nothing to even do with it. Scanning your cart is just one thing that happens and no one's even shown OpenCart doesn't pass!
Mcafee Says opencart doesn't pass. The way it links to other parts of opencart is open security vuln that can be used to make other sites think your site is connecting

Vulnerability Detail
Device xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Vulnerability User specified URL redirection (Open Redirect)
Port 80/tcp
Scan Date 26-OCT-2010 15:18


URL
Protocol http Port 80 Read Timeout 10000 Method POST Demo
Path /index.php
Query route=common/home
Headers Referer=http%3A%2F%2Fxxxxxxxxxxxxxxx%2F
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" 0 --X Content-Disposition: form-data; name
so if I read that right (it's really not much info) they are saying if you screw with your http headers then you can get sent to a different place which is sort of correct. opencart uses that to determine which store to show you, but I don't really see how that could be exploited. It doesn't actually redirect you to another site it simply shows different information depending on the domain name you called the script with.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Demon5 » Fri Apr 15, 2011 12:49 pm

The demo that I got from mcafee sent me to their website using my opencart as a redirect. Basically what they say is they can pass data through and hack a website and site will think it is me.
Oh and my host DOES tout PCI compliance and the servers are. I made them update the php version this morning to get that back compliant.
Last edited by Demon5 on Fri Apr 15, 2011 12:54 pm, edited 1 time in total.

https://www.lotnllc.com is your one stop shop for all your computer needs!


User avatar
Active Member

Posts

Joined
Sat Jun 19, 2010 4:12 am
Location - Sacramento, CA

Post by Demon5 » Fri Apr 15, 2011 12:52 pm

The "User specified URL redirection (Open Redirect)" false-positive or acceptable-risk submitted on "store.lordofthe.net" has been declined. Please review the technical support notes below:

The issue can be seen by using the demo link:

Login to McAfee Secure.
Click on Security tab on the top.
Click on Vulnerabilities under Audits.
Click on the Vulnerability link (User specified URL redirection)
Click on Found On under the Overview section.
Click on Detail on the right in the Found On section.
Click on Demo.
Click on Submit button on the next page.
You will see it being redirected to McAfeesecure.com

https://www.lotnllc.com is your one stop shop for all your computer needs!


User avatar
Active Member

Posts

Joined
Sat Jun 19, 2010 4:12 am
Location - Sacramento, CA

Post by grgr » Fri Apr 15, 2011 4:40 pm

PCI doesn't only cover the shopping cart but also the servers, and if you're storing details, then the office you're sitting in as well, but there is an easy get out.
Does PCI DSS apply to merchants who use payment gateways to process transactions on their behalf, and thus never store, process or transmit cardholder data?

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. However, under PCI DSS requirement 12.8, if the merchant shares cardholder data with a third party processor or service provider, the merchant must ensure that there is an agreement with that third party processor/service provider that includes their acknowledgement that the third party processor/service provider is responsible for the security of the cardholder data it possesses. In lieu of a direct agreement, the merchant must obtain evidence of the third-party processor/service provider's compliance with PCI DSS via other means, such as via a letter of attestation.
So, by using a payment method which sends the customer to the payment processors site where the whole credit card process is done on the payment processors server , your site/hosting does not have to be PCI compliant.

Examples of such would be...

Google checkout
PayPal Express Checkout
PayPal Standard
2Checkout
Nochex

But for anyone using methods where the cc info is in either way processed, or transmitted, the site (shopping cart and web servers) has to be PCI compliant.

Examples of such would be...

PayPal Pro
Authorize.Net

-
Image Image Image Image
VIEW ALL EXTENSIONS * EXTENSION SUPPORT * WEBSITE * CUSTOM REQUESTS


User avatar
Active Member

Posts

Joined
Mon Mar 28, 2011 4:08 pm
Location - UK

Post by Demon5 » Tue Apr 19, 2011 10:26 am

Yes REAL stores use things like authorize.net which requires it. The only part of anything that fails pci is the part where it can be used an open redirect. They suggested making a type of whitelist for this. My server is PCI. opencart is not simply for that ONE reason. I would think that would be easy for person that develops opencart to fix. Maybe seo url's for all links and not just products would hide and make that unusable?

grgr wrote:PCI doesn't only cover the shopping cart but also the servers, and if you're storing details, then the office you're sitting in as well, but there is an easy get out.
Does PCI DSS apply to merchants who use payment gateways to process transactions on their behalf, and thus never store, process or transmit cardholder data?

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. However, under PCI DSS requirement 12.8, if the merchant shares cardholder data with a third party processor or service provider, the merchant must ensure that there is an agreement with that third party processor/service provider that includes their acknowledgement that the third party processor/service provider is responsible for the security of the cardholder data it possesses. In lieu of a direct agreement, the merchant must obtain evidence of the third-party processor/service provider's compliance with PCI DSS via other means, such as via a letter of attestation.
So, by using a payment method which sends the customer to the payment processors site where the whole credit card process is done on the payment processors server , your site/hosting does not have to be PCI compliant.

Examples of such would be...

Google checkout
PayPal Express Checkout
PayPal Standard
2Checkout
Nochex

But for anyone using methods where the cc info is in either way processed, or transmitted, the site (shopping cart and web servers) has to be PCI compliant.

Examples of such would be...

PayPal Pro
Authorize.Net

https://www.lotnllc.com is your one stop shop for all your computer needs!


User avatar
Active Member

Posts

Joined
Sat Jun 19, 2010 4:12 am
Location - Sacramento, CA

Post by Xsecrets » Tue Apr 19, 2011 12:13 pm

Demon5 wrote:Yes REAL stores use things like authorize.net which requires it. The only part of anything that fails pci is the part where it can be used an open redirect. They suggested making a type of whitelist for this. My server is PCI. opencart is not simply for that ONE reason. I would think that would be easy for person that develops opencart to fix. Maybe seo url's for all links and not just products would hide and make that unusable?
well someone might come up with a fix if you would give a reasonable description or example of how this supposedly happens. From looking at the code I can see no way to force a redirect from opencart, and the little bit of info that the error gave you is useless and doesn't tell us anything.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by grgr » Tue Apr 19, 2011 3:29 pm

Demon5 wrote:Yes REAL stores use things like authorize.net which requires it. ....
We'll I'd completely disagree. The amount of quite large businesses using hosted pages for their web shops is quite considerable.

That said, I do agree that taking the payment on your own site is probably preferable but most shoppers are quite used to and almost expect to be redirected to hosted pages and therefore I don't see that this is a barrier to sales. Personally, I think I prefer to be sent to hosted pages as I am more confident about the security of my details, I doubt that I am alone in that.

I was also making the point that the small home run businesses don't have to panic about PCI compliance, they can just use hosted pages such as PayPal to get around it.

Almost by definition, those using free software are likely to be quite small businesses (and this is generally confirmed by those writing in the forum); 'real' larger businesses should have the resources (or money) to throw at problems like these.

All of that said, it would be nice to have the confidence to be able to take payments directly on the site and I do think that if there is a problem with opencart failing PCI scanning then it would be wise for OC to investigate and plug any holes - not least of all as being able to say that OC will pass PCI checks can only be beneficial in terms of increasing the user base and therefore revenues. I can't say as I know enough about it to know if there are any problems or not or what they would be or what would have to be done, but being PA-DSS validated must be the way forward for OC.

-
Image Image Image Image
VIEW ALL EXTENSIONS * EXTENSION SUPPORT * WEBSITE * CUSTOM REQUESTS


User avatar
Active Member

Posts

Joined
Mon Mar 28, 2011 4:08 pm
Location - UK

Post by Demon5 » Thu Apr 21, 2011 10:40 am

per Mcafeesecure.com General Solution
Remove the parameter that allows redirection from your site. If the parameter is required for operation then construct a list of valid links that the user can be redirected to [White List] and any other links that are specified the user will not be redirected to.

URL
Protocol http Port 80 Read Timeout 10000 Method POST
Edit Demo
Path /index.php
Query route=common/home
Headers Referer=http%3A%2F%2Fstore.lordofthe.net%2F
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" 0 --X Content-Disposition: form-data; name

URL
Protocol http Port 80 Read Timeout 10000 Method POST
Edit Demo
Path /index.php
Query route=common/home
Headers Referer=https%3A%2F%2Fstore.lordofthe.net%2F
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" USD --X Content-Disposition: form-data; name

they used it to redirect to their own site like 10 different ways through the opencart.

Kinda sad that the opencart people do nothing but say pci is ridiculous for security. Companies like Mcafee know security. SEO url's on the main links of the site like they have on the products might cover this up. Have mcafee scan your own opencart and you will see the demo's yourself...

https://www.lotnllc.com is your one stop shop for all your computer needs!


User avatar
Active Member

Posts

Joined
Sat Jun 19, 2010 4:12 am
Location - Sacramento, CA

Post by Qphoria » Thu Apr 21, 2011 12:40 pm

Demon5 wrote: Kinda sad that the opencart people do nothing but say pci is ridiculous for security. Companies like Mcafee know security. SEO url's on the main links of the site like they have on the products might cover this up. Have mcafee scan your own opencart and you will see the demo's yourself...
When did "the opencart people" say that?
PCI is absolutely important. But it isn't a cart issue. The cart was designed to allow payment extensions to be "extended" to the core. The individual payment extension controls the forms and data as well as security. OpenCart has simply ensured that SSL support is enabled on the payment page.

Example: If the person who codes the payment extension decides to save the cvv before sending it, that is NOT pci compliant and that is on the developer of that mod.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Xsecrets » Thu Apr 21, 2011 1:16 pm

Demon5 wrote:per Mcafeesecure.com General Solution
Remove the parameter that allows redirection from your site. If the parameter is required for operation then construct a list of valid links that the user can be redirected to [White List] and any other links that are specified the user will not be redirected to.
would be nice if someone might go ahead and say what that parameter is so we can have a look at it.
URL
Protocol http Port 80 Read Timeout 10000 Method POST
Edit Demo
Path /index.php
Query route=common/home
Headers Referer=http%3A%2F%2Fstore.lordofthe.net%2F
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" 0 --X Content-Disposition: form-data; name

URL
Protocol http Port 80 Read Timeout 10000 Method POST
Edit Demo
Path /index.php
Query route=common/home
Headers Referer=https%3A%2F%2Fstore.lordofthe.net%2F
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" USD --X Content-Disposition: form-data; name

they used it to redirect to their own site like 10 different ways through the opencart.
once again some sort of legible information would be nice. All I see there is a request to the homepage with a referrer in the header doesn't tel me anything.
Kinda sad that the opencart people do nothing but say pci is ridiculous for security. Companies like Mcafee know security. SEO url's on the main links of the site like they have on the products might cover this up. Have mcafee scan your own opencart and you will see the demo's yourself...
I would do it and have a look at it, but Mcafee charges an arm and a leg for their scans, and I'm not willing to pay that kind of money to scan something for what appears by all accounts to be completely bogus anyways.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Xsecrets » Thu Apr 21, 2011 1:43 pm

actually I found it. It's in the login.php. I think the fix should be fairly simple. I'll have to test it out. Though to be honest I don't really see how this could be exploited since in order to get someone to send the bogus post data you have obviously already gotten them to enter their data on your site, and then you are sending them back to your site, so why worry with posting it to the official site why not just post it to your site and collect the data. Besides it's not like anything relevant is going to come to you with the redirect. All the session data is server side so you won't get that anyways, and the redirect doesn't send along any post data.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Xsecrets » Thu Apr 21, 2011 1:59 pm

Ok I haven't tested this completely, but I think this change will keep it from failing the scan and maintain functionality. Like I said though this has not been thouroughly tested just a preliminary test so use at your own risk, though I'm pretty sure the worst that would happen is people wind up at the account page after logging in instead of being redirected to where they are supposed to be, but in a few quick tests everything seemed to still work.

in catalog/controller/account/login.php

find around line 36

Code: Select all

if (isset($this->request->post['redirect'])) {
                    $this->redirect(str_replace('&', '&', $this->request->post['redirect']));
                } else {
                    $this->redirect(HTTPS_SERVER . 'index.php?route=account/account');
                }
 
replace it with

Code: Select all

if (isset($this->session->data['redirect'])) {
                    $tmp_redirect = $this->session->data['redirect'];
                    unset($this->session->data['redirect']);                                        
                    $this->redirect(str_replace('&', '&', $tmp_redirect));
                } else {
                    $this->redirect(HTTPS_SERVER . 'index.php?route=account/account');
                } 
 
find around line 93

Code: Select all

if (isset($this->request->post['redirect'])) {
            $this->data['redirect'] = $this->request->post['redirect'];
        } elseif (isset($this->session->data['redirect'])) {
              $this->data['redirect'] = $this->session->data['redirect'];
              
            unset($this->session->data['redirect']);              
        } else {
            $this->data['redirect'] = '';
        }

 
and remove it. comment out if you would like.

in catalog/view/theme/default/template/account/login.tpl (replace default with your theme name if it has a login.tpl file)
find

Code: Select all

<?php if ($redirect) { ?>
            <input type="hidden" name="redirect" value="<?php echo str_replace('&', '&', $redirect); ?>" />
            <?php } ?>
and remove it. comment out if you like.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Demon5 » Sat Apr 23, 2011 1:48 pm

I applied those code patches and still get same response. I attached the entire section of security report they gave that has to do with opencart. Basically says because someone can use your opencarts as a link to their own site without people noticing "email phishing scams" and then they enter the info on scammer website. But any type of thing like that and it won't pass even though it isn't compromising your own data.

Would making all the top links like index.php/route=blah kinda links into seo type urls so they wouldn't see those links cause it to not see any of the query pieces?

If you guys can make this small stepping stone compliant the good side is you can boast PCI compliance in next version of opencart.

https://www.lotnllc.com is your one stop shop for all your computer needs!


User avatar
Active Member

Posts

Joined
Sat Jun 19, 2010 4:12 am
Location - Sacramento, CA

Post by Qphoria » Sat Apr 23, 2011 8:28 pm

Ok I think I understand what Demon and Xsecrets are saying here.
It can take you to login from yoursite and change the redirect to their site.

But it is only a redirect url, so your login isn't compromised, you are basically logging into the real site like normal, and simply being redirected to another site that has no knowledge of your login data. So it is a harmless issue, but I guess generally speaking can cause a security scan to flag it.

Xsecrets solution looks to be the correct idea. But maybe there is more.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Sat Apr 23, 2011 8:40 pm

Based on the PCI test warning.. it looks like it doesn't like the language_code and currency_code fields in the header. Haven't looked yet to see what makes them suspicious.

For grins, you could try removing the language and currency dropdowns from the header.tpl file and scan again to see if that fixes it.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Xsecrets » Sat Apr 23, 2011 10:09 pm

yeah I see it now. It's going to be the same type of thing. There really is no reason to do those redirects through post data when they are just as easily handled through session variables like I changed the other one to do. I'll dig through this latter on and see if I can track down where it's all coming from and going to and change it to use session data instead of post data.

had a quick look at it and that one is going to be quite a bit more difficult to fix since there's not an existing session I can use like there was on the login page. However if you are not using either the currency or language dropdowns you should be able to rip the code out of the controller and have it pass the scan. It will just be very difficult to make it pass the scan while keeping the functionality. Maybe we can simply do a check on the redirect post variable to make sure it includes HTTP_SERVER or something.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Qphoria » Sun Apr 24, 2011 1:18 am

I hope Demon can test with them disabled so we can be sure this is the culprit

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Xsecrets » Sun Apr 24, 2011 1:55 am

Qphoria wrote:I hope Demon can test with them disabled so we can be sure this is the culprit
just removing them from the .tpl file will not help anything, because mcafee is generating their own forms to send the data, so it would have to be removed from the controller otherwise even though it doesn't show up on the site mcafee could still trigger it with their custom forms.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by Qphoria » Sun Apr 24, 2011 1:58 am

Ah.. bastages!

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Xsecrets » Sun Apr 24, 2011 2:12 am

ok this code really hasn't been tested much at all, but I think it should work. Try it out and see if it stops the problems with mcafee.

in catalog/controller/common/header.php

find (there should be two occurrences)

Code: Select all

if (isset($this->request->post['redirect'])) {
                $this->redirect($this->request->post['redirect']);
            } else {
                $this->redirect(HTTP_SERVER . 'index.php?route=common/home');
            }
 
replace it with

Code: Select all

if (isset($this->request->post['redirect'])) {
                if((strpos($this->request->post['redirect'], HTTP_SERVER) === false)){
                    $redirect_error = true;
                } elseif(strpos($this->request->post['redirect'] === false)) {
                    $redirect_error = true;
                } else {
                    $redirect_error = false;
                }
                if($redirect_error == true){
                    $this->redirect(HTTP_SERVER . 'index.php?route=common/home');
                } else {
                    $this->redirect($this->request->post['redirect']);
                }
            } else {
                $this->redirect(HTTP_SERVER . 'index.php?route=common/home');
            }
 
let me know what happens. Like I said I haven't thoroughly tested, but in a couple of quick test the currency dropdown still redirected properly, and I believe this should keep it from allowing redirecting offsite.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US
Who is online

Users browsing this forum: No registered users and 47 guests