Security

Security built-in features

As standard, ZnetDK 4 Mobile includes several features to protect the web application against hacker attack attempts.

User authentication

When access to the application is protected by entering a login ID and password (see CFG_AUTHENT_REQUIRED parameter), ZnetDK 4 Mobile applies the following security measures:

• Hashed password stored in database: user passwords are hashed with random salt using the PHP password hashing API before being stored in the database.
• Only one user session open at the same time: the user is automatically logged out when another user logs into the app with the same login ID. This behaviour applies in version >= 3.0 of ZnetDK 4 Mobile (see CFG_SESSION_ONLY_ONE_PER_USER parameter).
• Session cookie mandatory for login: since version >=3.3 of ZnetDK 4 Mobile, the login process is only executed if the session cookie received by downloading the login page, is transmitted in the request HTTP header.
  In other words, this means that the login page must first be downloaded before being able to log in within the context of the login page's user session. The number of login attempts can then be tracked within the user session.
  To bypass login attempt tracking in user's session, an attacker must re-download the login page (without the session cookie in the request header) to start a new user session.
• Login throttling: since version >=3.3 of ZnetDK 4 Mobile, login process is locked out for a specific login name during 60 seconds after 5 login failures occurred in a 30 seconds time window.
  Le nombre d'échecs de connexion pour un même nom de connexion est suivi en dehors de la session utilisateur pour éviter d'être contourné par un attaquant (par exemple en effaçant le cookie de session en fermant le navigateur Web après chaque tentative).
  This mechanism can be customized through the following constants: CFG_LOGIN_THROTTLING_ATTEMPTS_BEFORE_LOCKOUT, CFG_LOGIN_THROTTLING_LOCKOUT_DELAY and CFG_LOGIN_THROTTLING_ATTEMPTS_WINDOW_TIME.
• User account disabled after multiple login failures: a user account can be disabled after too much login attempts (see CFG_NBR_FAILED_AUTHENT parameter). This mechanism is not longer enabled by default since version >=3.3 of ZnetDK 4 Mobile.
• User session expiration after a too long inactivity: the user must renew their session after too long inactivity by re-entering their password (see CFG_SESSION_TIMEOUT parameter).
• Password validity limited in time: The user's password has a limited validity period and must be changed periodically (see CFG_DEFAULT_PWD_VALIDITY_PERIOD parameter).
• Strong password required: user must enter a password strong enough to register it (see CFG_CHECK_PWD_VALIDITY parameter).
• Secure password reset system: requesting a new password via the Forgot your password? link requires verification of the authenticity of the user at the origin of the procedure by sending a first automatic email. If the user confirms that they are the originator of the request, then they receive a second email containing an auto-generated password. This feature is available in version >=2.5 of ZnetDK 4 Mobile (see CFG_FORGOT_PASSWORD_ENABLED parameter).

Restricted access to user authorizations

Authorization management is reserved for users with appropriate rights only (see User rights).

Additionally, no user password is loaded in a user's edit form.

In version >=3.0 of ZnetDK 4 Mobile, reinforced security measures have been added to prohibit access to authorizations by calling the application controllers for managing users and user profiles.

Preventing SQL Injection attacks

The ZnetDK PHP API includes the \DAO and \SimpleDAO classes designed to execute SQL queries using bound variables to set the values of the conditions specified in the WHERE clause, thus eliminating the risk of SQL Injection attacks.

See in particular, \DAO::setFilterCriteria() and \SimpleDAO::getRowsForCondition() methods and the \DAO::$filterClause property.

Strict input data sanitization

In order to eliminate the risk of Cross-Site Scripting (XSS) attack, the data entered by the user is systematically cleaned by the ZnetDK object of type \Request before being processed by the recipient controller action.

CSRF token

When authentication is enabled (see CFG_AUTHENT_REQUIRED parameter), all AJAX requests executed on the client side via the ZnetDK request method pass a token whose validity is automatically checked upon execution of the target controller action.
As a result, controller actions cannot be executed outside of the page containing the application and prevents the risk of a Cross Site Request Forgery (CSRF) attack.
This protection applies to version >= 3.0 of ZnetDK 4 Mobile.

Protection of sensitive files and directories

Access to sensitive files and folders located in the ZnetDK for Mobile installation directory is protected by the .htaccess script.
Only public resources can be read and the index.php root script is the only script that can be directly executed remotely for an application.
The .htaccess script is auto-generated in version >= 3.0 of ZnetDK 4 Mobile.

Generic error messages

To avoid disclosing sensitive information when displaying technical errors (E_ERROR, E_PARSE, ...) or uncaught exceptions, technical error details are hidden by default from the end user (see CFG_DISPLAY_ERROR_DETAIL parameter).
This protection is available in version >= 3.0 of ZnetDK 4 Mobile

Developer best practices to strengthen security

This chapter presents several best practices for developers to prevent the risk of hacker attacks.

Server-side data validation

Validating form data on the browser side is not sufficient because a malicious user can always directly call the controller action linked to the form and thus bypass this first level of control.
Server-side data validation is carried out in the controller action through an object of type \Validator.

Output data sanitization before display

In the case where you access the data entered by the user by directly reading on the server-side in PHP the POST parameters (via $_REQUEST or $_POST variables arrays) without going through a \Request object, then be sure to encode or clean this same data if it is intended to be displayed in the application in order to protect against Cross-Site Scripting (XSS) attack.

HTTPS deployment

Your internet application must be deployed in a production environment in HTTPS so that the data exchanged between the browser and the internet hosting is end-to-end encrypted. Also be sure to configure systematic redirection from port 80 to port 443 on your internet hosting to prevent access to your application via HTTP.