Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.

XSS & SQL Vulnerabilities


Recommended Posts

1. We got alerted to a potential XSS vulnerability in the following scenario.


Solution: cross-site scripting can be fixed by modifying the application's code on the server to HTML-encode user-supplied characters which have special meaning when rendered in a browser. That is, change < to <, > to >, & to &, and " to ". Some web application programming languages contain functions for this purpose, such as htmlspecialchars() in PHP.

Doesn't osC already use htmlspecialchars?

2. On another note, there is also an integer-based SQL injection vulnerability in products_id parameter when the following is used.


We do use Ultimate SEO to rewrite the stock URLs but would that be true of default settings as well?

Solution: all user-supplied parameters should be checked for illegal characters, such as a single quote ('), before being used in an SQL query.

Any insight on addressing the two above issues would be greatly appreciated. These could well be false positives.

Link to comment
Share on other sites

They are almost certainly false positives.  The first one is simple.  Try it.  If it shows the alert, then there is a problem.  Find out where it displays and add the call to htmlspecialchars. 

The second is more difficult, but less likely to be a problem.  Because the software already sanitizes all input before use.  It's barely possible that you have installed something that doesn't (probably not Ultimate SEO URLs).  But certainly core already does that. 

3 hours ago, rule said:

Solution: all user-supplied parameters should be checked for illegal characters, such as a single quote ('), before being used in an SQL query.

This is not the approach that osCommerce takes.  Instead, it sanitizes all parameters before using them in a SQL query.  In the case of a product ID, this would typically happen via a cast to int.  For strings (including the extended product IDs used with attributes), it uses mysqli_real_escape_string and a charset of UTF-8 when communicating with the database.  In general, checking for illegal characters is a bad approach, as it leads to cleverer exploits. 

It is conceivable that you are using an older version that has a bug in it.  You should update to the latest to pick up all the security fixes.  The most recent change was to always use UTF-8, which is required for mysqli_real_escape_string to work consistently (other character sets are also safe but some are unsafe).  Before that was the switch to casting to int and mysqli_real_escape_string (I forget which was more recent--both are really old). 

Always back up before making changes.

Link to comment
Share on other sites

@ecartz Thank you for picking this up.

Below is what NoScript returns when trying to access the URL mentioned in point 1.

NoScript detected a potential Cross-Site Scripting attack
from [...] to http://domain.com.
Suspicious data:
(URL) http://domain.com/advanced_search_result.php?keywords=[removed]alert('SAINT')[removed]

How would you troubleshoot this deeper?

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...