wir hatten am 28.06. Aufrufe an Mollie im Log die einen kritischen Fehler geworfen haben. Für mich sieht es so aus als würde versucht werden Zahlungen einzuleiten.
Das letzte Mal, als ich sowas an Plenty gemeldet habe, hieß es die Aufruf kämen über ein externes System oder von einer anderen Person. Nicht aber von Plenty selbst.
[Hier war ein Bild. Ich darf aber nur eines pro Post verwenden.]
Wie sicher ist eine solche Anbindung die Aufrufe von außen zulässt? Könnte es irgendwann gelingen eine Bestellung aufzugeben und eine Zahlung vorzutäuschen?
Wenn man die Seite mit Domain+Pfad aufruft, sollte der Zugriff auch geloggt werden, sonst wäre es ja kein Logging.
Ich kann jetzt nicht sagen, wie der Call normalerweise ausschaut, aber hier wurde wohl einfach, wie @dirkdreher bereits angemerkt hat, mal ein SQL-Injection getestet.
Das ist etwas, was ein System eigentlich erkennen sollte, also an der Stelle sollte eigentlich nicht stehen, das er keine Bestellung 1 gefunden hat, sondern dass die Anfrage „malicious“ ist, also bösartig.
Interessant wird es, wenn der Call erst an einer Stelle erzeugt werden „kann“, nachdem die Bestellung vorbereitet wurde (Checkout kurz vor dem Kauf).
Der Entwickler in mir fragt sich auch, ob GET für diese Anfrage möglich sein sollte, aber da hab ich zuwenig berührung mit der Mollie-Api in Plenty
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1*DBMS_PIPE.RECEIVE_MESSAGE(CHR(99)%7C%7CCHR(99)%7C%7CCHR(99)%2C15)"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1xQvacfJ9'))%20OR%20820=(SELECT%20820%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1OKCJ9QiG')%20OR%20566=(SELECT%20566%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1hMI66pxW'%20OR%20538=(SELECT%20538%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1-1))%20OR%20231=(SELECT%20231%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1-1)%20OR%20760=(SELECT%20760%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1-1%20OR%20187=(SELECT%20187%20FROM%20PG_SLEEP(15))--"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1BHtIVygP';%20waitfor%20delay%20'0:0:15'%20--%20"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1-1%20waitfor%20delay%20'0:0:15'%20--%20"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1-1);%20waitfor%20delay%20'0:0:15'%20--%20"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=(select(0)from(select(sleep(15)))v)/*'%2B(select(0)from(select(sleep(15)))v)%2B'\"%2B(select(0)from(select(sleep(15)))v)%2B\"*/"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=10\"XOR(1*if(now()=sysdate()%2Csleep(15)%2C0))XOR\"Z"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=1*if(now()=sysdate()%2Csleep(15)%2C0)"
callerFunction:"route: GET /rest/mollie/init_payment?&orderId=-1\"%20OR%205*5=25%20or%20\"f0zzqJYG\"=\""
Das sieht stark danach aus, das jemand mal getestet hat was geht.
Wichtig ist, das er als Antwort niemals etwas anderes als „No query results for model …“ bekommt.
Du bekommst einen Spam-Newsletter und Klicks auf abmelden.
Du bekommst das Feedback das du abgemeldet wurdest und gleichzeitig bekommt der Spammer die Bestätigung, dass da jemand aktiv die E-Mails liest.
Folge: noch mehr Spam
Hier bekommt der „Tester“ scheinbar immer eine positive Info zurück.
Nämlich, das nichts gefunden wurde. Kein Abbruch und nichts.
@jkornau nicht wundern, hab jetzt gerade auch einen Call abgefeuert, kann sein das der auch im Log auftaucht (01.07.2025 / 11:13)
Der wurde im Browser z.B. mit
{"error":{"message":"Payment method not from Mollie.","code":0}}
beantwortet. Sauberer wäre eine Verbindungsablehnung und zeitnahe Sperrung des Absenders.
ich würde behaupten, man muss sich da keine Sorgen machen, da als API Backend PHP Laravel verwendet wird und der API Server normalerweise sowas standardmäßig rausfiltert bzw. korrekt behandelt. (Auch wenn die Antwort hier nicht danach aussehen mag)
Wir haben bei uns sowas in der Woche sicher 1000x auf z.b. die Shopsuche oder andere URLs.
Verstehe aber nicht, wieso Plenty nicht sowas wie AWS WAF verwendet (gibt haufen guter default Rules BlockSQLTimeBasedAttacks ), um das default zu blockieren. (Damit hat sich auch das Thema Sperren dann z.b. erledigt)
