[Php] Is mijn script hackbaar?

[Verwijderd]

Hoi, ik had eens een topic gemaakt om mij even te helpen met scripten:
http://gathering.tweakers.net/forum/list_messages/1290396

Wel, het was een wonder, want ik heb het volledig zelf kunnen fixen!

Alleen kreeg ik daarnet iemand op msn en die zei dat ik het niet goed heb gedaan, want nu is het hackbaar omdat ik cookies heb gebruikt Ik vroeg hem om mij te bewijzen of het echt degelijk te hacken is, maar daar had hij geen zin in.

Oké, wie is vrijwilliger om mijn site te hacken?
Pm met je msn adres dan voeg ik je meteen toe en geef ik jou de link.

(Oja! Ik heb dit topic niet gemaakt om te helpen met scripten)

[ Voor 14% gewijzigd door Verwijderd op 12-03-2011 15:46 ]

[Verwijderd]

Als een cookie gestolen wordt (denk aan de vroegere Limewire met daarbij de Hotmail cookies) kan die worden gebruikt bij jouw site ja. Het enige wat je nodig is toegang tot de cookies van je users op je site die gebruik maken van je script.

Dus als je je cookie enigzins verbind met een sessie oid dan valt dat best mee _{is dat niet precies wat er dan ook gebeurd? ... afijn}

[soulrider]

vragen om te hacken is wat tegen de policy ('werving' en zo)

maar mogelijk kunnen we je helpen als je dat stukje code laat zien ?
(aanpassing naar post van TS om hele code te posten: is niet nodig, enkel het stuk dat je sessie's/cookie's afhandeld - al de rest is overbodige balast)

veel kunnen de code zo wel lezen, en de gaten eruit halen en zelfs verbeteringen aanraden.
(anders eens kijken bij andere soortgelijke code van bv hotscripts.com)

en bij sessies moet je altijd opletten voor replay-attacks.
(jij komt aan mijn pc, logt in op je site, logt terug uit - maar ik heb ondertussen een copy-paste van je cookie gemaakt terwijl je was ingelogd, en daarmee kan ik achteraf als 'jou' terug inloggen op jouw site.)

als dat lukt, dan kan ik ook remote je cookie stelen, en remote mbv je cookie als 'authorized' naar je site surfen.

[ Voor 49% gewijzigd door soulrider op 01-05-2008 21:07 ]

[user109731]

Wat sla je op in de cookie? Een cookie waarin je opslaat of iemand is ingelogd is onveilig. Alternatief is om een random id te maken die je dan op de server koppelt aan een user_id ofzo.

[Verwijderd]

Oké dan post ik de hele script even, ik hoop maar dat het erop kan, want het is erg groot.

[Verwijderd]

-weg ermee-

[ Voor 99% gewijzigd door Verwijderd op 01-05-2008 21:10 ]

[soulrider]

enkel het sessie/cookie-stuk is nodig en gebruik aub de [ code ] - tags ...
dan kunnen wij makkelijk naar regelnummers verwijzen

en door je sql-statements zie ik al dat ik een sql-injectie kan doen als ik in de cookie het userid aanpas naar een sql-statement ...

alle input die van een client komt controleren: vertrouw nooit iets van een client, en stuur het zeker nooit zonder controle/escaping naar je database...

in de cookie als userid "; drop table users;" zetten is al genoeg om die tabel kwijt te geraken op jouw database. en de user id vind ik zo met even de http-requests enzo te loggen mbv "live http headers" van FF. dan is het even cookie openen en aanpassen en voila: dada tabel of database.

[ Voor 78% gewijzigd door soulrider op 01-05-2008 21:14 ]

[Verwijderd]

Omg... Doe anders even

code:

[code] code [/code]

tags enzo. Controle voor op je script is hier op GoT ook niet gewenst verder.

[XangadiX]

