Ja, je kan al snel even kijken in je access log voor sql injecties op get requests. Daarnaast kan je een query log activeren op mysql. En je kan hotjar installeren om te kijken of sommige spelers misschien bots gebruiken op bepaalde functies.

Citaat van Frenzo.Brouwer

Ik krijg nergens een foutmelding en ik zie nergens een fout..

Welke fouten registreer je op dit moment? Worden deze alle braaf weggeschreven naar je errorlog, of veeg je alle foutmeldingen onder het tapijt? Hoe luiden jouw error_reporting(), display_errors, log_errors en error_log directives?

Citaat van Frenzo.Brouwer

Het spel is geprogrammeerd in PHP PDO.

Sja, maar hanteer je de principes van PDO (en daarmee prepared statements) wel juist? Plak je zelf snippets in je query in plaats van hiervoor de placeholders te gebruiken? Dan ga je mogelijk al nat. Het maakt niet uit welke methode je gebruikt; als je de principes hiervan op de verkeerde manier toepast dan levert dat zelden/nooit veilige applicaties op.

Citaat van Frenzo.Brouwer

Wat ik me nu dus afvraag, is het mogelijk om SQL-injecties uit te voeren waardoor je dus onbeperkt geld krijgt?

Ja, zie hierboven, maar mogelijk is er iets anders aan de hand. Maken de queries die je gebruikt voor het uitwisselen van (speel)geld wel gebruik van database-transacties waarbij je eventueel records locked? Anders is het wellicht mogelijk om de server te bombarderen met verzoeken tot het overmaken van geld, waardoor de momenten van controle of iemand wel genoeg geld heeft om iets over te maken en het overmaken zelf door elkaar gaan lopen (met alle ongewenste gevolgen van dien). Je zou voor de gein eens kunnen kijken of er spelers met negatieve geldbedragen zijn? Dit hangt natuurlijk sterk af van hoe alles is ontworpen. Maar als er dus mensen zijn met onbeperkt geld dan zit er ergens iets goed scheef in het ontwerp, de veiligheid van de site, of beide.

Indien je geen gebruik maakt van database-transacties (hiervoor heb je de InnoDB database-engine nodig) zodat je kunt afdwingen dat dit soort geldtransacties echt als één ondeelbare actie uitgevoerd kunnen worden dan is het in zekere zin al einde oefening :p.

Citaat van Frenzo.Brouwer

Hoe kan ik dit testen?

Zie hierboven, of bekijk de suggesties van @darkshifty. Wat je op dit moment wilt doen is het verzamelen van "bewijs" zodat je de situatie kunt reproduceren of op zijn minst kunt verklaren.

Je zou ook eens door je code heen kunnen rennen en zoeken op de databasetabel(len) die betrekking hebben op speelgeld en dan de bijbehorende queries eens verder onder de loep nemen.

Wat misschien ook interessant was geweest was de toestand op het moment van de uit de hand gelopen geldbedragen te backuppen en deze eens op een testomgeving nader te bekijken, aangenomen dat deze website "verplaatsbaar" is. Je had dan waarschijnlijk een ideale testcase gehad, maar misschien is die dus nu alweer permanent verwijderd :/. Ook de database van een "gehackte" site kan zeer veel nuttige informatie bevatten.

Ik zou, wat hierboven ook geadviseerd wordt, beginnen met het toevoegen van logging / activity tracking.

Never trust the user. Er zijn namelijk nog veeeeel meer manieren om een php applicatie te misbruiken:

- SQL-Injections (testen a.d.v. een tool sqlmap).
- Object-Injections (uploaden van een geinjecteerd bestand)
- XSS-Injections
- CSRF-Injections
- Man-in-the-middle Attacks
- etc.

De meest voor de hand liggende methoden zijn denk ik wel SQL en Object-Injections in jou specifieke case.

In geval van Object-Injections kun je denken aan maatregelen als het correct valideren en 'sanatizen' van het bestand. Maar ook aan het niet direct ophalen van het geüploaden bestand uit de public directory. Zo voorkom je dat gebruikers het volgende kunnen uitvoeren: phar://http://www.example.com/uploads/avatar.jpg, omdat er in hun geüploaden bestand een kwaadaardig phar bestand zit verstopt die vervolgens gewoon wordt uitgevoerd en het phar-protocol t.o.v. het http-protocol geen restricties heeft.

