I am converting a CI3 webapp to CI4 we need to make sure that our code security strategy is rock solid. Please comment on what is wrong and what is missing.
Escaping outputs:
- Many of the built-in CodeIgniter 4 library functions automatically escape outputs. Examples of this are form_input(), form_password(), form_upload(), form_textarea(), form_dropdown(), form_multiselect(), form_checkbox() and form_radio(). anchor() also is automatically escaped, so no need to do anything with those.
- Output outside of this should always be wrapped in esc() and using the correct context as a 2nd parameter.
- If done correctly, we shouldn't experience problems of data being garbled.
Validation of Inputs:
- CodeIgniter has validation mechanisms that allow us to return errors to the user when invalid data is sent.
- We need to be validating textboxes and other form input for correct data, and required data.
Query Security:
- CodeIgniter4's Query Builder should be used when possible. This is because QueryBuilder has automatic escaping of queries and creates parameterized queries.
- Any time queries are not written using QueryBuilder or QueryBuilder->rawSql() is used, $this->db->escape() should be wrapped around variables being inserted into the database and $this->db->protect_identifiers() should be wrapped around variables representing table or column names.
Database Security:
- Encryption of all information which can be used to identify an individual including names, addresses, phone numbers, email and addresses.
- Passwords need to be encrypted, hashed and salted.
- Encryption of API keys used in API calls.
Now on to what I am less certain about:
- CSRF is needed, but we need to do everything in such a way that it doesn't hinder APIs since those will be needed for third party integrations. If it's interfering, potentially using token authentication and APIKEYs in place of CSRF is warranted?
- General best practice, I'm told, is to store html and tags in the database as they are entered (i.e., not encoded). Filtering inputs practices though seems to frequently suggestion wrapping $_POST (getPost() in CI4) in htmlspecialchars() since getPost($foo, FILTER_SANITIZE_STRING) is deprecated. Those functions encode special characters though before they get sent to the model for storing in the database. So the big question is what does Filtering Inputs need to look like if we want at least some HTML to not be encoded?
- One option is simply stripping unwanted data. For example with phone numbers we may wrap that in a preg_replace() that filters anything that is not '(', ')', ' ', '-', '+','[0-9]' and maybe 'x' or '/' for indicating extension numbers. We only have certain kinds of data, so it seems reasonable to have a handful of functions in the security_helper to properly filter these kinds of values without mangling the text. It also makes sense to use the 2nd parameter of getGet() and getPost() where it doesn't mangle text since those are already written. In places we want some HTML tags to be allowed (such as descriptions and attribute text) perhaps using something like https://github.com/ezyang/htmlpurifier rather than strip_tags() would be a good approach.
