Beveiliging tussen formulier en betalingspagina
Ik ben een hacker en ik heb mezelf toegang weten te verschaffen tot iemands website
die gebruik maakt van iDeal betalingen.
Ergens binnen die website is een laatste controle pagina/formulier voordat er wordt overgegaan naar iDeal,
en bij een klik op de knop wordt ik dus middels <form action='betaling.php'> naar de betalingspagina gestuurd binnen de site. Tot zover...
Stel, nu kopieer ik alles wat gerelateerd is aan die betalingspagina/iDeal, en noem het allemaal net even anders, vul ipv de oorspronkelijke iDeal gegevens mijn iDeal partner gegevens in, en in de voorlaatste pagina wijzig ik de action naar <form action='betaling2.php'>
Ofwel... nu gaan de betalingen via mijn iDeal account naar mijn rekening.
Nou ben ik in werkelijkheid alleen niet die hacker, maar de andere kant dus.
Even helemaal los van het feit dat de hacker te achterhalen is, en het heeeeel veel werk kost om ooit je geld terug te krijgen,
ben ik éigenlijk op zoek naar een mechanisme wat dit überhaupt ooit kan voorkomen.
Wie heeft hier een slim idee over hoe dit aan te pakken?
Alvast dank voor het mee denken...
Gewijzigd op 04/09/2019 21:24:34 door - Ariën -
Het probleem is niet echt de cruciale info, dat zit wel goed.
Het probleem zit er in dat iemand de website aanpast en ik op zoek ben naar een of ander mechanisme wat
in de gaten heeft dát er iets is aangepast (en daarop bijvoorbeeld alles dicht gooit).
Is het bijvoorbeeld meetbaar met een cronjob om de bestandsgrootte van deze twee pagina's te meten, en dan daarop te acteren... (of kom ik dan al eigenlijk te veel in de unix sfeer :-) )
Maar elke andere manier die hierin iets kan betekenen is natuurlijk ook prima.
Toevoeging op 04/09/2019 21:36:00:
Ik denk dat ik daar inderdaad naar op zoek moet... een unix script die de bestandsgrootte controleert
en daarmee actie onderneemt.
Wat mij betreft mag topic gesloten :-)
Een andere aanvalsvector is bijvoorbeeld iets als Cross Site Scripting (XSS). De aanvaller voegt dan bijvoorbeeld iets aan de URL toe, waarmee ze een stukje javascript in je pagina kunnen injecteren (omdat je speciale tekens niet escapet), en dan dus van "betaling.php" via een javascript event of iets dergelijks "https://hacker.ru/betaling2.php" maakt. Of als de opmaak van je pagina voor een deel uit templates bestaat die bijvoorbeeld in een database worden opgeslagen, hebben ze die database weten aan te passen (ook weer via een vorm van injectie, of ook gewoon door directe toegang tot die database weten te bemachtigen - bijvoorbeeld door via brute force het wachtwoord te achterhalen).
Deze laatste varianten ga je dus niet meten door je bestanden te vergelijken. Die kun je eigenlijk alleen in de praktijk zien: zelf in een browser aan de slag gaan, en kijken waar het formulier naar toe verwijst. Nou kun je dit wel deels automatiseren door dit in een headless browser te doen, en dan te kijken wat er - nadat ook de javascript heeft gedraaid, uiteindelijk aan HTML resulteert, maar een beetje clevere hacker kan dan natuurlijk nog steeds z'n acties alleen uitvoeren als ie zeker weet dat er alleen een echte gebruiker achter de computer zit ...
Eric T op 04/09/2019 21:08:01:
toegang weten te verschaffen tot iemands website
Ik was toen eigenlijk al gestopt met serieus lezen.
Dat is je probleem, en dat zul je ook op moeten lossen.
Alle andere "remedies" zoals het controleren van bestandsgroottes (wat trouwens geen fantastische methode is, ik kan een bestand inhoudelijk aanpassen en dan wat spaties toevoegen om het te laten lijken alsof het bestand niet gewijzigd is) zijn doekjes voor het bloeden.
Als iemand toegang heeft tot jouw server zijn alle checks die op corruptie checken OOK corrumpeerbaar. Dit haalt dus niet zoveel uit. Een check op bestandsgroottes (zie ook hierboven) lijkt mij dus geen oplossing.
Voordat je je band gaat plakken zul je ook eerst moeten kijken waar het lek zit, anders kun je de band beter in zijn geheel vervangen.
De implementaties van betalingsmethoden zijn meestal "voorgeschreven handshakes" en/of krijg je van de PSP's complete modules waarin je enkel je accountgegevens in hoeft te vullen, dus dat zou al goed moeten zitten.
Als echter je server is aangetast, dan is het letterlijk "All Bets Are Off".
Ik heb nog niets gehoord over je hostingopzet. Beheer je alles zelf, of is dit dedicated, of wat? Lijkt mij dat je hosting je bij zou kunnen staan in zulke gevallen, maar het hangt er vanaf hoe de verstandhouding tussen jullie is.
Zie ook: md5_file
Gewijzigd op 05/09/2019 00:09:48 door - Ariën -
Stel...hypothetish:
Jij bent zelf die hacker en hebt jezelf toegang weten te verschaffen tot iemands website/server ... dan is alles wat je hier vraagt en datgene wat je probeert te doen in strijd met de Nederlandse wetgeving en ben je dus strafbaar bezig.
^^ Ik ga hier niet vanuit ... maar wil het wel even gezegd hebben voor eenieder die dit leest.
Daarnaast: zorg voor een SSL certificaat en zie er op toe dat je provider actief bezig is met beveiliging van je server.