quick checklist

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet

  • SQL injection
  • code execution: beware unserialize()/exec() user supplied variables
  • command execution: do not use user supplied vars in commands. It allows an attacker to terminate the intended command and to append arbitrary system commands for execution. Common character sequences to separate commands are semicolons (;), boolean operators (&|), $(subcommands), `backticks`, and newline characters (%0a). This can be prevented by using the built-in function escapeshellcmd() on the whole command or by escaping all command arguments with the built-in function escapeshellarg(). It is recommended to avoid invoking system commands from a web application whenever possible.
  • PHP object injection: occurs when user input is deserialized. `unserialize(base64_decode($_GET['url']))` An attacker can inject objects of any class type with arbitrary properties into the application's scope by providing these in a serialized string format. When the object defined by the attacker is instantiated, certain magic methods of the injected class type, such as wakeup() and destruct(), are automatically invoked. Depending on the magic methods defined within the application's code and the involved properties that can be controlled by the attacker, further vulnerabilities or code can be triggered. It is highly recommended to avoid the deserialization of user input and to use the built-in functions json_encode() instead.
  • Cross-Site Scripting(XSS): escape user provided content printed on the page, uses should not execute js scripts on the page
  • File inclusion: never use a user supplied variable in a path
  • Path traversal: user input is used unsanitized in a file path for reading. An attacker can access arbitrary files on the FS by using '../'. This can lead to the disclosure of PHP code, configuration files, and login credentials. use the built-in function basename() to ignore injected directory names. It is recommended to create a whitelist of all allowed file names.
  • file upload: may allows users to upload malicious files to the web server. For example, a remote code execution can be achieved by uploading a PHP file into the document root. Often, the file extension plays an important role and depending on the web server's configuration, different file extensions such as .php, .php4, or .php.zzz are passed to the PHP interpreter. Furthermore, uploading a .htaccess file can lead to remote code execution and uploading .htm, .html, .swf, or .svg files can lead to persistent cross-site scripting. Note, that certain built-in functions used to ensure the presence of an image, such as getimagesize(), can be bypassed. It is recommended, that uploaded files are not stored in the document root and the file's name is not in control of the user.
  • variable tampering: occurs when user input is used to dynamically access variables. `$template_name = ${$install_to};` An attacker might be able to interfere with the applications logic by manipulating sensitive variables.

The detected vulnerability allows to assign arbitrary variables to a variable. This can lead to information leakage or unexpected application behavior.

// xss mitigation functions
function xss_safe($str, $encoding='UTF-8') {
   return htmlspecialchars($str, ENT_QUOTES | ENT_HTML401, $encoding);
}

the enemies:

  1. Week Passwords: too simple to get by with brute force
  2. predictable path: easy to guess resources urls
  3. XSS: Cross-site scripting, Allowing users to enter text that will be displayed to other users without encoding.
  4. SQL injection: It is a vulnerability in the database layer of an php application. When user input is incorrectly filtered any SQL statements can be executed by the application. You can configure Apache and write secure code (validating and escaping all user input) to avoid SQL injection attacks. A common practice in PHP is to escape parameters using the function called mysql_real_escape_string() before sending the SQL query.
  5. Spoofing
  6. File uploads It allows your visitor to place files (upload files) on your server. This can result into various security problems such as delete your files, delete database, get user details and much more. You can disable file uploads using php or write secure code (like validating user input and only allow image file type such as png or gif).
  7. Including local and remote files: An attacker can open files from remote server and execute any PHP code. This allows them to upload file, delete file and install backdoors. You can configure php to disable remote file execution.
  8. eval(): Evaluate a string as PHP code. This is often used by an attacker to hide their code and tools on the server itself. You can configure php to disable eval().
  9. CSRF (Cross-site request forgery - Sea-surf Attack): forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
  10. Storing passwords in your database Always salt and hash your passwords instead.
  11. DDoS: Not protecting your system from oversized message payloads. Similarly, not limiting data returned by queries.
  12. Not protecting objects that users can update in the database. Allowing users to, for example, update their own objects to gain elevated privileges.
  13. Providing various accounts with unnecessary privileges. That account should have the absolute minimum permissions in the database.
  14. Not patching/updating dependencies when security vulnerabilities in them are discovered. Remember - your vulnerabilities/attack surface is that of your software plus every other piece of software you use.
  15. For larger teams: Allowing too many of your credentials to be known by too many people.
  16. Failure to audit is a vulnerability: Make sure all your systems are monitored and produce detailed logs. Suspicious activity should raise red flags! E.g. multiple failed logins from the same IP. E.g. multiple 403 errors for a logged-in account.
  17. Failure to understand the power of social engineering [e.g. phishing attacks] and to take steps to mitigate it.
  18. Lack of end-to-end encryption, lack of encryption at-rest, lack of protection from request forgery.

