pfSense

It seems like in addition to fixing ACB, it would be good to sanitize notices as you suggest. A sanitiize_text() function might be useful elsewhere and could simple zap strings such as script, onload, onclick, onchange etc.

ACB is good now. But head.inc probably should sanitize $id and $notice unconditionally. Any reason we couldn't always run those two through htmlspecialchars? I don't see anything using links within $notice, and even if they are that's probably not a great idea. That'd prevent notices from breaking the GUI in addition to security benefits.

Changing ACB directly was the quickest way to get a fix for everyone without updating pfSense itself, but looking through the source at uses of file_notice in deeper detail, doing it for all notices may be fine. Initially I thought I saw some place that relied on using HTML inside the message, forming a link or similar, but it looks like maybe all of that has shifted to using the $url parameter when filing a notice.

So we could probably do with an htmlspecialchars() on $notice['notice'] at source:src/usr/local/www/head.inc#L671 and for ACB on RELENG_2_3 we could revert or change the htmlspecialchars() it does to avoid having it done twice.

As for id, as long as htmlspecialchars() is run only on $notice['id'] at source:src/usr/local/www/head.inc#L668 that should be fine.

I suppose it could also be done for both in source:src/etc/inc/notices.inc#L93 and source:src/etc/inc/notices.inc#L94 as well when filing the notice rather than on display.

I'd rather store it safely, as there's less chance it'll become a security issue in our code, or outside of it where people are shipping notices elsewhere. For instance, discussed here.
https://thehackerblog.com/poisoning-the-well-compromising-godaddy-customer-support-with-blind-xss/

Pushed change to run all 5 through htmlentities before storing. That doesn't appear to hurt any current usage of notices.