- Issue created by @larowlan
This was originally reported as a security issue but was cleared by the security team to be fixed in public
For automatic updates, the client-side code was audited by Cure53. Their one identified vulnerability is:
DRU-01-010 WP1: Batch set processing triggerable via CSRF (Low)
Cure53 determined that the Drupal core batch set processor can be triggered by a Cross-Site Request Forgery (CSRF) attack through knowledge of the batch ID. Several actions from the Drupal core and Automatic Updates module are split into operations that are handled in a batch set, which is processed after initiating the batch. Once the batch has been started by an authenticated administrator, they could be lured onto an attacker-controlled web page that can send authenticated HTTP requests or forward the user to the batch endpoints. This activity will trigger the execution of the current batch queue items or the completed callback in an unsynchronized manner.
The following HTML markup could be served from an attacker-controlled domain, which will cause the execution of the current batch item within the batch set (ID 15) on the virtual.world domain.
Sample CSRF web page:
<script>location.href="http://virtual.world/batch?id=15&op=start";</script>
To mitigate this issue, Cure53 recommends enforcing the requirement of a valid CSRF token before performing any batch set operations. By doing so, it is assured that only the JavaScript of the user interface holding the CSRF token can perform those actions.
Additionally, it is advisable to require that the execution of batch items is synchronized to only allow the execution of a single batch operation simultaneously. Lastly, one could ensure that the finishing callback can only be executed once all operations have been completed.
Active
11.0 🔥
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
