04 Aug 22
PrestaShop, the company that gives name to the famous CMS (content management system) in open source, has reported a vulnerability in the safety of their product, that allowed the execution of arbitrary code on the servers that give support to websites based on it. In scenarios like this, a next generation WAF becomes highly important. Let us explain.
PrestaShop’s CMS is a solution preferred by a large number of people in the construction of their e-commerce platforms. According to the company itself, approximately 300.000 online businesses are based on their software solution, especially in Europe and Latin America.
The exploitation of this vulnerability and the subsequent injection of malicious code will give the attacker the ability of gathering confidential information referring to the clients of these e-commerce platforms. This information includes banking details of said clients.
The vulnerability, which has been categorized as CVE-2022-36408, is a vulnerability by SQL injection or SQLi. According to the data given by the company, it affects versions of their product from v1.6.0.10 onwards. PrestaShop has repaired it from version v1.7.8.7, although they can’t guarantee that this is the only way of executing the attack.
And, even if you do have to update the software, with its corresponding security patches, such as we recommend at Transparent Edge, it’s also useful to consider the great relevance of a WAF (web application firewall).
A WAF is, first of all, a security tool, a firewall that analyzes and, when necessary, intercepts and blocks malicious HTTP traffic (such as attempts of SQLi and others), to and from a web application, such as the case of an e-commerce platform based on PrestaShop.
Integrated into our next-generation CDN, our WAF is completely configurable from our dashboard.
Declaratively, and through a limited set of HTTP headers, it’s possible, among other things:
That way, a configuration such as the next, deployed in our panel, would activate the use of the WAF for the website www.mysite.com
sub vcl_recv { if (req.http.host == "www.mi-sitio.es") { set req.http.TCDN-WAF-Enabled = "true"; set req.http.TCDN-WAF-Set-SecRuleEngine = "#On"; } }
That way, the requests made against the website would be processed in our CDN, which would delegate those requests to the WAF. The WAF would then act as a second layer between the CDN and the origin (backend) of the site.
Once a request is received in the WAF, it executes the proper verifications to determine its nature: whether it’s safe or malicious.
So, in the case it’s safe, the request will be delegated safely to the origin, the underlying infrastructure. But if the request is malicious, it will be blocked by the WAF, returning a status code 403 (Forbidden). It will never get to interact with the origin, so it won’t be able to cause harm.
Transparent Edge’s next-generation WAF is built on Modsecurity and implements and updates the OWASP (Open Web Application Security Project) CRS (core rule set) so that it can always have the latest set of rules for attack detection.
The goal is then, to protect web applications from a wide variety of attacks, including the OWASP Top 10, and on the other hand, minimize the possibility of false positives.
In the case of the vulnerability reported by PrestaShop, being an SQLi, the set of rules of OWASP CRS associated with this kind of attacks is the one with numbering 942XXX. It’s related to configuration file rules: rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf.
This set of rules combines the different reasons contemplated (in broad terms, matching regular expressions), that reveal that a matching request has the purpose to access the website’s database, maybe to destroy or to gather data, as it has happened with PrestaShop.
Our next-generation WAF has, besides, an integrated antivirus for the analysis of attached files. It guarantees the access to security audits generated by said WAF, from our control dashboard or as an external way through our log delivery service via streaming.
Also, and thanks to its integration with our CDN, it’s possible to combine in a simple way other mechanisms for protection, such as blocking of suspicious IPs, defining geolocation blocking rules, or applying limits to the ratio of requests by unit of time (rate limit).
To summarize, having an adequate policy for the installation of security patches and the update of software is key. You’ve seen that our WAF is a tool with the proper attributes and required capacity to counteract and mitigate dangerous scenarios, such as the one that PrestaShop detected recently.
Compartir:
