[PHP] Criminals bugs opsporen

[Verwijderd]

Hey,
ik wil kijken hoe lek criminals nou eigenlijk is. Veel mensen zeggen dat het gemakkelijk is om remote sql injections te doen, etc. Ik wil dit testen op mijn eigen script, of je nou echt remote iets in de database kan veranderen.

Mijn vraag is nu, hoe pak ik dit aan? Ik ken de basis van php, maar hoe kan je controleren of iets een bug is, en dat er remote gebruik van kan worden gemaakt?

Wat zijn de standaard bugs van criminals? Waar kan men zo remote wat querys uitvoeren?

Zo kan ik mijn script optimaal beveiligen.

[André]

PHP = Programming

En wat heb je zelf al geprobeerd en gevonden?

[ Voor 42% gewijzigd door André op 21-07-2006 20:56 ]

[Verwijderd]

Gezocht, heel Google. Kijken hoe ik querys uit kon voeren remote, dan kan ink zelf kijken hoe ik het dicht. Ik heb door de source gekeken maar ik heb werkelijk geen idee hoe ik een bug moet herkennen..

[engelbertus]

goh.. een bug herkennen door eenvoudig de source van een ander wat door te bladeren ( meer zal het niet geweest zijn gok ik ;-) en onnodig ook nog omdat je niet weet waar het fout kan gaan
het lijkt me een beetje voorbarig om dan te stellen dat je wel even wat bugs gaat vinden en oplossen, maar ja, wie ben ik. maar om dan te vragen wat de lekken zijn en hoe je er gebruik van kunt maken vindt ik wel wat obscuur. ik zou verwachten als je security minded bent, je dat wel weet te vinden ?

[MueR]

Daarbij is de vraag naar "de bekende bugs in Criminals" ook niet echt iets waar wij ons mee bezig houden. Dat zou je kunnen vragen bij de makers van Criminals, die je waarschijnlijk fijntjes vertellen dat er op die manier misbruik gemaakt kan worden van het spel, en ze dus daarom je de bugs niet gaan geven.

[Guru Evi]

Simpel: als je de source code hebt, ga je door de source code en zie je wat elke instructie doet. Dan kun je nakijken of bepaalde invoer niet gecontroleerd wordt op correctheid of niet correct gequote wordt. Bijvoorbeeld:

code:

<?php
$variable = $_GET['variable'];
$sql = "SELECT * FROM blaat WHERE key = $variable";
?>

is slecht omdat ik als ik een url constructeer waar $variable het volgende van wordt: "value OR 1=1;" dan krijg ik opeens een listing van de volledige database...

En er is zoveel die je kunt nakijken, maar daar zul je zelf eens moeten op zoeken: security & php

[Verwijderd]

André schreef op vrijdag 21 juli 2006 @ 20:56:
En wat heb je zelf al geprobeerd en gevonden?

Vind je 't erg dat ik dat wel een heel erg domme vraag vind?
'Criminals' proberen juist de dingen die je zelf nog niet geprobeerd hebt, en vinden dingen die je zelf over het hoofd hebt gezien.

[AW_Bos]

Of je SQL injection kan uitvoeren hangt van je Magic Quotes instelling in je PHP af. Meestal staan deze voor GPC (Get/Post/Cookie) altijd aan, dus krijgen ze automagisch addslashes...
Verder is die troep van Criminals niet alleen lek, maar ook server overbelastend.
Mag ik even komen met wat nadelen van dit stuk software?

- Geen goede foutafhandeling
- Onnodige backticks om tabellen heen.
- Gare herdedocs <<ENDHTML etc..
- mysql_pconnect. Leuk om je MySQL connecties open te houden ..
- Soms zijn adminbackend beveildigd met een GET waarde: admin.php?x=adminblaat (enkele keer gezien)
- Bagger opbouw van de code..

Ok, dit valt wel te fixxen, maar dan kan je beter from scratch beginnen denk ik, naar mijn mening.

En een goede tip: Lees dit eens door:
http://www.phpfreakz.nl/artikelen.php?aid=106