Dit klinkt een beetje als werving, en het hele script laten zien is ook wat overdreven; als je nu alleen de delen post die relevant zijn (in dit geval het inlezen en uitlezen van het koekje bijvoorbeeld) dan wil ik het wel toestaan. Anders is dit topic niets meer dan een ordinair scriptrequest of een "kan iemand even...".

Probeer zo duidelijk mogelijk uit te leggen wat volgens jou de problemen zijn en wat je zelf hebt geprobeerd om het op te lossen.

update
te laat gepost... 700 regels aan code zijn dus niet de bedoeling, alleen de relevante stukken graag, met wat uitleg en eventueel een linkje naar de daadwerkelijke site.

update 2
Het wordt een beetje slowchat zo he
Maar goed, probeer het zo netjes en duidelijk mogelijk uit te leggen dus

wat doet het script eigenlijk?

[ Voor 28% gewijzigd door XangadiX op 01-05-2008 21:12 ]

[Verwijderd]

Hmm, ik zelf heb geen één probleem hoor, maar iemand op mijn msn liet mij twijfelen of de script wel echt degelijk veilig is... Ik zal proberen het stukje van de cookie op te zoeken.

Volgens mij is het dit stukje:

[ Voor 139% gewijzigd door Verwijderd op 01-05-2008 22:22 ]

[XangadiX]

Ik bedenk me trouwens net dat PHP geen client side scripting is dus ik schop het topic naar Programming.

Het script is trouwens best een beetje veilig, dat wil zeggen als iemand achter een computer zit van iemand met een wachtwoord (en dus koekjes) dan kan hij toegang krijgen, maar zo op het eerste gezicht lukt dat je niet 'zomaar' van iedere computer af.

[ Voor 55% gewijzigd door XangadiX op 01-05-2008 21:16 ]

[J3roen]

Paste je code anders gewoon hier. Maar naar mijn mening moet je toch zelf kunnen beoordelen of het hackbaar is. Iets meer zelfvertrouwen dus .

Ok, ik zie nu een stukje code staan.

Lol.. Je zet het login/wachtwoord in de cookie? Denk je zelf dat dat veilig is? Tip: doe eens wat onderzoek naar sessions.

[ Voor 31% gewijzigd door J3roen op 01-05-2008 21:17 ]

[soulrider]

je bent dus vatbaar voor cookie-replay.

hou een bv extra table bij waar je je cookie's logt mbv bv een md5-hash van die cookie
als de gebruiker dan uitlogt, delete je die rij in die table. of gebruik daarin een extra rij: 'still valid': true/false)
komt dan nadien die zelfde cookie langs, dan kan je dat nog eens apart loggen als mogelijke aanvaller.

hier op tweakers kan je bv bij uitloggen al je openstaande sessie's nog zien en vanaf de pc waaraan je zit sluiten - of enkel de huidige sluiten

en tip 3 staat hier boven: kan je combineren met de tip hier boven: gebruik sessie-id's en hou die apart ook bij op geldigheid.

[ Voor 37% gewijzigd door soulrider op 01-05-2008 21:22 ]

[Kwastie]

mischien ipv $_COOKIE $_SESSION gaat gebruiken? session is server side, cookie niet.
Wat inhoud dat je een cookie kunt wijzigen en een session niet, zie een session maar als een cookie op de server. (dat is het niet, maar zo werkt het wel)

En gooi NOOIT maar dan ook NOOIT een wachtwoord in een session of cookie !!!!!!

[ Voor 15% gewijzigd door Kwastie op 01-05-2008 21:25 ]

[NMe]

Waarom probeer je niet te [google=php website security common hacking methods]? Je zoekt nu in feite niet meer iemand die je helpt met programmeren, maar je zoekt wel iemand die het testen en bugfixen voor je doet...

