Security best practices in plugins for SAP Customer Check Out

[former_member311115]

Hi,

Can you please help me please understand security bounds in SAP Customer Check Out from plugin development point of view.

1. Do standard methods (for example BusinessPartnerManager.BusinessPartnerManager(string externalId)) from ENV.jar provide such checks as SQL injection check or plugin developer should think about that?

2. Is there a standard approach to store sensitive data in local CCO database ?

3.CCO allows to write JavaScript code for UI (frontend), should this such thing as validation be duplicated on backend?

One of the reason for these questions is that CCO installed locally on POS machine, which means a user can get access to backend and database (not to frontend only like in classic Web applications).

Thanks,

Sergei

[marco_becker2 · Accepted solution]

Hi Sergei,

all Users in CCO have permissions/roles assigned. Even if a standard user finds out the URL of an admin only function (e.g. configuration page) the user will not be able to access the page. The user is bound to a session. In the CCO backend the session has all information about the user. Also if the user has the admin role or not. The backend will not allow the execution of functions for which the user does not have the permission.

For your plugin, you can (and probably should) add some security measures that prevent fraud. But it is hard to tell what measures you have to add, because I don't know what your Plugin does. A Plugin can be very mighty, because in general it has access to all internal CCO methods. Depending on which method you call, it might be required to check, if the user is allowed to execute the method or not. If the user fires a request to a standard resource and your plugin will only enhance the internal logic, then the CCO security checks will take place.

If you handle backend calls entirely in your Plugin, you bypass some security checks of CCO. Then it is in your responsibility to check the permissions. With the class PermissionControl class you can check in your Plugin, if the user has a permission for a certain action or not. It is even possible to add new custom permissions.

Best regards

Marco

[marco_becker2]

Hi Sergei,

1. Nearly all the internal queries are generated with Prepared Statements where the parameters are bound in a secure way. There are some rare corner cases where Prepared Statements are not used. But in those cases appropriate measures are taken to prevent SQL injection.

2. No.

3. I'm not quite sure what you mean here. You mean you want to keep a copy of the code in the backend to validate if the frontend code was modified?

Best regards

Marco Becker

[former_member311115]

Hi Marco,

Thank you for answers.

3. As I understand, CCO is web app. In web app developer cannot trust data which is coming from frontend, because frontend is opened for end user. For example, standard web app with user roles Administrator and User. Frontend part checks which roles available for a user and shows extended interface with AdminRequest for Administrator only. Usual User cannot make AdminRequest, because it is not available in UI. However, a bad user can find this AdminRequest in JS files and run it without Administrator role. As a result, when AdminRequest is coming to backend, backend should check assignment Administrator role without trusting frontend.

At the same time, CCO has frontend and backend on one user machine. Should a plugin developer make checks on both ends (like in example before) or just frontend check will be enough?

Thanks,

Sergei