[ Voor 24% gewijzigd door AW_Bos op 22-07-2006 00:00 ]

[Sendy]

Nee Afterlife. Je kan toch niet zeggen wat je nog kan proberen als je niet zegt wat je al geprobeerd hebt?

Verder snap ik dit topic niet echt. Wat is "criminals"? Misschien kan de TS nog wat meer info daarover plaatsen?

[Verwijderd]

AW_Bos schreef op vrijdag 21 juli 2006 @ 23:57:
Of je SQL injection kan uitvoeren hangt van je Magic Quotes instelling in je PHP af. Meestal staan deze voor GPC (Get/Post/Cookie) altijd aan, dus krijgen ze automagisch addslashes...

Onzin. SQL injection is uitsluitend afhankelijk van 1 instelling: die van de ontwikkelaar.
Wanneer je input van users in je query opneemt moet je gewoon heel voorzichtig zijn: rechtstreeks een username als ';drop table users' in je SQL opnemen is niet handig, en daar helpt je geen addslashes of magic quotes aan...
(gechargeerd, want meestal heeft die web-user geen admin rechten op de database, maar om maar even aan te geven dat PHP maar 1 schakel in de keten is)

Aan de voordeur (PHP) moet je nooit vertrouwen op degene die aanklopt (user) of op je slotenmaker (Magic Quotes, addslashes). Je queries parametriseren is 't veiligst, maar wanneer 't echt niet anders kan moet de user input door de vlooienkam.
Bij een MSSQL backend zou ik bv. dingen als ';', 'xp_', 'master', '--', '/*' enz. enz. absoluut weigeren als input.

Verder is die troep van Criminals niet alleen lek, maar ook server overbelastend.

Ik dacht dat TS met 'Criminals' gewoon de doorsnee hufters bedoelde, maar ze hebben zichzelf blijkbaar een eigen vetleren medaille toebedeeld?
Zo leer ik ook nog 's wat.

[Verwijderd]

Zover ik weet zit criminals echt vol met fouten .

maar gewoon eens een paar page's doorlopen en kijke of er wel een check op word uitgevoert op de data wat hij binnen krijgt van get/post checked hij niet kanje makelijk mysql uitvoeren zekker omdat je de sql hebt en dus de table names etc.

[Verwijderd]

Verwijderd schreef op zaterdag 22 juli 2006 @ 01:18:

[...]

Ik dacht dat TS met 'Criminals' gewoon de doorsnee hufters bedoelde, maar ze hebben zichzelf blijkbaar een eigen vetleren medaille toebedeeld?
Zo leer ik ook nog 's wat.

Google?

[jan-marten]

Hier heb ik ooit eens een criminals script vandaan gehaald. Het is geschreven met het doel om van a naar b te komen op de meest efficiente manier (geen commentaar in de code, geen gebruik van classes, html/php/javascript allemaal in php files gezet, geen invoercontrole). Plus het feit dat ze Cronjobs nodig hebben (die rekenen dan de punten eens per uur/dag/week uit). Resource vretend dus en behoorlijk lek.

Veel succes als je dat wilt debuggen.

[Creepy]

jan-marten schreef op zaterdag 22 juli 2006 @ 09:54:
Plus het feit dat ze Cronjobs nodig hebben (die rekenen dan de punten eens per uur/dag/week uit). Resource vretend dus en behoorlijk lek.

?? Omdat het een cronjob is, is het en resource vretend en behoorlijk lek? Beetje erg kort door de bocht vind je niet?

[JayVee]

AW_Bos schreef op vrijdag 21 juli 2006 @ 23:57:
Of je SQL injection kan uitvoeren hangt van je Magic Quotes instelling in je PHP af. Meestal staan deze voor GPC (Get/Post/Cookie) altijd aan, dus krijgen ze automagisch addslashes...

AfterLife had hier al commentaar op.

Sterker nog: addslashes is niet genoeg om SQL injection te voorkomen, daar moet je mysql_real_escape_string voor gebruiken!
magic_quotes zijn dus redelijk nutteloos, en worden niet voor niets afgeschaft in PHP 6 (samen met register_globals).

