Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRM-20926 - Allow extensions to flag PHPIDS html/json fields #10709

Merged
merged 9 commits into from
Aug 4, 2017

Conversation

totten
Copy link
Member

@totten totten commented Jul 20, 2017

Background

PHPIDS scans all HTTP inputs and applies heuristics to identify malicious
submissions. It relies on a having configuration about the list of fields
we'll process.

NOTE: This PR includes/depends on #10708.

Before

The function createConfigFile() produces the standard configuration as an
INI file. The configuration was represented as an unalterable string.

After

  • The configuration is represented as an array.
  • The configuration is generated via createStandardConfig()
  • The configuration file is no longer used.

Acceptance Criteria

  • PHPIDS still protects most page-requests.
  • The pre-existing PHPIDS policies still apply.
  • Individual inputs for individual pages – such as the civicase_reload involved with CRM-20924 – can be flagged as html, json, or other exceptions to the PHPIDS heuristics.

@totten
Copy link
Member Author

totten commented Jul 20, 2017

jenkins, test this please

@seancolsen
Copy link
Contributor

seancolsen commented Jul 21, 2017

"Allow extensions to..." — This caught my eye. Would it be possible to add some documentation to the Developer Guide to go along with this PR so that extensions developers can learn how to do whatever it is that this PR would allow them to do?

@totten
Copy link
Member Author

totten commented Jul 25, 2017

@seanmadsen This should be ready for you to give a whirl. I've posted some docs in civicrm/civicrm-dev-docs#227 along with an example of triggering the IDS in https://gist.github.com/totten/27cc1bde206fe17371c8a6d7cb361e49

@totten
Copy link
Member Author

totten commented Aug 1, 2017

@seanmadsen Updates following our discussion

  • Rebased PR and resolved conflicts
  • Fixed the issue where "exception" and "exceptions" get confused. Updated the docs PR accordingly
  • Fixed the undefined index
  • Improved test coverage
  • Tested which policies (exceptions, html, json) accept the example data from https://gist.github.com/totten/27cc1bde206fe17371c8a6d7cb361e49 -- these are the results:
    • This allows the scary data: $items['civicrm/admin']['ids_arguments']['exceptions'][] = 'foo';
    • This rejects the scary data: $items['civicrm/admin']['ids_arguments']['html'][] = 'foo';
    • This rejects the scary data: $items['civicrm/admin']['ids_arguments']['json'][] = 'foo';

(The commit#'s have all changed following rebase, but the only new thing is 615e575.)

@seancolsen
Copy link
Contributor

I've reviewed this PR by looking over the code and running it locally.

  • ✅ It's a worthy pursuit
  • ✅ It's documented
  • ✅ It includes tests for new functionality
  • ✅ Overall, it behaves as advertised
  • ✅ Acceptance criteria is met
    • ✅ PHPIDS still protects most page-requests.
    • ✅ The pre-existing PHPIDS policies still apply.
    • ✅ Individual inputs for individual pages can be flagged as html, json, or other exceptions to the PHPIDS heuristics.

Good to go!

 * This function does not appear to be called anywhere in `universe`.
 * It references the table/DAO for `civicrm_menu`, which seems like a bad idea.
 * This function goes back v3.0 (when the navbar and router were decoupled) -- but even then, it wasn't used!
   I'm guessing it was an interim and forgotten artifact written while decoupling navbar and router.
@totten
Copy link
Member Author

totten commented Aug 4, 2017

Thank you @seanmadsen!

It was really helpful how your review involved trying it out -- that step found the exception/exceptions bug which (a) wasn't visible in my original test scenario and (b) would have been very hard to spot from just reading the code. Nice.

I'll rebase to resolve the recent conflict and move the upgrade logic to match the new version#. Then it should be merge-on-pass.

Background
==========

We need a place to store per-page information about IDS configuration.

More generally, as we continue adding features through extensions, we should
anticipate that the route metadata will expand in ways that we can't
anticipate.  Adding a general-purpose serialized field will help us define
new behaviors through extensions.

Before
======

All metadata in the routing table (`civicrm_menu`) had to stored in a
separate SQL column.

After
=====

Any unrecognized fields will be stored and loaded from the column
`module_data`.
Background
==========

PHPIDS scans all inputs and uses heuristic checks to identify malicious
content.  It relies on a configuration with data about the fields we'll
process.

Before
======

The function `createConfigFile()` produces the standard configuration as an
INI file.  The configuration was represented as an unalterable string.

After
=====

 * The configuration is represented as an array.
 * The configuration is generated via `createStandardConfig()`
 * The function `createConfigFile()` only handles file I/O.
Background
==========

Previously, the IDS configuration was written to a temp file and then read from the tempfile.

Since we no longer read the tempfile, we don't need to write to it either.

Before
======

System autocreates the `Config.IDS.ini` file.

After
=====

System does not create `Config.IDS.ini`.
The PHPIDS config format uses the property:

```
exceptions => array('field_1)`
```

But our XML format uses the tag:

```
<exception>field_1</exception>
```

Grammatically, those both make sense. But they were getting confused.

This modifies the XML parser to map the tags `<exception>` to property
`exceptions`, and it updates the unit-test to ensure that the data
(from the route and the default config) are correctly merged.
@seamuslee001
Copy link
Contributor

@totten tests have passed

@totten totten merged commit 8e61538 into civicrm:master Aug 4, 2017
@totten totten deleted the master-ids-cleanbreak branch August 4, 2017 01:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants