When considering a Magento upgrade one of the most important things you should discuss with the person who might do the upgrade is whether the changes you think the upgrade will make are actually going to happen. We often have people come to us for upgrades of Magento or other web software who are expecting that it will fix a problem they are having, but in most cases the upgrade won’t have any impact (in many cases fixing the problem requires much less work that an upgrade would entail). Along similar lines we have had an increasing number of people coming to us asking about Magento upgrades who it turns out are actually interested in making their website responsive; that is making the website work well across desktops, tablets, and smartphones.
Upgrading Magento will not make a website responsive. The confusion surrounding this seems like it might be largely due to how Magento 1.9 was promoted by its developers. The blog post announcing that version is titled “Magento Enables Responsive Sites in Half the Time” and the clearest mention of what that actually means in the post isn’t all that clear. It states that a “new responsive design reference theme that makes it possible to quickly get a tablet and smart phone-friendly site”, what isn’t necessarily clear for someone who doesn’t deal with the more technical side of Magento is that all that means that Magento now comes with a new theme that is responsive. The new theme doesn’t have any impact on the existing theme you have, so you would have to switch to new theme to make the website responsive. With that you lose the current look of the website and would have to customize the default theme.
Since responsiveness comes from the theme and not from using a newer version of Magento, if you are looking to make your Magento website responsive you would want to replace your current theme with one that is responsive. You could customize the new default responsive theme that comes with Magento 1.9 & up, or you could use another responsive theme created by someone else as well. Depending on if the new theme is compatible with your Magento version you may or may not need to upgrade Magento as well.
A couple of weeks ago we discussed our opinion that Automattic, the company closely associated with WordPress, should bear some of the responsibility for improving the security of WordPress plugins. That came up after we bumped in to their use of WordPress plugins for the WordPress.com VIP service, while trying track down the developer of a plugin to let them know of a security issue. It was only days later that we came across a closer connection between Automattic and the poor security of WordPress plugin.
As part of our efforts to improve the security of WordPress plugins we have created the Plugin Vulnerabilities plugin that alerts when the currently installed version of plugins have known security vulnerabilities (as well as listing vulnerabilities that existed in installed plugins). When we add vulnerabilities to the dataset for that plugin we verify that vulnerability exists and what versions it existed in, in some instances we have found that vulnerabilities that discoverer of the vulnerability and or the developer of the plugin claim have been fixed have not actually been fixed. That is the case with two reflective cross-site scripting (XSS) vulnerabilities recently identified in the Pods plugin. While the report says that the vulnerabilities were fixed in version 2.5, we found that they still existed in that version. While looking for a way to contact the developers to let them know that issue existed and had been publicly disclosed, we noticed that footer of the website prominently displays that the project is sponsored by Automattic:
According to their About page, Automattic has been sponsoring development since 2012.
After a little more digging we were able to find Pods recommend method for reporting a security issue. While we got a quick response it didn’t seem like they really understood things. In our initial contact we recommended they use Firefox when confirming the vulnerabilities still exist, due to XSS filtering in other major web browsers that would protect against the example exploits of the vulnerabilities that were provided in the advisory (the XSS filtering would not necessarily protect against more advanced exploits). In response they asked how they could confirm them in Chrome for some reason. A week later two new version, 2.5.1 and 220.127.116.11, were released that based on the changelog fixed a number of bugs, but did not fix the security vulnerabilities that have been publicly available since January 12. As of today the vulnerabilities still exist in the plugin.
In reviewing the other vulnerabilities that were included in that report another thing stuck out to us, the security of Pods has actually gotten worse over time. One of the other vulnerabilities could have lead to all the of Pods data being deleted from a website if a malicious actor could get a logged in admin to visit a specified page through a cross site request forgery (CSRF) vulnerability. That vulnerability existed back to version 2.0, but as of at least the last version of 1.x series the reset function was protected from this type of vulnerability with a nonce.
So the big panic in the past week or so has been about this GHOST vulnerability in glibc which under certain circumstances can allow remote code execution (serious business!). So we’ve had Heartbleed, POODLE and Shellshock and now we have awfully cute GHOST. What is it? The CVE for GHOST is – CVE-2015-0235, the technical [...]
Read the full post at darknet.org.uk