CAMPLA exam configuration

When a submission to CAMPLA fails, campla_client::sendtocampla() builds an error message that embeds the raw HTTP response body returned by the CAMPLA endpoint ($response->results, via $response->error ?? $response->results). That string is concatenated into the message returned by process_dynamic_submission() and handed to the JavaScript, which passes it to core/toast's add().

The core toast template (core/local/toast/message.mustache) renders the message with a triple-mustache {{{message}}}, i.e. without HTML escaping. The plugin deliberately injects an HTML <br /> into the message, confirming it relies on raw-HTML rendering. As a result, any HTML/JavaScript present in the CAMPLA endpoint's response body is executed in the browser of the manager who triggered the action.

This is a defense-in-depth issue rather than a directly reachable vulnerability: the payload must come from the configured CAMPLA server's HTTP response, and TLS verification is on by default, so an attacker needs to control (or compromise) the configured endpoint, or occupy a network MITM position, to inject the payload. The blast radius is limited to users holding quizaccess/campla:canusecampla (managers/admins).

The CAMPLA application secret is registered as a plain admin_setting_configtext with PARAM_RAW. This means the credential is shown in cleartext in the site administration form (as the manageplugin.feature Behat scenario asserts — the saved secret value is read back verbatim), and there is no masking on screen.

Moodle provides admin_setting_configpasswordunmask (and admin_setting_encryptedpassword) precisely for secrets: they mask the value in the UI and, in the encrypted variant, store it encrypted at rest. Using a plain text field for a shared secret is an avoidable information-exposure/hardening gap.

The CAMPLA base URL is stored as an admin_setting_configtext with PARAM_URL, which accepts both http:// and https://. The plugin never enforces or warns that the scheme must be HTTPS. All requests to CAMPLA carry sensitive material:

• the application secret (in the token request body),
• the Bearer JWT token (in the Authorization header of the examination request), and
• participant personal data — email, first name, last name, full name of every enrolled user — plus the SEB quit password.

If an administrator configures an http:// endpoint, download_file_content() will happily use it and all of the above is transmitted in cleartext.

classes/form/sendtocamplaform.php is an autoloaded class file, yet at file scope it requires config.php, requires filelib.php, and calls require_login(). Moodle's coding standards require class files under classes/ to be free of side effects at include time — they must not bootstrap Moodle (config.php) and must not perform request-level actions such as require_login().

Because the class is autoloaded lazily, require_login() executes whenever the class is first referenced. In the current call paths this happens to be after authentication has already been established (the ajax external function and the dynamic-form handler both call require_login() themselves), so it is redundant. However, running require_login() at autoload time is fragile: if the class is ever autoloaded in a context that has not set up a page (web-service/class discovery, CLI, unit-test bootstrap, etc.), it can trigger unexpected redirects or exceptions.

A related coupling exists in campla_client.php: it calls download_file_content() but does not require filelib.php itself — it silently depends on the form file having loaded filelib.php at file scope. If campla_client::sendtocampla() were ever reached without the form file being loaded first, that call would fatal.

settings_provider::get_campla_quizallowedbrowserexamkey() is named and documented as a read accessor ("Returns the quiz browser exam key"), but when no key exists it writes to another plugin's data: it fabricates a new key, then creates or mutates a quizaccess_seb\seb_quiz_settings record — setting requiresafeexambrowser to USE_SEB_CLIENT_CONFIG, showsebdownloadlink to 0, and the new allowedbrowserexamkeys — and calls save().

This is invoked during campla_client::sendtocampla(). So clicking Send to CAMPLA can silently reconfigure the quiz's Safe Exam Browser access rule (potentially enabling SEB enforcement on a quiz that previously had none), with no explicit user confirmation and no indication that a get performed a persistent write. The persistence uses the SEB persistent API (not raw DDL), and it is behind the manager capability and the dynamic form (sesskey enforced), so it is authorized — but the surprising side effect in a getter is a correctness/maintainability hazard.

campla_client::sendtocampla() is declared with a : array return type, but its guard clause return false; returns a boolean. If that branch were reached, PHP would raise a TypeError. The caller, process_dynamic_submission(), immediately list-destructures the result ([$camplaresponse, $camplamessage] = ...), which also assumes an array.

In practice the guard is effectively dead code: process_dynamic_submission() is only reachable after check_access_for_dynamic_submission() passes the capability check, and campla_client::init() sets self::$caps['canusecampla'] from the same capability, so it will be truthy; $formdata from get_data() will also be non-empty. Nonetheless the type contract is violated and the guard cannot actually signal failure the way the caller expects.

sendtocamplaform::handle_jwttoken_request() performs a hand-rolled host check before contacting CAMPLA. Two problems:

• After computing $parts = parse_url($url) and setting $hostvalid = false when $parts is falsy or $parts['host'] is empty, the code unconditionally reads $host = $parts['host'];. If $parts is false or lacks a host, this raises an undefined array key / array offset on bool warning and yields null, which is then passed to dns_get_record(null, ...) (a deprecation/TypeError risk on modern PHP).
• The dns_get_record() gate adds no security value here — the URL is admin-configured, so there is no SSRF to prevent — while making the flow brittle (transient DNS failures cause a spurious "No valid CAMPLA URL" error).

This method is reachable via the ajax external function by a manager even when the base URL is empty/invalid (the external function checks the capability but not is_campla_config_valid()), so the degenerate $url = '/rest/auth/application/' path is actually reachable.

The modalForm export defines its args parameter with a default value that references args inside its own initializer: args = {...args, hidebuttons: args.hidebuttons ?? 1}. A parameter's default expression cannot read the parameter being initialized (it is in the temporal dead zone), so if modalForm were ever called with fewer than four arguments, this would throw a ReferenceError at call time. The compiled amd/build/modalforms.min.js reproduces the same broken pattern.

In practice this is currently unreachable: the only caller is rule.php, which always passes the fourth argument (['hidebuttons' => 1, 'cmid' => $cmid]) via js_call_amd, so the default never executes. It remains latent, dead-but-wrong code.