Kwastie schreef op donderdag 01 mei 2008 @ 21:23:
mischien ipv $_COOKIE $_SESSION gaat gebruiken? session is server side, cookie niet.
Wat inhoud dat je een cookie kunt wijzigen en een session niet, zie een session maar als een cookie op de server. (dat is het niet, maar zo werkt het wel)

Hoe dacht je dat je sessie-ID 99 van de 100 keer opgeslagen wordt?

[ Voor 49% gewijzigd door NMe op 01-05-2008 21:25 ]

[Verwijderd]

Damn, jullie zitten echt in een gevorderd niveau, ik snap totaal niets wat jullie zeggen Kan het iemand nu even uitleggen zoals je tegen een kind van 6 jaar uitlegd aub?

[Kwastie]

Je hebt gelijk, sessions zijn gewoon server-side cookies. Alleen met een 'vaste' levensduur, en zelfs dat klopt nog niet eens.

hier: http://rafb.net/p/RyMSMF94.html (zo ziet mijn login systeem eruit )

tip: Koop een boek over PHP

[ Voor 10% gewijzigd door Kwastie op 01-05-2008 21:43 ]

[NMe]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:29:
Damn, jullie zitten echt in een gevorderd niveau, ik snap totaal niets wat jullie zeggen Kan het iemand nu even uitleggen zoals je tegen een kind van 6 jaar uitlegd aub?

Veel simpeler dan dit wordt het niet. Wat begrijp je precies niet?

[Verwijderd]

Ik denk dat ik het gewoon niet begrijp omdat ik niet goed ben in php schrijven. Ben nog maar een beginner. Ik heb daarnet nog wat rondgekeken naar de andere scripts en ik vond wel van die $_SESSION dingetjes, dus er werd wel over sessions gedacht. Volgens mij lijkt het mij wel veilig.

[Verwijderd]

En als ik nou SQL commandos in mijn cookie ga typen? Bijvoorbeeld "Naam"; delete from everything als gebruikersnaam?
Sla nooit wachtwoorden op in cookies. Dat kan altijd wel op een of andere manier gehackt worden.
Waarom gebruik je niet een bestaand login systeem dat al getest is? Ik ben zelf geen PHP programmeur, maar er bestaat vast wel een OpenID API of iets dergelijks.

[NMe]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:42:
Ik denk dat ik het gewoon niet begrijp omdat ik niet goed ben in php schrijven.

Je begrijpt "het" niet. Wat is "het"? Over wiens post heb je het en waar heb je precies moeite mee? Als je niet eens aan kan geven wat je niet begrijpt, dan kunnen wij je ook niet helpen.

[Verwijderd]

Hmm waar kan ik mijn cookies vinden? Ik wil het wel eens zien of mijn wachtwoord er echt instaat.

[Verwijderd]

-NMe- schreef op donderdag 01 mei 2008 @ 21:49:
[...]

Je begrijpt "het" niet. Wat is "het"? Over wiens post heb je het en waar heb je precies moeite mee? Als je niet eens aan kan geven wat je niet begrijpt, dan kunnen wij je ook niet helpen.

Die sessions enzo... ik weet niet eens hoe ik dat moet in één scripten...

[simon]

Maybe wat PHP tutorials volgen en inlezen? Anders kunnen we dat allemaal gaan uitleggen...

[soulrider]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:50:
Hmm waar kan ik mijn cookies vinden? Ik wil het wel eens zien of mijn wachtwoord er echt instaat.

die vind je in je "temporary internet files"-folder als text bestand.
(of via je cookie-beheerder van je bowser als dat niet IE is)

en zoek even rond op 'sessie-beheer', 'sql-injection', 'replay-attacks', 'stelen van cookie',...
je gaat ogen-opende-informatie vinden, en zo merk je dat scripting door velen kan gedaan worden, maar als het echt veilig moet er vaak veel meer werk moet gedaan worden.

