Security in ConfigBox

The ConfigBox application code is follows best practices on security. Here we discuss how we deal with OWASP’s Top 10 Critical Web Application Security Risks.

If you have any concerns, feel free to contact us with specific questions and we will do our best to provide you with concrete information.

SQL Injection

Strict input sanitation in DB queries: Every database query ConfigBox makes has any dynamic variable (user supplied or otherwise) cast to integers or escaped to make it impossible to query for anything other than intended data.

No difference between user-supplied input and system-supplied input: We sanitize every variable in queries, no matter if the variable is user-supplied or comes from the system.

Unfiltered user input

Input validation for both anonymous and trusted users: This regards input from anonymous website visitors as well as authenticated users like administrators and alike.

Validation against whitelists: Every input (be it query string parameters, POST data like strings and files) are sanitized and validated according to its intended use and restricted to its minimum. Plain text get goes through htmlspecialchars or where applicable through a whitelist of allowable characters. Numbers to go through intval() or floatval(). HTML generally gets filtered through a whitelist (we use HTMLPurifier).

Files are checked against a whitelist of file extension and MIME-types (individually for the intended sue).

Injection for malicious file inclusion: Any user input that directly or indirectly refers to a file to be included or served gets sanitized carefully to avoid maliciously crafted input to include an unintended file.

Authentication and session management

Passwords: Password storage is handled by ConfigBox’ platform (Joomla, Magento). Both systems store user passwords hashed and salted. The platform can implement a password complexity policy to avoid weak passwords.

Session token: CB uses its own session token system. The session token’s key and value each are randomized 64-character strings and passed by a cookie. When a user log’s out, the token gets removed.

Encrypted transmission of credentials: Every form that deals with user credentials transmits via HTTPS (on servers supporting HTTPS).

Cross-Site Scripting (XSS)

Output: Any dynamically generated output (user supplied or otherwise) to the browser get’s converted for its intended use. Numbers get type-casted to integers or floats, plain text goes through htmlspecialchars($string, ENT_QUOTES). HTML gets script tags and event handler attributes filtered out.

This ensures that even if any exploit managed data manipulation, no client scripts will reach a browser.

Input: Any user input gets sanitized according to the input’s intended use. Numbers, plain texts, HTML, file types. HTML gets filtered for script tags and event handler attributes to ensure no browser script language can get stored.

Direct Object References

No server-side source-code file can execute or output anything when accessed directly. Every source-code file has a check on if it was included through the authorized entry file.

Sensitive Data Exposure

Authorization: For any data served to the user, ownership of the data or authorization to see other’s data is checked for. Through the users session token we identify the user. Every request to serve a user’s data (be it cart contents, quotations, profile data etc.) goes through a check if the data in question belongs to the user.

Data storage: Data is stored in the platform’s database schema and in the application’s store directory. Solid access control to the database and file system is up to the site owner.

Function Level Access Control

User privilege checks: When a user requests an application action, the request goes through the application’s authorization check. Actions (tasks in the MVC terminology) are compared with the list of actions the user is privileged for and on a negative result, the action will not be carried out.

Cross-Site Request Forgery

CSRF Tokens: ConfigBox for Magento uses Magento’s CSRF token validation for all non-static HTTP requests to the application. ConfigBox for Joomla currently lacks a similar CSRF token.

Unvalidated Redirects and Forwards

When ConfigBox issues a redirect header, the redirect URL is built without any user input or with sanitized and validated user input. We never use a whole user-supplied URL for redirection, but individual pieces of data (e.g. an ID for a certain item) and build the URL from it.