[Woy]

Verwijderd schreef op zaterdag 22 juli 2006 @ 01:18:
[...]

Bij een MSSQL backend zou ik bv. dingen als ';', 'xp_', 'master', '--', '/*' enz. enz. absoluut weigeren als input.

Dat vindt ik ook een beetje kort door de bocht. Als iets een text veld is mag dat van mij best ingevoegd worden. Zeker als je met een geparametriseerd query systeem werkt zou dat geen problemen op moeten leveren ( Al weet ik niet of er een goed werkend parameter systeem is voor PHP )

JayVee schreef op zaterdag 22 juli 2006 @ 10:40:

AfterLife had hier al commentaar op.

Sterker nog: addslashes is niet genoeg om SQL injection te voorkomen, daar moet je mysql_real_escape_string voor gebruiken!
magic_quotes zijn dus redelijk nutteloos, en worden niet voor niets afgeschaft in PHP 6 (samen met register_globals).

En bovendien is magiq_quotes gewoon ronduit irritant. Mischien wil ik wel iets met de data doen waar die slashes niet voor nodig zijn. Dan moet ik eerst weer die slashes gaan verwijderen.

Als ik iets in de database stop zorg ik er zelf wel voor dat het geescaped en al is. Als ze een veilig alternatief aan willen bieden kunnen ze het best gewoon een geparametriseerd query systeem aan bieden. Dat werkt makkelijker, veiliger en het is nog mogenlijk om er performance winst uit te halen ook.

[ Voor 22% gewijzigd door Woy op 22-07-2006 10:52 ]

[Verwijderd]

Bedankt iedereen, voor de reacties. Ik heb de source geupload voor de geinteresseerden:

http://rapidshare.de/files/26600496/Criminals.rar.html

Als een databaseconnectie niet (correct) wordt afgesloten, kan een hacker hier iets mee doen dan?

[Verwijderd]

rwb schreef op zaterdag 22 juli 2006 @ 10:49:
Dat vindt ik ook een beetje kort door de bocht. Als iets een text veld is mag dat van mij best ingevoegd worden. Zeker als je met een geparametriseerd query systeem werkt zou dat geen problemen op moeten leveren ( Al weet ik niet of er een goed werkend parameter systeem is voor PHP )

Dat zei ik ook:
"Je queries parametriseren is 't veiligst, maar wanneer 't echt niet anders kan moet de user input door de vlooienkam."

[kunnen]

Verwijderd schreef op zaterdag 22 juli 2006 @ 11:00:
[..]
Als een databaseconnectie niet (correct) wordt afgesloten, kan een hacker hier iets mee doen dan?

Nee, maar dit kan enorm veel resources kosten op je server.

[YopY]

Pulsher schreef op zaterdag 22 juli 2006 @ 12:44:
[...]

Nee, maar dit kan enorm veel resources kosten op je server.

Valt wel mee toch, PHP sluit toch vanzelf die verbinding weer af nadat de scripts uitgevoerd zijn?

(Zo niet, dan moet ik mijn scripts nog even instellen dat ze de verbinding ook weer verbreken )

[Shadowman]

YopY schreef op zaterdag 22 juli 2006 @ 13:35:
[...]


Valt wel mee toch, PHP sluit toch vanzelf die verbinding weer af nadat de scripts uitgevoerd zijn?

(Zo niet, dan moet ik mijn scripts nog even instellen dat ze de verbinding ook weer verbreken )

klopt, tenzij er mysql_pconnect wordt gebruikt. Bij mysql_pconnect blijft een verbinding open (wordt gesloten na een tijd niet gebruikt te zijn geloof ik) en wordt die opnieuw gebruikt bij een volgend request (indien mogelijk).

quote: http://ie2.php.net/mysql_connect

De link naar de server zal worden gesloten zodra de executie van het script eindigt, tenzij hij eerder expliciet gesloten wordt door het aanroepen van mysql_close()