![]() My first questions when I heard about this change were, “What does this mean for pre-existing layout updates? Will they no longer work and need to be migrated in one-way or another?”. What Does The Change Mean for Pre-Existing Layout Updates? Given this danger, Magento decided to remove this feature entirely, effectively shutting down any possible vulnerability that would leverage it. This in turn can lead to remote code execution or SQL injection. ![]() From a high level, the idea is, an attacker can find ways to abuse the feature by passing unexpected arguments to unexpected functions. This opens the door to a class of vulnerability known as “Server Side Template Injection” (SSTI). ![]() Generally speaking, giving users the ability freely manage layout / rendering from an administrative panel is a dangerous prospect from a security point-of-view. Some Backgroundīefore we dig into the specifics of this change, it’s useful to have an understanding of why Magento made this change. Here, I’d like to present my findings in a slightly more formal manner, and also offer some additional details. I dug into this a bit and shared some info in this Twitter thread. The Custom Layout Update field on the CMS Page Edit, Category Edit, and Product Edit pages has now been converted to a selector Removal of custom layout updates and the deprecation of layout updates to remove the opportunity for Remote Code Execution (RCE). Per Magento’s release notes, as of Magento v2.3.4, this ability has been removed: These updates would then be merged with layout definitions from the theme on the website to impact the overall frontend page rendering. In versions on Magento prior to v2.3.4, users had the ability to add custom layout updates to category, product and cms pages via a textarea input from the Magento admin panel. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |