|
|
| Line 1: |
Line 1: |
| I am working on a revision of these guidelines. I am going to hack around on this talk page before copying the result to the main page. | | People seem happy enough with the new format that I have copied it to the main page. |
|
| |
|
| Start of new page contents.
| | I will just leave the [[Security:Template]] link here. |
| -----------
| |
| | |
| This page describes how to write secure Moodle code that is not vulnerable to anything that evil people my try to throw at it.
| |
| | |
| The page is organised around the common types of security vulnerability. For each one, it explains
| |
| # what the danger is,
| |
| # how Moodle is designed to avoid the problem,
| |
| # what you need to do as a Moodle developer to keep your code secure, and
| |
| # what you can do as an administrator, to make your Moodle more secure.
| |
| The explanation of each vulnerability is on a separate page, linked to in the list below.
| |
| | |
| This page also summarises all the key guidelines.
| |
| | |
| | |
| ==Common types of security vulnerability==
| |
| | |
| * [[Security:Unauthenticated access|Unauthenticated access]]
| |
| * [[Security:Unauthorised access|Unauthorised access]]
| |
| * [[Security:Cross-site_request_forgery|Cross-site request forgery]] (XSRF)
| |
| * Cross-site scripting (XSS)
| |
| * SQL injection
| |
| * Command-line injection
| |
| * Data-loss
| |
| * Confidential information leakage
| |
| * Configuration information leakage
| |
| * Session fixation
| |
| * [[Security:Denial of service|Denial of service]]
| |
| * [[Security:Brute-forcing login|Brute-forcing login]]
| |
| * [[Security:Insecure configuration management|Insecure configuration management]]
| |
| * [[Security:Buffer overruns, and other platform weaknesses|Buffer overruns, and other platform weaknesses]]
| |
| * [[Security:Social engineering|Social engineering]]
| |
| | |
| | |
| * [[Security:Template]]
| |
| | |
| ==Summary of the guidelines==
| |
| | |
| ===Authenticate the user===
| |
| | |
| * With very few exceptions, every script should call '''require_login''' or '''require_course_login''' as near the start as possible.
| |
| | |
| | |
| ===Check permissions===
| |
| | |
| * Before allowing the user to see anything or do anything, call to '''has_capability''' or '''require_capability'''.
| |
| * If appropriate, restrict what people can see according to '''groups'''.
| |
| | |
| | |
| ===Don't trust any input from users===
| |
| | |
| * Use '''[[lib/formslib.php|moodleforms]]''' whenever possible.
| |
| * Before performing actions, use '''is_post_with_sesskey''' to check sesskey and that you are handling a POST request.
| |
| ** In Moodle 1.9, use '''data_submitted() && confirm_sesskey()''' instead.
| |
| * Before destroying large amounts of data, add a confirmation step.
| |
| * If not using a moodleform, clean input using '''optional_param''' or '''required_param''' with an appropriate '''PARAM_...''' type.
| |
| ** Do not access $_GET, $_POST or $_REQUEST directly.
| |
| ** Group optional_param and required_param calls together at the top of the script, to make them easy to find.
| |
| | |
| Similarly, clean data from other external resources like RSS feeds before use.
| |
| | |
| | |
| ===Clean and escape data before output===
| |
| | |
| * Use '''s''' or '''p''' to output plain text content.
| |
| * use '''format_string''' to output content with minimal HTML like multi-lang spans (for example, course and activity names).
| |
| * Use '''format_text''' to output all other content.
| |
| ** Only use $options->noclean if it requires a capability with RISK_XSS to input that content (for example web page resources).
| |
| * Before Moodle 2.0, input from optional_param or required_param must have [[Slashes|'''stripslashes''' or '''stripslashes_recursive''']] applied if it is being output directly, rather than being stored in the database.
| |
| | |
| See [[Output functions]] for more details.
| |
| | |
| | |
| ===Escape data before storing it in the database===
| |
| | |
| * Use the XMLDB library. This takes care of most escaping issues for you.
| |
| * When you must use custom SQL code, '''use place-holders''' to insert values into the queries.
| |
| ** Before Moodle 2.0, you have to build SQL be concatenating strings. Take particular care, especially with quoting values, to avoid SQL injection vulnerabilities.
| |
| * Before Moodle 2.0, data loaded from the database must have [[Slashes|'''addslashes''' or '''addslashes_object''']] applied to it before it can be written back to the database. (addslashes should no longer be use anywhere in Moodle 2.0 code.)
| |
| | |
| | |
| ===Escape data before using it in shell commands===
| |
| | |
| * Avoid shell commands if at all possible.
| |
| ** Look to see if there is a PHP library instead.
| |
| * If you can't avoid shell commands, use '''escapeshellcmd''' and '''escapeshellarg'''.
| |
| | |
| | |
| ===Log every request===
| |
| | |
| * Every script should call '''add_to_log'''.
| |
| | |
| | |
| ===Other good practice===
| |
| | |
| ... that helps with security.
| |
| | |
| * Structure your code nicely, minimising the use of global variables. This makes the flow of data, and hence security, easier to verify.
| |
| * Initialise objects ($x = new stdClass;) and arrays ($x = array()) before you first use them.
| |
| * Test every input field with tricky input to ensure that it is escaped and un-escaped the right number of times everywhere, and that Unicode characters are not corrupted. My standard test input is:
| |
| <nowiki>< > & &lt; &gt; &amp; ' \' 碁 \ \\</nowiki>
| |
| | |
| | |
| ==See also==
| |
| | |
| * [[Coding]]
| |
| | |
| CategoryDeveloper
| |
| Category:Security
| |
| | |
| ------
| |
| End of new page contents.
| |
| | |
| Please comment below.
| |
