Beveiliging tussen formulier en betalingspagina

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Eric T

Eric T

04/09/2019 21:08:01
Quote Anchor link
Stel...hypothetish:
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...
 
PHP hulp

PHP hulp

06/12/2019 04:13:03
 
- Ariën -
Beheerder

- Ariën -

04/09/2019 21:23:56
Quote Anchor link
Je moet er gewoon voor zorgen dat je geen cruciale informatie in je request doorgeeft die anderen kunnen aftappen en aanpassen. Hoe je dit voorkomt ligt echt aan de implementatie van de betalingsverwerking naar de PSP. In alle lijnen moet dit juist veilig zijn.
Gewijzigd op 04/09/2019 21:24:34 door - Ariën -
 
Eric T

Eric T

04/09/2019 21:32:34
Quote Anchor link
Hoi Ariën, dank voor je snelle reactie.
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 :-)
 
- Ariën -
Beheerder

- Ariën -

04/09/2019 22:01:53
Quote Anchor link
Topics doen we alleen dicht als ze de huisregels overtreden of als ze onnodig omhoog gehaald worden door iemand na lange inactiviteit. We willen namelijk iedereen graag de mogelijkheid geven om een mening te geven.
 
Rob Doemaarwat

Rob Doemaarwat

04/09/2019 22:20:15
Quote Anchor link
Het aanpassen van een PHP bestand is goed te meten, maar betekent ook dat iemand toegang heeft tot je server (of je ontwikkelomgeving).

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 ...
 
Verwijderd 31683

Verwijderd 31683

04/09/2019 23:28:02
Quote Anchor link
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.
 
- Ariën -
Beheerder

- Ariën -

05/09/2019 00:06:58
Quote Anchor link
De enige manier om te bekijken of een bestand aangepast is, is vooraf een md5hash te genereren als checksum, en deze te vergelijken op het moment dat je die opnieuw berekent.

Zie ook: md5_file
Gewijzigd op 05/09/2019 00:09:48 door - Ariën -
 
Ozzie PHP

Ozzie PHP

05/09/2019 00:54:47
Quote Anchor link
Ik vind het eerlijk gezegd nogal een bijzonder vergezocht en expliciet benoemd scenario ... een hacker met een eigen iDEAL-account ... yeah right. Die is uiteraard binnen 2 minuten te achterhalen op basis van z'n inschrijfgegevens bij iDEAL, nog even afgezien van het feit dat overal in de log-bestanden zijn IP-adres zou staan. Daarnaast zou de betalingsinformatie van een klant gekoppeld moeten zijn aan een hash in jouw database. En hoe zou die hacker zich überhaupt toegang moeten verschaffen tot jouw server?


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.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

05/09/2019 09:56:53
Quote Anchor link
Gewoon sterke wachtwoorden gebruiken voor alle deuren die naar je data of code leiden zoals je Configuratie en beheer omgeving, je FTP, SSH, MyPHPAdmin en (mysql) database server.
Daarnaast: zorg voor een SSL certificaat en zie er op toe dat je provider actief bezig is met beveiliging van je server.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.