The recently released SUPEE-10415 patch introduced some changes relating to validation of the log file paths before writing to them (APPSEC-1913). There is one side affect of these changes that I’ve not seen anybody talking about so I thought I’d write this post. The consequence I’m refering to is caused by this change, in Mage.php:
With the release of SUPEE-9767 there seems a lot of confusion around APPSEC-1281 and how and/or why symlinks are dangerous or being exploited. I’m going to try and add some clarification (or you know, muddy the waters even more if I’m wrong). What’s the Exploit As far as I’m aware, symlinks in themselves are not
Since everyone else in the Magento community seems to be blogging about their experiences at Magento Imagine, I decided I should probably break my dry spell (of posting updates, don’t worry, I haven’t stopped drinking) and do the same. After all, just like the next man, I don’t like missing out on any passing fad.
Over the last few years, Magento has gradually increased protection against CSRF attacks. The most common defence against such attacks is to require a form key (a randomly generated string, unique to the session) to be submitted with all actions that perform update/insert commands on the server. In version 126.96.36.199 this protection was implemented for
After seeing a bunch of ‘year in review’ articles last year. I decided I’d take a crack at it myself this year. Since I don’t blog that much I figured I’d expand it to include some of the other activities I got up to last year.
For those of you that don’t know, the Magento routeing system is largely based on classes provided by Zend Framework 1. Whilst browsing through the code I came across something interesting in the method Zend_Controller_Request_Http::setRequestUri. What was interesting to me, was that it prioritises two headers (HTTP_X_ORIGINAL_URL and HTTP_X_REWRITE_URL) over REQUEST_URI. Why is that interesting?
With the recent simultaneous release of both Magento 188.8.131.52 and SUPEE-8788, I decided to take some time and review the differences between an upgrade to 184.108.40.206 and patching an existing 220.127.116.11 installation. I did a similar thing when SUPEE-7405 came out alongside 18.104.22.168 and found that the differences were minimal. In this instance, however, the
I recently spent some time investigating some strange, seemingly random issues with caches not being cleared when expected. This behaviour could not be replicated locally in my vagrant based development environment. The Magento site in question was running on multiple servers and using Redis as the caching mechanism. Whilst the development environment also used Redis,
I recently became aware of a vulnerability that appears to be present in a relatively high percentage of Magento stores, including stores that have applied all security patches released by Magento. The vulnerability is caused by 3 flash files being compiled with a vulnerable version of flex, the underlying issue with flex was assigned the
A recent update to composer added a configuration option secure-http, which is defaulted to true. As the name suggest the setting relates to https. More specifically it errors if you attempt to pull in a dependency over the http protocol. Importantly, this error is triggered by both packages AND repositories. If you are pulling all