Api - Security

Have upgraded to 4.3.9 (from 3.0.5) - a driving force in the decision was the API and all the possibilities this opened up...

So have been starting to evolve some automated processing for "back office" use via the api. I was shocked to find the following in the order data output. Ok, so I would ONLY ever call the api over https BUT for those who don't know or understand the impact this is a major issue imho.

Coupled with the fact that passwords ARE STILL being sent via new user sign up email confirmation this is a security minefield - once again, imho!

Please, if anyone can advise in which template or script I can defeat this output being included in the API output, it would be greatly appreciated! If no response here I will be digging anyway to find it myself.

    [payment_method] => Array
        (
            [payment_id] => 18
            [company_id] => 1
            [usergroup_ids] => 0
            [position] => 0
            [status] => A
            [template] => views/orders/components/payments/cc_outside.tpl
            [processor_id] => 1000
            [a_surcharge] => 0.000
            [p_surcharge] => 0.000
            [tax_ids] => Array
                (
                )
        [localization] => 
        [payment_category] => tab2
        [processor_params] => Array
            (
                [merchant_id] => [REDACTED!]
                [access_code] => [REDACTED!]
                [password] => [REDACTED!]
                [transaction_type] => SALE
                [currency] => 826
                [cv2_mandatory] => [REDACTED!]
                [country_mandatory] => [REDACTED!]
                [state_mandatory] => [REDACTED!]
                [city_mandatory] => [REDACTED!]
                [address_mandatory] => [REDACTED!]
                [postcode_mandatory] => [REDACTED!]
            )

        [payment] => [REDACTED!]
        [description] => Secured By [REDACTED!]
        [instructions] => 

I would do this via a 'get_order_infot' hook.

In your hooked function, you could modify or delete those fields as in:

if( defined('API') ) {
  unset($order_info[['processor_params']);
}

And you might want to also unset 'payment_info' unless you need it in your export data.

If you're unsure how to do this, use the 'get-a-quote' link in my signature to tell me specifically what fields you want either deleted or their values redacted and we'll be happy to help you out.

Update: I changed the name of the hook since for this there is no '_post' suffix for this one. Guess we're not following our own internal guidelines in naming of hooks.

Hi @tbirnseth long time no speak... thanks for swift response.

Yes I simply wish to suppress API output of specific data - in this case, 'processor_params' & 'payment_info' would be sensible to avoid for "unnecessary transmission".

Is the 'get_order_info_post' hook created using the MyChanges add on? If you could give me a simple pointer that would be great - if I find myself stuck I will certainly request a quote!

Yes, you would register_hooks() in your my_changes/init.php file and then add a

fn_my_changes_get_order_info(&order_info) {
// do the unsets you want here
}

Correction. it is just 'get_order_info' for the hook. no '_post'. Apparently for histarical resons they aren't following their own rules/guidelines for naming of hooks. So in this case it's just 'order_info'. I will edit the original response above to reflect it.

BTW, finally bought an LCP last weekend.

LCP? I'm being a bit thick today!

I'm also being a bit thick as to where exactly to register the hook and add the function!

Do I need to create the my_changes/init.php file as there is none at the moment?

:)

Yes, create init.php and have code of:

And then create if necessary func.php using:

Re: LCP, I got you confused with someone else.... Sorry.
            

Ok great - thanks - should I further add the check for defined('API') as below?

LCP > ha ha! I thought so, I was checking previous posts and some email correspondence we had previously - was scratching my head!
            

Ok - so I am getting somewhat muddled as to where the init.php & func.php should reside..!

Is it (none work!):

/design/themes/responsive/templates/addons/my_changes/[here]

or

/design/themes/responsive/templates/addons/my_changes/hooks/[here]

or

/design/themes/responsive/templates/addons/my_changes/hooks/index ['index' directory does not exist yet]

or somewhere else entirely!

Sorry - i am a pain...

:S

None of the above.

/app/addons/my_changes/

Thank you...

Hmmm - that killed the entire site! Straight to "Store Closed"

Will check the code

I need to investigate this further as the above code is just forcing the "store" into store closed mode and curl error on api access.

...

I'm trying to offer examples. They haven't been tested and are meant to get you started versus being a complete, tested solution. Testing and qualification to the conditions you need is up to you. I had assumed you had some programming/development experience with cs-cart. But apparently not.

If you would like it coded, tested and be conditionalized to your specific needs,then please click the get-a-quote link in my signature and I'll be happy to give you a reasonable cost for doing so.

Yes, one of the conditions would be for if(defined('API')) but there could be more depending on your needs.

Suggest you read the tutorials on using hooks in the cs-cart documentation for details.

@tbirnseth I thank you for your help & support thus far and the examples you provided. You have always been very helpful and are a considerable asset to this forum.

I'm trying to offer examples. They haven't been tested and are meant to get you started versus being a complete, tested solution. Testing and qualification to the conditions you need is up to you. I had assumed you had some programming/development experience with cs-cart. But apparently not.

I certainly did not request a tested working solution to this issue and the examples / pointers you have provided will assist me in arriving at a working solution. I was merely posting an "observation" as to the outcome at that stage. I also understand that you have a vested interest in providing commissioned development projects.

I have considerable experience over the past few years modifying V 3.0.5 in my workplace environment creating many customisations to meet the business needs of a high turnover commercial e-commerce site. I have also recently performed a successful upgrade from 3.0.5 straight to 4.3.9 with few issues other than addressing changes to modifications owing to changes in CSS classes, jQuery and element data tag properties etc. etc.

I have a lot of experience in working with API's but the API in CS-Cart is entirely new to me as is. to a large extent, the process of "hooking" in the context of CS-Cart. Hence my request for some assistance to which which you kindly responded.

It is only my opinion, but I do feel that if a product such as CS-Cart, at its current level of evolution, is going to offer such a comprehensive API; it might be a good idea is essential to incorporate into the admin area some configuration options especially with regard to the optional transmission of what is quite frankly extremely sensitive data!

The transmission of Payment Gateway configuration data including merchant account identifiers, access codes, and passwords, when simply pulling standard Order Data over an API is, imho, a major security blunder and one that requires addressing by the development team. I shall post in the bugs / whatever area to raise my concerns. This should NOT require modding, hooking, paid add-ons or any such input to suppress. It should be by choice / consent of the site admin, not a default setting. This has very real PCI DSS implications again, imho.

Developers are most often not business owners or the appropriate responsible person who is named as Data Controller on the ICO Data Protection license or PCI DSS Assessment Certification.

What I find rather interesting and a credit to you, is that it was only you in the main and one other (The Tool) who even bothered to respond.

Rant over - once again, I do thank you for the examples you gave and will continue to work on this...

It's all good.

Note that an admin user can already be limited in their scope of information via their user group and the "permissions" that are enabled for that user group. Hence using the api credentials of a restricted user would provide restricted output versus using your "root" admin account which is basically unrestricted. Whether that includes the payment provider settings or not, I'm not sure.

I will try to add an "UNTESTED" line next time I provide a code segment that is off the top of my head versus being lifted from an already proven implementation. And yes, I do like to generate some revenue off of consulting services which is my business. But I also try to help where possible when it doesn't require a big investment of time on my part since time is what I sell.

It's all good.

Cool :)

Note that an admin user can already be limited in their scope of information via their user group and the "permissions" that are enabled for that user group. Hence using the api credentials of a restricted user would provide restricted output versus using your "root" admin account which is basically unrestricted. Whether that includes the payment provider settings or not, I'm not sure.

That's a very good point - I will try that in a minute and see what output I get...

I will try to add an "UNTESTED" line next time I provide a code segment that is off the top of my head versus being lifted from an already proven implementation. And yes, I do like to generate some revenue off of consulting services which is my business. But I also try to help where possible when it doesn't require a big investment of time on my part since time is what I sell.

Of course! I completely understand that...

Update:

I created a new user group "API Restricted" with only "View Orders" privileges enable and edited my "API User" to only be a member of that group by "declining" membership of any other group including the Administrator group.

Same output displayed... By definition the API User has to be an administrator to enable the "API" access in the first place.

That seemed a very logical way forward but seems to have no effect - I will play around with it a bit more though. I did close all browser instances first in case it picked up my root admin logged in status etc.

I'll be interested in the results.... It "should" conform to the permissions associated with the admin user.