Bug #8726
closed
Lack of input validation on custom GUI/dashboard settings leads to potential XSS
Added by Jim Pingle about 6 years ago.
Updated 11 months ago.
Affected Architecture:
All
Description
There are a few fields that customize the dashboard and GUI that can be set globally on system.php or per-user on system_usermanager.php or system_user_settings.php. Of these, some allow configurable user input, including: webguicss
, webguifixedmenu
, webguihostnamemenu
, and dashboardcolumns
.
These fields rely on basic JS/select lists to enforce their values, which can be easily bypassed by a malicious client.
dashboardcolumns
and likely the others can have a string inserted which can lead to a potential stored XSS.
These fields need to be validated on submission, and at least dashboardcolumns
needs to be sanitized before display.
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
Tested the above inputs webguicss, webguifixedmenu, webguihostnamemenu, and dashboardcolumns. and was not able to use any string that wasn't specified.
I'm not sure if this qualifies but I was able to insert my own value into the "language" input and have it stored in the config. by simply inspecting the element and editing the html in my browser. I didn't notice any ill effects from this.
[enablesshd] =>
[language] => My own string
[timezone] => Etc/UTC
As long as it doesn't lead to an XSS it should be OK. Try using a typical XSS injection string and then going to a page with a form field to pick the language. I don't think it should cause any ill effect though since that would be a selection list so the value isn't echoed back to the user anywhere.
On 2.4.4.a.20180829.1926, tried a XSS injection example as the dashboardcolumns value in the pfSense config.xml, reloaded the filter to load the modified config, visited System > General and the columns value was blank. Seems to be fixed.
- Status changed from Feedback to Resolved
- Private changed from Yes to No
Also available in: Atom
PDF