The Pros and Cons of using Plug-ins and External Code Libraries
When you install a plug-in, theme, or module into your web application, you are in effect allowing additional, custom code to be placed in (or run from) your web site.
In a perfect world, this additional code is safe and does what it says it does – but there is always a risk that the plug-in/module is malware of some kind – either purposely (a malicious author wrote the code in order to inject spam or malware into sites the plugin is installed on) or not purposely (such as if the repository where this code is stored gets compromised).
Many plug-ins use code from common sources or repositories. For example, if you are familiar with Javascript, you may be familiar with jQuery. As an alternative to hosting the jQuery file on your web server, you (or your plug-in) may be using code that simply includes this file by referencing a remote location of the file.
This is not necessarily a bad thing – if you (or your plug-in) are sourcing jQuery from a large, public CDN (content delivery network) such as Google, your site would benefit in the following ways:
- Caching – Many web sites serve jQuery from Google’s library. Since jQuery is used on many web sites there is a good chance that most users who visit your web site already have a copy of the jQuery file in their browser cache. This means that the file doesn’t even have to get downloaded to their browser, speeding up the performance of your web page.
- Latency – Content delivery networks are normally distributed in multiple physical locations, so for users who don’t already have the particular jQuery file in their cache this would get delivered to their browser from the closest physical server, increasing the download performance for this file.
- Concurrent Connections – most browsers limit the number of concurrent connections to a particular hostname. When a user is accessing your web page, their browser needs to make multiple connections to your site (one connection for each element – each image, script, css file, and the page itself requires a connection). Some web browsers are configured for a maximum of 2 connections at a time per hostname, which means only two elements can be downloaded at a time. If you are calling in elements from a different hostname, the browser will allow the additional connection(s) which is one reason why calling jQuery from an external source makes sense. The newer browsers are starting to allow as many as 6-8 connections at a time per hostname, but considering how many elements are on a page it still helps to pull content in from other hostnames.
So using a remote script can be a good thing – however, there have been cases of 3rd party web site plug-ins and modules (such as WordPress plug-ins) uploaded to WordPress.org that are calling in malicious or infected code.
In some cases the plug-in or theme is and purposely malicious – and in other cases the plug-in may be referencing code or content from a location that has been compromised.
There have also been cases where large advertising networks contained tainted ads (such as flash ads that contained malware) or where the ads linked to shady sites that distributed malware.
In regards to WordPress, they do remove plugins and themes from their directory that are found to be malicious, but it can take time for this to happen, and those who already installed the plug-in may not realize that they have a problem in their web site.
This can occur with any web application that uses plug-ins, themes, or modules, or any code that calls in external content – not only WordPress. WordPress is exploited quite often however as it is an extremely popular application used on over 73 million web sites – so attackers take advantage of this popularity. Even a small number of users install the bad plug-ins can amount to thousands of infected sites.
A good example is a recent occurrence of WordPress sites that were found to have hidden spam links. The spam is hidden from the user’s view but its purpose in the site code is to be picked up by search engines.
Security firm Securi recently posted an article that discusses a particular compromise relating to links going back to the domain wpstats.org. In this particular case the code is calling a jquery file located on a domain called wpstats.org which contains the spam links.
If you notice hidden spam links or other unwanted code on your WordPress site, the best thing to do first to narrow down the issue is to de-activate all plugins and then activate one plug-in at a time to find the offending one.
In some cases, the plug-in may be a good, valid plug-in but the source of the jQuery file that the author choose to link to has been compromised. If this is the only issue with the plug-in then you can fix this yourself by replacing the link to the jQuery file to Google’s hosted jQuery file. Google also hosts other libraries which are available at https://developers.google.com/speed/libraries/devguide
In summary, always be aware of the external sources that your site uses for content – whether that be plus-ins, code libraries, or even advertising networks, and should an issue arise on your site this could be the source of the problem, in additional to the usual suspects such as cross-site-scripting and SQL injection.
References:
Securi Blog post on wpstats.org spam and fake plug-ins:
http://blog.sucuri.net/2012/05/wpstats-org-spam-and-a-fake-advanced-search-plugin.html
Google Libraries API – Developer’s Guide
https://developers.google.com/speed/libraries/devguide
Roundup on Parallel Connections
http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/
