MediumGHSA-5f5v-5c3v-gw5v

Silverstripe IE requests not properly behaving with rewritehashlinks

Published 23 May 2024 · Updated 28 Nov 2024

Affected packages

silverstripe/frameworkComposer
Affected
<3.0.13
Fixed in
3.0.13
Update to the fixed version for your release line, for example:composer require silverstripe/framework:^3.0.13
silverstripe/frameworkComposer
Affected
>=3.1.0 <3.1.12
Fixed in
3.1.12
Update to the fixed version for your release line, for example:composer require silverstripe/framework:^3.1.12

Details

Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure

Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $_SERVER[‘REQUEST_URI’]

Example IE8 request 127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200

Example FF request 127.0.0.1 - - [18/Jun/2014:14:14:22 +1000] “GET /site/cars/brands/toyota?one=1\%22onmouseover=\%22alert(%27things%27);\%22 HTTP/1.1” 200

This causes any hash anchor to have the JS code inserted into the page as-is.

Is GHSA-5f5v-5c3v-gw5v in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected silverstripe/framework, and gives you the command that fixes it.

Scan a project free, no signupOr connect GitHub to scan every repo

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.