susom / biocatalyst-link Goto Github PK

Version 0.2 (with code to support #2 ) does not include the crucial introduction of a mechanism for blocking data from being exported from reports if an end user was able to request a report_id that was not on the allowed list returned by getProjectReports().

Is your feature request related to a problem? Please describe.

The module currently permits all reports in a project to be extracted with the Biocatalyst link. This can cause problems in environments where the Biocatalyst platform is permitted to contain less sensitive data than REDCap, where Biocatalyst users in the REDCap environment may have access to projects with reports that could contain sensitive data.

Describe the solution you'd like

Update the module to include an option for administrators to restrict which data reports may be extracted on a per-project basis.

Additional context

We have a strong need to be able to allow only specific reports to be pulled by the module. The UCSF security environment has very strict rules on where PHI can live, and currently REDCap is cleared for PHI, but Biocatalyst will not be. So we need to be able to ship only deid data across the Biocatalyst integration, which has created a requirement that our system admins review each activation of the module. But we still can't restrict which reports a user can pull from a project, so it's very possible for someone to inadvertently pull out an identified report for consumption by Biocatalyst.

Describe the bug

SQL queries called in the following functions are not sanitized to prevent SQL injection attack:

• verifyReportAllowed() (v0.3 and higher)
• getProjectReports() (v0.1 and higher)
• getReportColumns() (v0.1 and higher)
• checkReportInProject() (v0.1 and higher)

Expected behavior

SQL injection protection should be applied to all parameterized queries.

Additional context

From REDCap Framework v4 release notes:

Parameterized Queries - Framework Version 4 requires that all query() method calls must include an additional $parameters argument. All queries should be refactored so that all dynamic values are passed as parameters. Please take a moment to read the Query Documentation page to get a feel for parameterized queries in general, then return here for the following specifics on transitioning modules to use them:

• As of REDCap version v#.#.# (TDB in early 2020), the query() method supports (but does not require) the $parameters argument. This allows module queries to be updated incrementally over time, prior to updating to Framework Version 4.
• Parameters are automatically escaped, which means manual escaping methods like db_escape() and db_real_escape_string() should be removed to avoid double escaping.
• Updating many queries will be as simple as replacing all variables in the SQL with question marks, then specifying those variables in the $parameters argument instead. Cases that require additional handling are included below.
• The db_affected_rows() method will no longer work. See the Query Documentation page for an alternative.
• Methods that begin with mysqli_... and operate on the MySQL result object will no longer work. Please use the equivalent db_... methods instead.
• Numeric column values will return as the int type in PHP where they previously returned as string. This can cause problems for any type sensitive operations like triple equals checking. The simplest solution to prevent potential issues without refactoring is to cast the numeric columns in either SQL or PHP.
  • In PHP you can cast all integer columns to strings manually, or by using the following utility method on each fetched row:
    • $row = $module->convertIntsToStrings($row);
  • In SQL you can cast values individually. For example:
    • Before: select project_id
    • After:   select cast(project_id as char) as project_id.
• Queries using appended SQL strings can still use parameters. For example:
  • Before: $module->query("...where value like '{$value}%'");
  • After:   $module->query("...where value like ?)", [$value . '%']");
• Please don't simply pass in an empty or partial parameter array while still manually appending parameters to your query string. Using prepared statements with parameterized queries is important for security as described by OWASP and security experts spanning many other development communities.
• This may also be a good time replace any old db_query() calls as well. Manually calling db_query() is deprecated in modules, and may be disallowed in the future.