Bij SQL-Injections moet je gewoon PDO correct te gebruiken, dus NOOIT raw-queries uitvoeren en altijd prepared statements indien er input komt van een gebruiker.

Verder wil ik hieraan toevoegen dat het beveiligen van applicaties een vak opzicht. Ongetwijfeld genoeg websites waarbij dit niet op orde is en als je een beetje gaat zoeken er vast genoeg te vinden. Dit geldt niet alleen voor kleine maar zeker ook grote bedrijven. De voorbeelden die ik noem zijn de methoden die ik weet maar er zullen vast nog meer methoden zijn om raar gedrag te veroorzaken bij een applicatie.

Citaat van Frenzo.Brouwer

Hey,
Bedankt voor je reactie! Heb wel een vraagje er over..

Wat bedoel je met een query log activeren op mysql?

Hotjar installeren is een goede! Thanks nogmaals voor je snelle reactie

Op deze website vind je een duidelijke uitleg hoe je bijvoorbeeld het log naar een tabel kan laten schrijven:
https://tableplus.com/blog/2018/10/h…g-in-mysql.html
En in de MySQL documentatie vind je meer informatie over de functionaliteit:
https://dev.mysql.com/doc/refman/5.7…stinations.html

Pas wel op dat je dit niet te lang laat wegschrijven naar je tabellen, dit kan binnen no time enorm groot worden.

Citaat van Frenzo.Brouwer

Graag kom ik met een van jullie in gesprek (Liefst via whatsapp of skype) om over de beveiliging te praten. Ik merk wel dat dit stukje minder goed door mij is uitgevoerd omdat ik mezelf hier nooit op heb gefocust...

Voel je vrij om vragen in dit topic te stellen.

Ik heb liever dat mensen mee kunnen lezen en hiervan kunnen leren dan dat ik één specifiek persoon ga helpen via Whatsapp/Skype. Dit moet volgens mij de kracht zijn van ICTScripters.

In het verleden heb ik dit wel gedaan, maar tegenwoordig reken ik gewoon consultancyuren voor dit soort advies als het gaat om een privégesprek. Te vaak goedbedoelde adviezen gedaan, waar vervolgens weinig waardering is voor het betreffende persoon (zeg niet dat jij dat doet) en de betreffende persoon heeft er vervolgens ook niks van geleerd.

Citaat van Frenzo.Brouwer

Heb ook eigenlijk geen idee hoe ik mijn php errors kan weg schrijven naar mijn database?

Waarom zou je dat willen doen? Volgens mij wordt dit nergens voorgesteld? Dit kun je gewoon doen naar een bestand. Trouwens het aanzetten van querylogging kan wel een performancedeuk opleveren, dus daar zul je misschien ook een beetje op moeten letten.

Citaat van Frenzo.Brouwer

Graag kom ik met een van jullie in gesprek (Liefst via whatsapp of skype) om over de beveiliging te praten. Ik merk wel dat dit stukje minder goed door mij is uitgevoerd omdat ik mezelf hier nooit op heb gefocust...

Dit zou het cement van je applicatie moeten vormen. Tegelijkertijd, indien je niet bekend met bepaalde (andere) principes zoals database-transacties dan kan je code misschien wel "veilig" zijn, maar zijn er nog steeds "onveilige" / onwenselijke situaties mogelijk. Het is zaak dat je van al deze markten thuis bent. Daarbij helpt het als de site "portabel" is zodat je makkelijk een ontwikkel-/test- en productie-omgeving kunt opzetten. En makkelijk code+(test)dabases kunt deployen op deze omgevingen.

Citaat van M.Beers

Dit moet volgens mij de kracht zijn van ICTScripters.

Niet zozeer van deze site alleen, maar meer van alle fora / efficiente communicatie in het algemeen. Op deze manier kun je je boodschap in één keer uitzenden in plaats van 1-op-1 elke keer hetzelfde verhaal te vertellen.

Citaat van M.Beers

Te vaak goedbedoelde adviezen gedaan, waar vervolgens weinig waardering is voor het betreffende persoon (zeg niet dat jij dat doet) en de betreffende persoon heeft er vervolgens ook niks van geleerd.

Sja, dat is het lot van eenieder die reageert op een forum, verwacht niets terug. Dus kun je er misschien inderdaad maar beter iets aan verdienen I suppose :p.

Citaat van Frenzo.Brouwer