(zoals escapen van speciale tekens, het voorkomen van overflows en code-/sql-injectie's, ....)

wederom je bezokers kan je misschien vertrouwen als het beste vrienden zijn, maar de onbekende bezoekers en spammers doen veel wat slecht kan aflopen voor je site.
idioot-proof maken kan vrij makkelijk, hackerproof niet zo makkelijk.

(sessie-id is ook misbruiker via het aanpassen van de verstuurde headers, en dat is zo scriptbaar - ik heb voor mijn script-tests een php-proxy ergens draaien waarmee ik makkelijk headers kan zien, aanpassen en terugspelen, alsook cookie's - maar die is enkel voor eigen scripts of die van maten te testen, heel soms een snelle test op gespamde site's ;-) )

[ Voor 36% gewijzigd door soulrider op 01-05-2008 21:59 ]

[Hobbles]

Ook een optie is om het IP-adres aan een cookie te koppelen in je database. Als iemand met hetzelfde sessie-ID (zelfde cookie dus) inlogt vanaf een ander IP, dan laat je die gebruiker niet toe alvorens opnieuw in te loggen. Dit is echter alleen beveiliging als ze niet op hetzelfde netwerk (zelfde IP) zitten. Maar de kans op cookie stealing is al een pak kleiner.

Als je meer wil weten over web security is dit een goede start plek: http://code.google.com/edu/security/index.html

[NMe]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:50:
[...]

Die sessions enzo... ik weet niet eens hoe ik dat moet in één scripten...

Overal waar nu $_COOKIE staat schrijf je $_SESSION, et voilà.

[simon]

http://nl3.php.net/manual/en/function.session-start.php niet vergeten...

[Verwijderd]

@Hobbles: Ik zou die link van google zelf ook ff lezen als ik jou was.
Wat als je een dynamisch IP hebt, en wat als er meerdere computers achter 1 IP zitten?

@BitKing: Ik zou toch echt de code van een bestaande API gebruiken en niet zelf gaan knutselen als je een echt veilige site nodig hebt. En anders zul je toch echt naar de boekhandel moeten gaan en een paar dikke pillen moeten kopen over security in algemeenheid. Wat -NMe- zegt klopt waarschijnlijk wel, maar als je weinig van beveiliging weet, kun je nooit garanderen dat je site in de toekomst ook veilig blijft.
Als je niet weet waar hackers zich mee bezig houden, kun je ook niet weten of je aan alles hebt gedacht om je site te beveiligen.

[Hobbles]

Verwijderd schreef op donderdag 01 mei 2008 @ 23:45:
@Hobbles: Ik zou die link van google zelf ook ff lezen als ik jou was.
Wat als je een dynamisch IP hebt, en wat als er meerdere computers achter 1 IP zitten?

Dynamisch IP verandert niet om de minuut hoor. Eerder na 36uur of meer. Meerdere computers achter 1 IP is het probleem dat ik zelf al aangaf (even beter lezen dus). Meerdere sessie ID's kunnen hetzelfde IP hebben in de database als je dat bedoelde... ;-) Ik gaf het trouwens enkel mee als optie voor de TS.

Hoe kom je er trouwens bij dat ik die link niet bekeken heb

[Verwijderd]

Je kan ook achter een echt dynamisch IP zitten, bijvoorbeeld een drukke loadbalanced verbinding, dan kan je IP gerust van request tot request wisselen.

[GlowMouse]

Verwijderd schreef op donderdag 01 mei 2008 @ 20:53:
Alleen kreeg ik daarnet iemand op msn en die zei dat ik het niet goed heb gedaan, want nu is het hackbaar omdat ik cookies heb gebruikt

Hoe wist diegene dat je cookies gebruikte? Dat blijkt niet uit het andere topic.

-NMe- schreef op donderdag 01 mei 2008 @ 22:13:
[...]

Overal waar nu $_COOKIE staat schrijf je $_SESSION, et voilà.

session_start()

[Hydra]

