Code Reuse Good, SQL-Injection Reuse Bad

One of the most common practices insoftware development is code reuse. Developers use the strategy to savetime and money by reducing redundant tasks and the theory is put intopractice in several popular content management systems available tousers who want to create their own Web presence.

The CMS, or content management system, is a framework that can beused by both experienced and novice developers to produce Web sites forcountless purpose. From blog sites (like this one) to e-commerce sites,for Fortune 500 companies to private individuals, a CMS can makedeveloping content for the Web a whole lot easier.

Many of the popular CMS varieties employ a modular approach thatmakes it easy to construct your own add-ons to suit any purpose you'dlike - searching, FAQ building, file uploading, news posting - the listis exhaustive. In fact, the odds are good that someone else has alreadymade the add-on you seek: they figured out code reuse.

Joomla! and Mambo are two common CMS frameworks. They are opensource, freely available, and have large communities of users. Theyhave hundreds of third party add-ons (called components) available tohelp developers add features easily to their sites. Even if you can'tfind a ready-made third-party component that does exactly what youwant, it's easy to copy the code from a similar component and customizeit as your needs require. This is code reuse at its best!

Unfortunately, vulnerabilities are reused as well. Symantec haspublished nearly 30 SQL-injection vulnerabilities over the past coupleof weeks, discovered by S@BUN and other researchers, for an assortmentof Joomla! and Mambo third-party components. The issues are eerilysimilar: they have a common parameter, typically some sort of key fieldin the underlying database, that is not sanitized before being used inan SQL query. The parameter name is often something like 'gid', 'id','filecatid', or 'listid'. For example, these BIDs 27551, 27558, and 27695illustrate vulnerable 'id' parameters for three Joomla! components thatprovide very different functionality, but seem to have the sameinherent lack of sanity-checks. Attackers can exploit SQL-injectionissues like these to compromise the application, access or modify datain the database, or corrupt the database itself. Based on thesimilarities of these issues, its a good guess that developers reusedcode from an existing component and didn't fully understand thesecurity hazards of doing so.