Om dan direct met de deur in huis te vallen: Wat reken jij voor het beveiligen van mijn website volgens de punten die jij in jou bericht aanhaalt?

Mijn standaard ZZP-tarief is 60 euro per uur incl. BTW. Alleen zou ik er persoonlijk niet voor kiezen om te investeren in een "simpele" criminals game die leuk zijn voor de hobby, maar verder in de praktijk weinig tot niks gaat opleveren.

Als ik hierin een tip mag geven; ga de benoemde problemen eens Googlen... genoeg best practices die je hierin kunnen helpen.

Bekijk alle request die je kan maken, bijvoorbeeld verkoop een auto.
Als die niet registreert dat die al verkocht is en iemand doet met een request maker ( google chrome app) hem 50x ophalen dan heeft die zo geld.

Dan is verkoop auto een voorbeeld waarschijnlijk heb je wel meer dingen die dan opvragen zal dat ook is na lopen.

Citaat van tkzone

Als die niet registreert dat die al verkocht is en iemand doet met een request maker ( google chrome app) hem 50x ophalen dan heeft die zo geld.

Ja maar het is dus heel erg belangrijk hoe je dit controleert. Als dit soort fratsen mogelijk zijn dan houdt dat dus in dat de registratie (mogelijk wel gebeurt maar) niet goed plaatsvindt.

Citaat van tkzone

Dan is verkoop auto een voorbeeld waarschijnlijk heb je wel meer dingen die dan opvragen zal dat ook is na lopen.

Maar dat zou dus inhouden dat dit soort checks mogelijk fundamenteel verkeerd zijn. En mogelijk is je applicatie uberhaupt niet uitgerust met de middelen om dit te (kunnen) doen.

Om dit soort zaken te voorkomen moet je waarschijnlijk de mogelijkheid hebben records echt voor korte tijd te locken middels database-transacties. Indien je database (er vanuitgaande dat dit MySQL is) geen gebruik maakt van de InnoDB-engine dan wordt e.e.a. al verdomd lastig zo niet onmogelijk. In dat geval zul je eerst terug moeten naar het database-ontwerp, want om dit programmatisch op te lossen lijkt mij onbegonnen werk (en is mogelijk nog veel foutgevoeliger).

Ik geef het mee als tip dat die dat misschien moet controlleren, omdat hij met bug komt dat mensen veel geld hebben in het spel.

Als daar die daar al fout mee begonnen is vanaf het begin dan is het natuurlijk echt veel werk om dat allemaal te gaan aanpassen.

Citaat van tkzone

Ik geef het mee als tip dat die dat misschien moet controlleren, omdat hij met bug komt dat mensen veel geld hebben in het spel.

Dat is prima, maar zoveel had ik al min of meer gesuggereerd in een vorige reactie :).

kan ook gebeuren door b.v. meer pagina's te openen en te gelijk een handeling te doen.
De meeste vinden dat niet lekker, als het niet goed gescript is.
Zelfde met pagina terug etc.
Bekende bugs bij crimes..... Spelers vinden altijd wel weer wat, zeker als er prijzen mee te verdienen valt.....
Pagina's loggen van spelers waar ze komen dan haal je meestal wel hoop er uit...

Dit is allemaal eenzelfde soort problematiek. Dit kan verholpen worden door gebruikmaking van database-transacties.

Artikel is inmiddels enigszins gedateerd, maar die paragraaf (7.10.9 Voorbeeld van gebruik) beschrijft in wezen nog steeds het onderliggende probleem. Een (beperkte) resource wordt tegelijkertijd meerdere keren gewijzigd naar aanleiding van een serie van handelingen, met ongewenste gevolgen. De remedie is om deze "series van handelingen" zodanig in afzondering (van elkaar) te behandelen, zodat deze niet meer verweven zijn, maar de series an sich ook echt in serie worden uitgevoerd.

Dit voert verder dan simpelweg wat codewijzigingen. Je moet je bewust zijn van wat er mis kan gaan, en vervolgens moeten er zowel in code alsook de database voorzieningen worden getroffen om dit tegen te gaan.

Maar voordat je dit doet moet je echt begrijpen wat er misgaat (zie artikel), waarom dit misgaat en hoe je dit moet bestrijden. Dit zodat je in de toekomst dit soort scenario's kunt identificeren, en dan niet opnieuw dezelfde fout maakt.