Verwijderd schreef op donderdag 01 mei 2008 @ 21:50:
Hmm waar kan ik mijn cookies vinden? Ik wil het wel eens zien of mijn wachtwoord er echt instaat.

Alles wat je in cookies zet wordt rechtstreeks op je harde schijf opgeslagen, en kan gewoon met notepad geedit worden.

Verwijderd schreef op vrijdag 02 mei 2008 @ 00:41:
Je kan ook achter een echt dynamisch IP zitten, bijvoorbeeld een drukke loadbalanced verbinding, dan kan je IP gerust van request tot request wisselen.

Daar heb je dan mechanismen voor, dan wordt sessie informatie meestal (al dan niet transparant) in een DB opgeslagen.

[ Voor 36% gewijzigd door Hydra op 02-05-2008 01:02 ]

[RobIII]

Hydra schreef op vrijdag 02 mei 2008 @ 01:01:
Daar heb je dan mechanismen voor, dan wordt sessie informatie meestal (al dan niet transparant) in een DB opgeslagen.

Dat is aan de server-kant; TRRoads doelde op de client kant. Echter boeit dat ook niet want bij ieder request word een sessie-id meegegeven door de browser en dus maakt het geen fluit uit van welk IP iets komt (normaliter). Als je een sessie aan een IP gaat koppelen ga je inderdaad de boot in dan. Dat sessie-id is in principe (en wat kort door de bocht) alles wat een sessie behelst. Omdat HTTP stateless is krijg je dat soort constructies.

[ Voor 16% gewijzigd door RobIII op 02-05-2008 01:09 ]

[Hydra]

RobIII schreef op vrijdag 02 mei 2008 @ 01:07:
Dat is aan de server-kant; TRRoads doelde op de client kant.

Ah, daar had ik geen rekening mee gehouden, verwachtte dat hij wel snapte dat er gewoon een sessie ID meegaat met elk request.

[Verwijderd]

GlowMouse schreef op vrijdag 02 mei 2008 @ 00:46:
[...]

Hoe wist diegene dat je cookies gebruikte? Dat blijkt niet uit het andere topic.


[...]

session_start()

Er staat inderdaad boven mijn elke script een session_start();

Acht wat maak ik mij toch allemaal druk over.... mijn scripts zijn echt wel veilig, ik heb het 2 jaar gebruikt op een andere site die goed ging en werd geen 1 keer gehackt terwijl er wel mensen waren die het geprobeerd hadden en het hun niet lukte.

Ohja, op de eerste pagina zei iemand dat het wachtwoord in een cookie wordt opgeslagen. Wel, die staan gewoon gecodeerd met meer dan 7 letters en cijfers code.... Als je zoiets kan kraken moet je wel een echte pro hacker zijn.

[ Voor 17% gewijzigd door Verwijderd op 02-05-2008 10:59 ]

[RobIII]

Verwijderd schreef op vrijdag 02 mei 2008 @ 10:56:
Acht wat maak ik mij toch allemaal druk over.... mijn scripts zijn echt wel veilig, ik heb het 2 jaar gebruikt op een andere site die goed ging en werd geen 1 keer gehackt terwijl er wel mensen waren die het geprobeerd hadden en het hun niet lukte.

Ja, dat is een maatstaaf om de conclusie op te baseren dat je script veilig is.

Verwijderd schreef op vrijdag 02 mei 2008 @ 10:56:
Ohja, op de eerste pagina zei iemand dat het wachtwoord in een cookie wordt opgeslagen. Wel, die staan gewoon gecodeerd met meer dan 7 letters en cijfers code.... Als je zoiets kan kraken moet je wel een echte pro hacker zijn.

Een XOR of ROT13 'encryptie' heeft een beetje amateur hacker ook zo in de smiezen en 'gekraakt'. 'Gecodeerd met 7 letters en cijfers code' zegt he-le-maal niks.

[Verwijderd]

