SQL Injections

 SQL injections: 

are really devastating and very dangerous, but can be quite simply avoided by following some simple steps that we will state here.

First, ensure that your database user privileges are as limited as you can (principle of least privilege). For example, actions done by a front-office user should be executed in the database by a user that only has rights on front-end-related tables. If no need to delete data on a specific table, then do not give delete rights to that user on that table, and this should be respected in all the phases of dev.

Second, sanitize all inputs for SQL instructions by referring to the filtering/escaping.
A more tangible way to avoid SQL injection bugs is to use prepared statements (PS).
How to implement prepared statements, you can take a look here: http://php.net/manual/en/pdo.prepared-statements.php

Command Injections:

Using command executions through your PHP code is very powerful and useful, but also very dangerous if used without precautions, as is the case of new developers. Therefore, it is recommended to disable dangerous functions with the disable_functions directive in the php.ini file of the deployment server. Once deactivated, these functions will not be accessible to hackers writing their own PHP code through another potential flaw.

disable_functions = show_source, exec, shell_exec, system, passthru, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source

When using one of these functions, pay extreme attention to parameters. Ensure data is properly validated against whitelists and/or filtered. Entire commands and arguments can be escaped with built-in functions escapeshellcmd (http://php.net/manual/en/function.escapeshellcmd.php) and escapeshellarg (http://php.net/manual/en/function.escapeshellarg.php).

Session Hijacking:

Sessions rely on session ids.
One common attack is the session fixation attack, which consists in giving a session ID to a victim before they log in, and then using that same session ID to use the victim’s session.

To avoid such problems, some rules must be followed:

• Do not accept session IDs coming from URLs or POST requests by using the session.use_only_cookies directive in php.ini.
• Protect session cookies with HttpOnly and Secure flags by using session.cookie_secure and session.cookie_httponly parameters in php.ini file.
• set a better entropy to your session ID by setting session.entropy_file = /dev/urandom in php.ini, on linux systems.

A key point is to regenerate session IDs at a critical moment: when logging users.
You can trigger a session ID renewal by calling the session_regenerate_id function (http://php.net/manual/en/function.session-regenerate-id.php).

Additional important steps can be implemented to add security at different levels (defense in depth):

• keeping track of the user’s last activity in the session, to detect suspicious behaviors on critical functions.
• saving the user agent in the session and verifying it at key points.
• checking the IP address is not recommended, as it can change dynamically, for instance on mobile networks.

XSS:

Protecting your website against XSS is quite simple as it looks; you have to apply the “filter on input, escape on output” principle.
But do not forget to apply it to all parameters, including hidden parameters, GET/POST parameters, cookies, and HTTP headers.

Great complementary XSS protection can also be achieved via some HTTP headers, which we detailed in a previous article about HTTP headers for security.