Never Explicitly Trust Software Because It Is Open-Source

One of the major ideas behind open source projects is that allowing anyone that wants to view the source code of a project to be able to do so should make bugs and security weaknesses easy to find. While this did not work so well with OpenSSL and its various bugs that have been exposed recently, I do have an example where it worked extremely well.

Magento is an eCommerce platform that has two separate editions. One is a completely open-source and free as in beer Community edition. The other is a somewhat expensive Enterprise Edition. There is a large community of Magento developers that create extentions, or addons, for these two editions of Magento.

One of these “Magento developers” is a company whose products I’d never use. They create some CMS addon for Magento that has an evil feature. Many current extensions “phone home” to the main developer’s servers to tell them what sites are using their extensions among other various bits of information. What makes this “open source” extension’s “phoning home” so insidious is that part of the information it sends to its developer’s servers is the private encryption key that the Magento installation uses to encrypt passwords for users among other things.

That’s right, an open-source Magento extension is collecting private encryption keys and sending them to the extension developer.

While the “developer” of this extension claims this was all to track unauthorized usage of their extension, the response should not make you feel any better about their bad software. If you look at the Magento Stack Exchange profile of the supposed “developer”, there is no contact information listed or even a website for the extension. If you dig a bit deeper and look at the developer’s website, you will be unable to find any way to contact the developer other than the contact form on the website. This developer does not even give you a hint as to what country they are based in, other than the fact that they are processing payments in Euro. To top it all off, the developer also does not disclose any contact information in the registration of their domain. They seem quite private and secretive for a company that creates open-source extensions for Magento.

The thing to take from this is that before using any software, including open source software, you should weigh the security risks that the software poses and address them appropriately. In the case of Magento extensions like this one that has the potential to expose customer data, potentially even credit card information, you should have a trusted developer review the entire codebase of any third-party extensions you wish to install on your site.

To prevent security breaches, an ounce of prevention is worth a pound of a cure.

Tags:

Related Posts

Apr 18, 2014
2 minutes

Magento Adminhtml and Relative Links to Static Resources

Relative links in URLs allow you to only specify the path to an resource that is in the same or subfolder of the current folder. Lets say the current page you are on is http://example.com/test/ and you want to reference an image at http://example.com/test/image.jpg. You could put the full http://example.com/test/image.jpg in the src attribute of the img tag, or you could use just image.jpg instead. This works well when you are not sure what the directory path is the parent directory of your code. However, it can cause some issues when your code is moved to another location, but some resources are not moved, such as image.jpg.

#magento #html
Read More
Jul 10, 2014
One minute

Ignore Whitespace Not Available in BitBucket Pull Requests

When looking for an online location to use as the host for source code, many people by default look at GitHub, as it seems to be the most well-known option out there, and is free for open source projects. However, if you would like your source code to be kept private, or would rather use Mercurial instead of Git, GitHub may not be the place for you. Instead, I would suggest BitBucket as your source code repository provider.

#rant #web-development
Read More
Jan 8, 2015
3 minutes

Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.

#jquery #javascript #web-development
Read More