Field instructions are sanitised, erasing code

[arthurperton]

Bug description

In the instructions for a field you can use markdown. When I add a html link in the instructions, it now gets sanitised and some of the (essential) attributes are removed.

I expect the instructions to stay untouched. Is it possible to not sanitise the field instructions, because it is from a safe source?

Introduced in #14006. See the markdown function in resources/js/bootstrap/globals.js‎.

How to reproduce

Add a link to the instructions for a field and add attributes like target and onclick for example:
<a href="/some/page" target="_blank" onclick="doSomeImportantStuff();">link</a>

It will be rendered as:
<a href="/some/page">link</a>

Logs

Environment

Environment
Laravel Version: 11.48.0
PHP Version: 8.3.29
Composer Version: 2.9.3
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: Europe/Amsterdam
Locale: nl

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: null
Cache: file
Database: mysql
Logs: stack / single
Mail: log
Queue: sync
Session: file

Statamic
Stache Watcher: Enabled
Static Caching: Disabled
Version: 5.73.11 PRO

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

[jasonvarga]

I wouldn't have expected target to be scrubbed away. But onclick, yeah. That's opening up an XSS vector.

[arthurperton]

I agree.

The important thing here is that I would not expect counter-XSS measures against content that I provide as a website developer / maintainer. I think typically this sanitation is used on content provided by visitors, .e.g. posts and comments, because that input is not trusted. In my view the instructions we provide for the fields are from a trusted source, but maybe I am overlooking a scenario?

[daun]

We had something like this happen a while ago, where an automated import from a third-party localization platform introduced an XSS vulnerability into the backend using onclick on a link, so basically the exact scenario from above. I think it was an ex-employee who still had access to the localization platform. Switched to manual review and merge right after that :)

As an alternative, you could probably set a data attribute or class name on the link and add the event handler from your custom cp.js. Unless classes are stripped too.

Anyway, keeping target for external http/s origins would be great for external documentation links.

[jasonvarga]

In my view the instructions we provide for the fields are from a trusted source, but maybe I am overlooking a scenario?

That was our view too. But it's not accurate. Someone with permission to edit fields could inject JS to get a super admin to do something.

This is why we can't have nice things.