When simple sitemap is requested with non-ascii characters in the variant, an exception is generated, which could result in logs getting filled up, denial of service attacks, etc. Such requests should not be routed by simple sitemap.
Currently, the inbound path processor, takes the variant without checking the characters and redirects from {variant}/sitemap.xml to the route /sitemaps/{variant}/sitemap.xml. From there, the variant is compared to configuration to see if it is a defined variant. But the config table stores the config name using the ASCII character set and ascii_general_ci collation, so the comparison statement fails with "Illegal mix of collations"
This could be fixed in either the path processor (ensuring $arg 1 is an ASCII character before altering the path), but I think a much simpler fix is to just add a requirement to the simple_sitemap.sitemap_variant route: variant: '^[\x21-\x2E\x30-\x7E]+$'
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | simple_sitemap_3554196_non_ascii_variant-4.patch | 1.12 KB | dgroene |
| #3 | simple_sitemap-non-ascii-variant-3554196-2.patch | 841 bytes | gbyte |
| #2 | simple_sitemap_3554196_non_ascii_variant.patch | 491 bytes | dgroene |
Comments
Comment #2
dgroene commentedPatch for 4.2.2
Comment #3
gbyteVery good! How did you catch it?
Your solution didn't work for some reason, but I don't mind making the check in the context of loading the variant which would be the path processor (the alternative you suggested). What do you think of the patch?
Comment #4
dgroene commented@gbyte- your version is better and is working for me. I am not sure if you created it against dev, but did not apply for me in 4.2.2, so I am attaching one that applied.
Comment #6
gbyteSeems to be an issue core should be fixing in the long run, see #3475540: Use a route requirement to prevent non-ASCII characters causing an exception when looking up a config entity.
Thanks!