Verwijderd schreef op vrijdag 02 mei 2008 @ 10:56:
[...]
Ohja, op de eerste pagina zei iemand dat het wachtwoord in een cookie wordt opgeslagen. Wel, die staan gewoon gecodeerd met meer dan 7 letters en cijfers code.... Als je zoiets kan kraken moet je wel een echte pro hacker zijn.

7 tekens is niks. Rainbow tables voor md5 zijn iig t/m 14 tekens verkrijgbaar. Dan heb je jouw 7 tekens tellende wachtwoord binnen een seconde.

Ookal is een wachtwoord gecodeerd, dien je het alsnog niet op te slaan aan de client kant.

[ Voor 13% gewijzigd door Verwijderd op 02-05-2008 13:19 ]

[kokx]

Verwijderd schreef op vrijdag 02 mei 2008 @ 00:41:
Je kan ook achter een echt dynamisch IP zitten, bijvoorbeeld een drukke loadbalanced verbinding, dan kan je IP gerust van request tot request wisselen.

Daarom bied ik gebruikers de mogelijkheid om IP controle voor een sessie uit te zetten (zoals t.net ongeveer ook doet). Dit is dan misschien wel onveiliger, maar als je je gebruikers er voor waarschuwt, en je het niet gebruikt bij je eigen account, dan is de beveiliging voldoende.

[EnsconcE]

Verwijderd schreef op vrijdag 02 mei 2008 @ 10:56:
[...]

Er staat inderdaad boven mijn elke script een session_start();

Acht wat maak ik mij toch allemaal druk over.... mijn scripts zijn echt wel veilig, ik heb het 2 jaar gebruikt op een andere site die goed ging en werd geen 1 keer gehackt terwijl er wel mensen waren die het geprobeerd hadden en het hun niet lukte.

Ohja, op de eerste pagina zei iemand dat het wachtwoord in een cookie wordt opgeslagen. Wel, die staan gewoon gecodeerd met meer dan 7 letters en cijfers code.... Als je zoiets kan kraken moet je wel een echte pro hacker zijn.

Misschien dat je hier even naar wil kijken
crisp in "[PHP] BeveiligingsTips nodig"

Overigens is het verstandig jezelf eerst in te lezen voordat je ergens aan begint. Vooral wanneer je het gaat hebben over beveiliging van je website dien je op de hoogte te zijn van de mogelijkheden. Je hoeft zelf geen hacker te zijn, als je maar weet waar een gat kan zitten.

[Verwijderd]

@Hobbles: Het was misschien een iets te cynische opmerking dat je die link niet gelezen zou hebben. In iedergeval beschrijft google 3 manieren om de uniekheid van een gebruiker te vergelijken en er zijn er maar 2 genoemd.
Ik erger me aan de handelswijze van veel (PHP) programmeurs wat veiligheid betreft. Eerst beginnen met coden, daarna pas kijken hoe beveiliging eigelijk zou moeten werken. Ik heb voor mijn werk vaak code moeten verbeteren van anderen waaruit bleek dat ze niet eens de moeite hebben genomen om "beveliging voor dummy's" of iets dergelijks te lezen. Om een veilige site te bouwen kun je 2 dingen doen:
- je verdiepen in beveiliging en zelf iets bedenken
- een bestaande veilige methode gebruiken

Helaas wordt er vaak door (PHP) programmeurs gekozen voor een andere methode:
- iets proberen en er vanuit gaan dat het werkt, totdat je gehacked bent.

Op die laatste manier loop je dus achter de feiten aan.

PHP is een taal met een grote open source community. Haal daar je log in gedoe vandaan en stop met het produceren van troep.

Sorry, ik ben enigzins gefrustreerd door de PHP code die ik de afgelopen maand tegen ben gekomen.
Ik kan maandag wel wat code die ik ben tegenkomen posten met voorbeelden hiervan.

[ Voor 3% gewijzigd door Verwijderd op 02-05-2008 23:33 ]