Opened this issue because there is not a security advisory or a response from the repo maintainers after sending a report by email.
The POC described here used the docker continuous deployment instance (https://ci.simplcommerce.com).
An user with the name <script>alert(1)</script> is registered and stored to the database. This payload appears to not be triggered while browsing through the site but when admin needs to remove this user, the payload is executed.
Below is shown an example where to trigger our malicious payload at https://ci.simplcommerce.com/admin#!/users.
We can see the registered user and the payload in the full name field. Nothing anormal happens when loading the page. But when trying to remove the user and after clicking the remove button the script of the malicious payload is executed and the alert box appears.
This behavior confirms the XSS vulnerability. It requires to click the remove button, but as soon as is clicked, the exploit is executed.
Looking to the inspector from the dev tools, we can see the injected script in the Bootbox modal body.
At line 27, the value of user.fullName field is added directly to the bootbox modal without proper sanitization making it vulnerable to XSS.
Also, at line 33 a toast is launched when we confirm deleting the user and again user.fullName is added to the toast. The same payload can be triggered twice if we follow this use case.
Opened this issue because there is not a security advisory or a response from the repo maintainers after sending a report by email.
The POC described here used the docker continuous deployment instance (https://ci.simplcommerce.com).
POC
The following POC is just an example of many others that are prone to DOM XSS. To better understand and see a more detailed explanation of what is, please see the following link: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)
Using the user register page and the input is the Full Name field at the register page (https://ci.simplcommerce.com/register).
An user with the name <script>alert(1)</script> is registered and stored to the database. This payload appears to not be triggered while browsing through the site but when admin needs to remove this user, the payload is executed.
Below is shown an example where to trigger our malicious payload at https://ci.simplcommerce.com/admin#!/users.
We can see the registered user and the payload in the full name field. Nothing anormal happens when loading the page. But when trying to remove the user and after clicking the remove button the script of the malicious payload is executed and the alert box appears.
This behavior confirms the XSS vulnerability. It requires to click the remove button, but as soon as is clicked, the exploit is executed.
Looking to the inspector from the dev tools, we can see the injected script in the Bootbox modal body.
In the SimplCommerce code, this happens in the following line of code at https://github.com/simplcommerce/SimplCommerce/blob/master/src/Modules/SimplCommerce.Module.Core/wwwroot/admin/user/user-list.html#L65
When clicked the delete button, the function vm.user(delete) is executed. If we look for the user-list.js file (https://github.com/simplcommerce/SimplCommerce/blob/master/src/Modules/SimplCommerce.Module.Core/wwwroot/admin/user/user-list.js) we can see of the function is doing.
At line 27, the value of user.fullName field is added directly to the bootbox modal without proper sanitization making it vulnerable to XSS.
Also, at line 33 a toast is launched when we confirm deleting the user and again user.fullName is added to the toast. The same payload can be triggered twice if we follow this use case.
Fixing the vulnerability
As the bootbox.js maintainer does not fix the XSS vulnerability, to protect the users of SimplCommerce from being attacked is recommended to sanitize input before adding it to any bootbox modal or dialog. The following link explains the approach to validate user data https://docs.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-3.1#where-should-encoding-take-place.
The next functions are just suggestions to validate input data. Upon your goals, you can choose the one(s) that best fit to your project:
HttpUtility.HtmlEncode - https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netcore-3.1
WebUtility.HtmlEncode - https://docs.microsoft.com/en-us/dotnet/api/system.net.webutility.htmlencode?view=netcore-3.1
The text was updated successfully, but these errors were encountered: