View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1682 | Composr | core | public | 2014-08-28 09:44 | 2014-10-10 21:35 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1682: Kid Gloves developer-mode | ||||
| Description | Developers often don't understand variable escaping, even so called "professionals". All the bundled Composr code is carefully written to use proper techniques to convert data between different layers - for example, escaping into SQL statements, or HTML entity encoding within templates. We want to continue to have Composr written in a logical and correct way, and already have some developer safeguards to check for errors - but those safeguards typically only run in "debug mode" or with the ocProducts version of PHP. I like how we currently do it because the framework never does anything weird, it is all correct and logical, so long as you code in a correct and logical way - the code flows smoothly. I propose that any code in a *_custom directory run with extra run-time protections, unless the developer declares (self-certifies) they understand the technologies involved fully. These protections will have some consequences on correctness - for example you may see "amp" in output if stuff ends up being double escaped, or code might run very slightly slower. That's better than security holes though. Protections would include: - Our SQL safeness scanner would run, even when not in debug mode. This scanner looks to see if strings are present within SQL that were not escaped and not part of the original SQL code (it uses active code scanning to do this, comparing written code to run-time results). - All strings passed into do_template or do_lang_tempcode would be auto-escaped, if that string value had not already been marked as an output of escape_html - For a mini-block/mini-module, any string values in the GET/POST present in the output would be substituted in the output by the escaped values - Any "../" or "..\" in any input parameter results in a hack-attack call (no need to call filter_naughty first like you normally need to do) These protections would be enabled based on analysing call-context (i.e. detecting *_custom callers) and by looking at the developer declarations. The protections are imperfect. They cannot catch all cases, only the most obvious and common ones that might be targeted. However at the least they also raise an awareness of security at the API level. Some other cases are already protected for within the Composr API and already need explicit disabling of safeguards to be bypassed. To make a declaration, you'd run some code such as... i_solemnly_declare(I_UNDERSTAND_SQL_INJECTION | I_UNDERSTAND_XSS | I_UNDERSTAND_PATH_INJECTION); The ocProducts addons would want upgrading to make these declarations. Whenever a new module/block is launched, any existing declarations would be wiped. The Code Book would need to be updated to explain how to use 'i_solemnly_declare'. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 8 | ||||
| Sponsorship open | |||||
