Security Checklist - Githubissues

adam-buckley commented 11 years ago

Some sources with good PHP security tips, cmfive will need to be checked over with these as security is paramount with a business orientated webapp:

http://en.wikibooks.org/wiki/Web_Application_Security_Guide/Checklist http://bitly.com/bundles/enygmadae/3 http://websec.io

adam-buckley commented 11 years ago

We will want to check through cmfive and make sure we use $_REQUEST in the right area, as http://stackoverflow.com/questions/2142497/whats-wrong-with-using-request explains, REQUEST also includes COOKIE which should not be included with form data

careck commented 10 years ago

Hi Adam,

please follow this up more. We want cmfive to be as secure as we can.

adam-buckley commented 10 years ago

Here's a semi-shortened list from the first link that apply to us (IMO):

PHP Specific Issues (Im putting this at the top :) )

[x] Do not use the short form “<?”, always use the full form “<?php”
[x] preg_replace can act as eval() in certain cases. Avoid passing user input to it. If you must, correctly filter and escape it. using /e is the eval flag for preg_replace, we just need to avoid using it (so far so good)
[ ] Use the Suhosin (including the patch, if possible) and configure it with strict rules
- Enable suhosin.executor.disable_emodifier
- Enable suhosin.executor.disable_eval if possible
- Set suhosin.mail.protect to 2 if possible
[x] Use POST requests instead of GETs for anything that triggers an action
[x] Ensure robots.txt does not disclose "secret" paths

SSL

[ ] Follow https://www.ssllabs.com/projects/best-practices/

Misc

[ ] Do not rely on Web Application Firewalls for security (consider using them to improve security) like http://ironbee.com
[ ] For every action or retrieval of data, always check access rights
[ ] Ensure debug output and error messages do not leak sensitive information
[x] Do not use “eval()” and similar functions
[x] Avoid “system()” and similar functions if possible
[ ] Consider to block old browsers from using your application For that we could use something like http://www.devcha.com/2012/03/how-to-detect-old-browsers-in-php-and.html
[ ] Ensure database servers are not directly reachable from the outside

File Inclusion

[ ] Avoid having scripts read and pass through files if possible.
[ ] Ensure the application runs with no more privileges than required.

File Upload

[ ] Ensure that files uploaded by the user cannot be interpreted as script files by the web server
[ ] Ensure that files cannot be uploaded to unintended directories
[ ] Try to disable script execution in the upload directory
[ ] Consider re-compressing images using a secure library to ensure they are valid
[ ] Ensure that uploaded files are specified with the correct Content-type when delivered to the user
[ ] Prevent users from uploading problematic file types like HTML, CSS, JavaScript, XML, SVG and executables using a whitelist of allowed file types
[ ] Prevent users from uploading special files (e.g. .htacces, web.config, robots.txt, crossdomain.xml, clientaccesspolicy.xml)

SQL

[ ] Always ensure the DB login used by the application has only the rights that are needed

XSS

[ ] Escape anything that is not a constant before including it in a response as close to the output as possible
[ ] Explicitly set the correct character set at the beginning of the document (i.e. as early as possible) and/or in the header.
[ ] Ensure that URLs provided by the user start with an allowed scheme (whitelisting) to avoid dangerous schemes

XML & API

[x] Avoid XML if possible
[x] Ensure proper access control to the API
[x] Use standard data formats like JSON with proven libraries, and use them correctly.
[ ] Do not forget that you need to correctly escape all output to prevent XSS attacks, that data formats like XML require special consideration, and that protection against Cross-site request forgery (CSRF) is needed in many cases.
[ ] Make sure browsers do not misinterpret your document or allow cross-site loading:
- Ensure your document is well-formed
- Send the correct content type
- Use the X-Content-Type-Options: nosniff header
- For XML, provide a charset and ensure attackers cannot insert arbitrary tags
- For JSON, ensure the top-level data structure is an object and all characters with special meaning in HTML are escaped

Input

[ ] If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted
[ ] The request URL (e.g. in environment variables) is untrusted
[ ] Data coming from HTTP headers is untrusted
- Referer
- X-Forwarded-For
- Cookies
- Server name (!)
[ ] All POST and GET data is untrusted includes non-user-modifiable input fields like select
[ ] All content validation is to be done server side (We should implement $_GET/POST sanitising at the start of EVERY request, before its used anywhere)

CSRF

[x] Include a hidden form field with a random token bound to the user’s session and check this token in the response
[x] Make sure the token is non-predictable and cannot be obtained by the attacker
[ ] Referer checks are not secure, but can be used as an additional measure

ClickJacking/Everything in general

[ ] For applications with high security requirements where you expect users to use outdated browsers with JavaScript disabled, consider requiring users of older browsers to enable JavaScript

Data Transfer

[ ] Use SSL/TLS (https) for any and all data transfer
[ ] Do not start communicating via http, only redirecting to https when “needed”
[ ] Mark cookies with the “secure” attribute, http://us3.php.net/manual/en/function.session-set-cookie-params.php
[ ] Use the Strict-Transport-Security header where possible
[ ] Educate users to visit the https:// URL directly (or just force it)
[ ] If your web application performs HTTPS requests, make sure it verifies the certificate and host name

Session

[ ] Regenerate (change) the session ID as soon as the user logs in (destroying the old session)
[ ] Prevent the attacker from making the user use his session by accepting session IDs only from cookies, not from GET or POST parameters (PHP: php.ini setting “session.use_only_cookies”)
[ ] Set the “HttpOnly” attribute for session cookies
[ ] Generate random session IDs with secure randomness and sufficient length
[ ] Do not leak session IDs

Truncation/Trimming Attacks

[ ] Avoid truncating input. Treat overlong input as an error instead.
[ ] Introduce length checks

Passwords

[x] Use per-user salts
[ ] Limit login attempts per IP
[ ] Enforce reasonable password policies

Comparison

[ ] When in doubt use a strict comparison

adam-buckley commented 10 years ago

Here is also a PHP security cheat sheet from OWASP: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet Which also tells us how to fix most of the problems

adam-buckley commented 10 years ago

Have now added per user salting as per the security requirements (commit: 3ca6065) There is a DB Update, also you will need to reset your password using the forgot feature

adam-buckley commented 10 years ago

Firebug was kind enough to let me know that logging into cmfive is very unsecure, we should really look at introducing a SSL feature, like give users an option to add a proper certificate or have the server self sign one: screen shot 2014-01-15 at 10 33 05 am

careck commented 10 years ago

This is platform depended. Whoever installs a cmfive app is responsible to secure it behind SSL.

On Wednesday, January 15, 2014, adam-buckley wrote:

Firebug was kind enough to let me know that logging into cmfive is very unsecure, we should really look at introducing a SSL feature, like give users an option to add a proper certificate or have the server self sign one: [image: screen shot 2014-01-15 at 10 33 05 am]https://f.cloud.github.com/assets/1585392/1916225/5c79ef2c-7d74-11e3-812f-1bb4293801ec.png

— Reply to this email directly or view it on GitHubhttps://github.com/careck/cmfive/issues/15#issuecomment-32320050 .

Kind regards,

Carsten Eckelmann tripleAcs expert cloud solutions

Mobile 0458 79 55 44 carsten@tripleacs.com www.tripleacs.com

careck commented 9 years ago

many of those security checklist items are concerning the server setup and configuration of the PHP environment ... not strictly the problem of the framework.

2pisoftware / cmfive

Security Checklist #15