web application self password reset mechanisms properly:

  • Don't reset the user's password until confirmed. Don't immediately reset the user's password. Only reset it once the user clicks on a confirmation link sent to their pre-registered email address.
  • Require a CAPTCHA. When a user requests that their password be reset, force them to solve a CAPTCHA before proceeding any further. This is to prevent automated tools from trying to give many users grief, and force the user to prove they are a human (not a robot).
  • Randomness. The time-limited password reset URL should include a random, unguessable component. Make sure you use crypto-quality randomness. The output from /dev/urandom or System.Security.Cryptography.RNGCryptoServiceProvider would be a good choice. The output from rand() or random() or System.Random are not random enough and would be a bad choice. A GUID or timestamp is not random enough and would not be a good choice.
  • Include a time limit. The reset confirmation link should expire after some reasonable time: say, 24 hours. The link should be usable only once, and should immediately expire as soon as it is used.
  • Include explanatory text in the email. You may want to add some explanatory text to the email, to explain why the email was sent, in case someone requests a reset for an account that is not your own. You could include some text like "Someone has requested that the password be reset for your account username on site. If you made this request, click here to change your password. If you did not make this request, click here to cancel the request."
  • Send email after the password is reset. Once the password is successfully reset, send email to the user to let them know that the password has been changed. Don't include the new password in that email.
  • Monitor cancellations. You might consider including some logic to monitor the frequency with which users click the cancellation link indicating that they didn't request a reset. If this goes above a certain threshold, it might be useful to send an alert to the system operators. Also, if a cancellation link for some request is visited after the confirmation link is visited, that's a potential indication of an attack against that user -- you may want to take action at that point, e.g., invalidate the user's password and require them to reset their password again. (This is a defense against the following attack: the attacker gains access to the user's mailbox, then requests that their password on your site be reset, then visits the confirmation link. If the attacker doesn't delete these emails from the user's inbox, then when the real user reads their email, they may click the cancellation link, giving you an indication of possible trouble.)
  • Use HTTPS. The link should use https (not http:), to protect against various attacks (e.g., Firesheep attacks on users surfing the web from an Internet cafe).
  • Log these operations. I suggest logging all such requests. In addition to logging the user's username, you may want to log the IP address of the client that requested a reset link be emailed to the user, as well as the IP address of the client that visited the reset link.
  • Lastly, consider non-password authentication . Passwords have many problems as an authentication mechanism, and you might consider other methods of authenticating users, such as storing a secure persistent cookie on their machine with an unguessable secret to authenticate them. This way, there is no password to forget and no way for the user to be phished, though you do need to provide a way for a user to authorize access from a new machine or a new browser (possibly via email to the user's pre-registered email address).]] Another one is to send half the reset code by SMS messaging to a registered mobile phone (two factor authentication).

There are three ways to authenticate an identity: based on what he has (phone, a device), or what he knows (a password, a story), or, what he is (his fingerprint, palm scan). The last is unusable in a remote context. to use what you have (usually time-limited) typically involves tokens, or one time password. You can also sidestep this complexity altogether: OAuth / OpenID / sign in via Facebook, Google, twitter.