Hello @Mark_Wonsil and other security minded EpiUsers!
I am curious what folks are doing to protect against SQL Injection? The scenario in mind is we have free-form text fields on a website where the input data will eventually be written to Epicor (e.g. a ShipTo address, etc.).
The research I’ve done on how to protect against injection talks mainly about how database queries are constructed / executed, but that kind of stuff is basically handled by Epicor source code, not us.
On the Ecommerce side we purchase the platform’s security addons and whatnot and they claim to “stop sql injection” but offer little actual details.
Should we be trying to take things a step further ourselves or could I be overthinking it? Does it make sense to prevent certain special characters in these free-form input fields?
I guess it’s always a good idea to sanitize inputs. An input should contain what you expect. Test for it, and even format it to remove ambiguities, e.g. YYYYMMDD, DDMMYYYY, MMDDYYYY, etc.
I don’t believe that you’re overthinking it.
Yeah, but Epicor can’t check everything. They let you deposit money in the future. So, validate what’s important to you.
The Open Web Application Security Project (OWASP) has a good list for web applications and APIs. This is a good place to start.
If you are using the BOs via REST Epicor already protects you pretty well. But @Mark_Wonsil isn’t wrong you should always sanitize your inputs where possible.
Good to know. In most cases we’re calling a Function via REST and sometimes just passing a single string parameter which is a string of json that we deserialize in the Functions and then do BO updates and whatnot.
Would the protection you’re talking about still apply to that methodology?
What if someone entered random order numbers? It’s a valid sales order but does that person have access to it? Usually, we call our Epicor Functions with a security context that have access to all entities but not restricted to a subset of its entire domain. Those are the things that you still have to check. This would be Broken Object Level Authorization (#1) from the OWASP Top 10 API vulnerabilities.
An input should contain what you expect. Test for it, and even format it to remove ambiguities, e.g. YYYYMMDD, DDMMYYYY, MMDDYYYY, etc.
So, validate what’s important to you.