[PHP]Veilig scripten

[Verwijderd]

Hallo allemaal,

Ik heb de laatste tijd diverse topics, posts en websites bekeken over het veilig scripten in PHP. Het enige probleem is dat elke site net iets anders vertelt wat veilig is. Dus nu is mijn vraag wat is er nu echt veilig, hoe voer ik bijvoorbeeld een veilige query in een GET of POST uit...

Wat ik momenteel doe voer login bijvoorbeeld is:
1. Gebruiker z'n gebruiksnaam in tex en wachtwoord in password input veld laten invoeren.
2. Dit posten naar dezelfde pagina
3. Het wachtwoord md5en
4. addslashes op de username en password (bij POST) en dan de query op die variablen... ("SELECT * FROM users WHERE username='$username' AND password='$password'");
5. Als de gegevens goed zijn een cookie met de gebruikersnaam en een cookie met het geëncrypte md5 wachtwoord neerzetten.
6. Dit wordt geverifieerd op elke pagina...

Bij een GET maak ik momenteel gebruik van escaping door " ' . $blabla . ' " te gebruiken...is dit veilig of kan dit beter?

[MBV]

met addslashes zit je wel redelijk veilig. Vergeet niet magic_quotes_gpc uit te zetten, die doet dat namelijk ook.
Wat beter is: bijv adodb gebruiken ipv de standaard mysql interface, daar zitten escape functies in specifiek voor sql. Je kan namelijk in theorie een quote coderen op een manier die mysql wel snapt, iets als #25 (weet het goede nummer niet meer), en dat is nou juist datgene waar adodb wel aan denkt.

Maar zijn hier niet al 100.000 boekwerken over geschreven?

edit:
of je ziet met je duffe kop een security hole waar een vrachtwagen doorheen kan over het hoofd

[ Voor 16% gewijzigd door MBV op 12-11-2006 23:18 ]

[Erkens]

Als eerste zou ik stap 4 de "addslashes" vervangen voor een beter alternatief, voor mysql bijvoorbeeld de functie mysql_real_escape_string waarmee je vrij zeker weet dat ranzige rommel niet je query verziekt.
Daarna is stap 5 slecht, waarom iedere keer dat password weer mee sturen? Of het nu md5'ed is of niet maakt niet uit, je kan er immers mee inloggen Gebruik liever sessions waarmee enkel een uniek id in je cookie hoeft te staan.

[CodeCaster]

Ik gebruik zelf de volgende functie voor het opvragen van POST-variabelen:

PHP:

/* =================================================================
GetPOST
cleans up a POST variable
================================================================= */
function GetPOST($postvar, $defvar) {
    if (isset($_POST[$postvar])) {
        if (!empty($_POST[$postvar])) {
            $toreturn = htmlspecialchars($_POST[$postvar]);
            if (get_magic_quotes_gpc() == 1) {
                return $toreturn;
            } else {
                return addslashes($toreturn);
            }
        } else {
            return $defvar;
        }
    }
    else {
        return $defvar;
    }
}

Misschien zijn er nog andere functies in te gebruiken, zoals mysql_real_escape_string of zo.

[Verwijderd]

Zolang je input als $username = 'jantje; drop table users --' (MSSQL voorbeeld, MySQL heeft vast ook wel vergelijkbare injections) niet afvangt heeft escapen m.i. nauwelijks zin.
Geparametriseerde queries is the way to go als je 't veilig aan wilt pakken.

[Verwijderd]

Oke bedankt voor de tips allemaal ik ga die mysql_real_escape_string toepassen op de queries.
Hoe kan ik verder met session id's werken om login gegevens te verifieren?

[Mac_Cain13]

Verwijderd schreef op zondag 12 november 2006 @ 23:42:
[...]
Hoe kan ik verder met session id's werken om login gegevens te verifieren?

Als je even de literatuur op php.net doorleest moet je het sessie systeem met session id's wel aardig doorkrijgen waarschijnlijk. Overigens moet je met Google ook nog wel wat werkende php session voorbeeldjes kunnen vinden.

[Verwijderd]

Verwijderd schreef op zondag 12 november 2006 @ 23:26:
Zolang je input als $username = 'jantje; drop table users --' (MSSQL voorbeeld, MySQL heeft vast ook wel vergelijkbare injections) niet afvangt heeft escapen m.i. nauwelijks zin.
Geparametriseerde queries is the way to go als je 't veilig aan wilt pakken.

escapen betekent dat je ' e.d. onschadelijk maakt. Je vangt het dus af...

[Paul]

Verwijderd schreef op zondag 12 november 2006 @ 23:10:
Wat ik momenteel doe voer login bijvoorbeeld is:
1. Gebruiker z'n gebruiksnaam in tex en wachtwoord in password input veld laten invoeren.
2. Dit posten naar dezelfde pagina
3. Het wachtwoord md5en

is dit veilig of kan dit beter?

Daar gaat het al fout Dit is gevoelig voor replay, en hoewel je je wachtwoord wel md5t doe je dit zo te zien serverside, en daar is het nut al mee verloren...

1: sessie-ID en een salt (willekeurige string die je serverside ook opslaat) meesturen. Je zou als salt ook je sessie-ID kunnen gebruiken) meesturen naar de client. Sessie-ID en salt serverside in de database zetten.
2: Op de client het wachtwoord md5en, salt eraan vast plakken, dit weer md5en
3: sessie-ID, username en md5(salt+md5(ww)) naar server posten. Zorg er wel voor dat je het password-veldje van je form leeghaalt/je nieuwe passwordstring hierin zet, anders gaat je password alsnog plaintext over de lijn afaik.
4: serverside kijken of sessie-ID bestaat, eventueel controleren of IP en useragent nog hetzelfde zijn (dan moet je ze in stap 1 dus ook opslaan).
5: als sessie-ID klopt dmv username de md5 van het wachtwoord uit je DB ophalen ("select password from users where username=?"), salt eraanvast, weer md5en, kijken of het overeen komt met wat de client mee heeft gestuurd.

Waarom, als je er de salt aan vastplakt en dan (nogmaals) md5t, het wachtwoord ook md5en? Kraakt men je DB dan kan men toch overal mee inloggen (als dat nog nodig zou zijn dan )? Omdat veel mensen hun username en password op meerdere sites gebruiken In mijn geval gaat het niet op, maar uit mijn sig blijkt dat ik op Samenkopen.net rondloop. Zou je nu hier of daar de DB kraken dan zou ook meteen mijn andere account gecompromiteerd zijn. Is dus ook eerder damage control dan wat anders, maar het kost je 3 seconden programmeren en 0,0007 seconden extra rekenen per inlog dus waarom niet

Edit: Als je parameters gebruikt hoef je afaik niet meer te escapen, tenzij je server een brakke parameterimplementatie (lees dan: stringconcatenatie ) heeft.

[ Voor 3% gewijzigd door Paul op 13-11-2006 00:09 ]

[EdwinG]

Verwijderd schreef op zondag 12 november 2006 @ 23:10:
3. Het wachtwoord md5en
4. addslashes op de username en password (bij POST) en dan de query op die variablen... ("SELECT * FROM users WHERE username='$username' AND password='$password'");

Als je eerst een md5 van een wachtwoord neemt, hoeft volgens mij deze niet met addslashes bewerkt te worden, aangezien een md5 alleen uit cijfers + letters bestaat.

[MIster X]

Paul Nieuwkamp schreef op maandag 13 november 2006 @ 00:08:
2: Op de client het wachtwoord md5en, salt eraan vast plakken, dit weer md5en

Clientside? Hoe doe je dat?

[crisp]

MIster X schreef op maandag 13 november 2006 @ 00:31:
[...]

Clientside? Hoe doe je dat?

http://www.pajhome.org.uk/crypt/md5/
Dat gebruiken wij hier ook voor het encrypted inloggen

[ Voor 13% gewijzigd door crisp op 13-11-2006 00:33 ]

[disjfa]

MIster X schreef op maandag 13 november 2006 @ 00:31:
[...]
Clientside? Hoe doe je dat?

Javanscript.

[Verwijderd]

Hoe kun je dan een sessie id ophalen/aanspreken... Ik heb net wat zitten lezen over sessies (al wel eerder gebruikt, maar niet zo geavanceerd ) en gezien als je er 1 registreert dat deze op de server opgeslagen wordt maar zodra je de browser sluit deze opnieuw opstart en naar dezelfde link gaat wordt er een nieuwe sessie geceeërd en wordt de oude niet meer gebruikt....

[ Voor 6% gewijzigd door Verwijderd op 13-11-2006 00:38 ]

[Erkens]

EdwinG schreef op maandag 13 november 2006 @ 00:18:
[...]

Als je eerst een md5 van een wachtwoord neemt, hoeft volgens mij deze niet met addslashes bewerkt te worden, aangezien een md5 alleen uit cijfers + letters bestaat.

regel 1: (user)input is nooit te vertrouwen
overigens moet je zoals als meerdere keren is genoemd, addslashes niet gebruiken maar als je wilt escapen de juiste functie voor je doel gebruiken, addslashes is typisch een voorbeeld van een functie die bijna nooit nuttig is...

[MIster X]

crisp schreef op maandag 13 november 2006 @ 00:33:
http://www.pajhome.org.uk/crypt/md5/
Dat gebruiken wij hier ook voor het encrypted inloggen

Waarop ik me verwonderde: jama als javascript dan uitstaat... Maar dat wordt in de link ook beantwoord. Bedankt, nuttige informatie!

JavaScript is not always enabled - either because a cut-down browser doesn't support it, or because the user has chosen to disable it. In this case, encrypted login will not be possible. There are two options for behaviour in this case - either block the login, or allow it to proceed unencrypted. This is a security vs usability tradeoff, different sites will make different choices, although I generally favor allowing the unencrypted login.

To permit an unencrypted login, we need to make a slight change to the login form. Add a hidden field "password_hash" and code the JavaScript to populate that with the hash, and blank the password field. If the server receives a login without a password_hash, JavaScript must be disabled. The server checks the password field instead.

[Paul]

MIster X schreef op maandag 13 november 2006 @ 10:30:
Waarop ik me verwonderde: jama als javascript dan uitstaat... Maar dat wordt in de link ook beantwoord. Bedankt, nuttige informatie!

Dat is 1 klik verder, in de hele nuttige en zeer uitgebreide uitleg over een veilig login systeem

[Janoz]

Verwijderd schreef op zondag 12 november 2006 @ 23:10:
Ik heb de laatste tijd diverse topics, posts en websites bekeken over het veilig scripten in PHP. Het enige probleem is dat elke site net iets anders vertelt wat veilig is.

Het belangrijkste van het doorlezen van dergelijke artikelen en posts is niet wat niet secure is, maar waarom dat niet secure is. Dan zul je zien dat al die artikelen en postings allemaal hetzelfde zeggen. Begrijpen waarom iets zo is maakt het een stuk makkelijker toepasbaar dan aannemen dat iets zo is.

Bekijk naast de regeltjes als 'REQUEST vars escapen' ook eens naar de exploits die gebruikt worden. Vaak zie je dan ook waarom die regeltjes gelden.

Als iedereen maar een stapeltje dingen aanneemt krijg je van die vreemde constructies waarbij mensen een html_special_chars over hun input heenhalen voordat het de database in gaat.

[mithras]

Paul Nieuwkamp schreef op maandag 13 november 2006 @ 00:08:
[...]

Daar gaat het al fout Dit is gevoelig voor replay, en hoewel je je wachtwoord wel md5t doe je dit zo te zien serverside, en daar is het nut al mee verloren...

[een aantal stappen]

Waarom, als je er de salt aan vastplakt en dan (nogmaals) md5t, het wachtwoord ook md5en? Kraakt men je DB dan kan men toch overal mee inloggen (als dat nog nodig zou zijn dan )? Omdat veel mensen hun username en password op meerdere sites gebruiken In mijn geval gaat het niet op, maar uit mijn sig blijkt dat ik op Samenkopen.net rondloop. Zou je nu hier of daar de DB kraken dan zou ook meteen mijn andere account gecompromiteerd zijn. Is dus ook eerder damage control dan wat anders, maar het kost je 3 seconden programmeren en 0,0007 seconden extra rekenen per inlog dus waarom niet

Volgens mij is het principe van md5 dat op elkaar lijkende strings een zo verschillend mogelijke hash krijgen. Een md5(md5(md5(iets))) is dus onveiliger dan een md5(iets). Dat je tussendoor nog iets toevoegt lijkt me niet significant uit te maken.
Verder hoort je wachtwoord gewoon in een hash in je tabel te staan. Ben je net zo veilig imho.

Wat ik verder lees in de ook voor mij nuttige bijdrage, is dat ook clientside een md5 hash wordt gemaakt. Vergroot het je veiligheid? Het enige wat je hierdoor voorkomt is dat het wachtwoord niet onversleuteld naar je server wordt gestuurd. Het kán dus onderschept worden tijdens je POST. Maar hoe groot is die kans?

Wat ik verder doe met mijn inlogsysteem wat ik nu ontwikkel (dus nog niet helemaal compleet):
Op elke pagina:

1. Bestaat er een cookie met een sessie id en ip adres? Zo ja, een gebruiker wil dat hij/zij ingelogd blijft en ga naar stap 3
2. Bestaat er een sessie die een sessie id bevat? Zo ja, gebruiker is ingelogd (en controleer verder), zo nee, gebruiker is een gast (doe dan verder niets)
3. Check sessie id met de opgeslagen sessie-id in de database. In de sessie tabel staat ook het ip en het user id opgeslagen. Komen ip's overeen, dan kan je gebruikers instellingen laden via je user-id

Bij inloggen:

1. POST wachtwoord + gebruikersnaam
2. md5 wachtwoord en kijk of md5(wachtwoord)/username combinatie in user tabel voorkomt
3. Zo ja, creer een sessie id, sla sessie id+ip+user id op in sessie tabel van database, maak een session aan die sessie id bevat.

Voor extra veiligheid wil ik misschien het wachtwoord of de sessie salten, maar deze opzet is een stuk makkelijker, en volgens mij even veilig als de eerder voorgestelde maatregelen.

De enige kwestie waar nog problemen mee kunnen ontstaan is als je handmatig een cookie aanmaakt. Je eigen ip komt overeen met het ip van een sessie in de database en je weet het sessie id die in de database staat. Dan kan je inloggen onder die gebruiker. Wellicht dan een salt of desnoods je ip hashen de oplossing hiervoor biedt. Maar volgens mij is deze methode bijna net zo veilig als het 100 stappen plan eerder gepost

edit:
Nu ik het teruglees: dit is niet een verkapte "maak mijn inlog systeem veiliger". Ik denk alleen dat "overveiligheid" niet nodig is, aangezien het imho alleen maar je code ingewikkelder maakt. Verder lees ik op aangehaalde sites dat als geen js aan staat, je misschien ook geen form moet tonen... tja. dat vind ik dan weer not done

[ Voor 5% gewijzigd door mithras op 13-11-2006 11:19 ]

[Tanuki]

Deze functie gebruik ik standaard in elk script:

PHP:

<?php
if (get_magic_quotes_gpc() == 1)
{
    function undo_magic_quotes_gpc($pmVariable)
    {
        if (is_array($pmVariable))
        {
            return array_map('undo_magic_quotes_gpc', $pmVariable);
        }
        else
        {
            return stripslashes($pmVariable);
        }
    }
    $_GET = undo_magic_quotes_gpc($_GET);
    $_POST = undo_magic_quotes_gpc($_POST);
    $_COOKIE = undo_magic_quotes_gpc($_COOKIE);
    $_REQUEST = undo_magic_quotes_gpc($_REQUEST);
}
?>

Vervolgens doe ik in query's altijd addslashes() over de data en bij het printen van data altijd htmlspecialchars().

Bij het kijken of ID's bestaan (in de URL bijv.) doe ik ook altijd een preg_match('/^([0-9]+)$/is', ...) om te kijken of het ook echt een getal is. Helaas wil ik daar nog wel eens de ^ en $ vergeten.


Maar volgens mij is bovenstaand veilig genoeg, niet dan?

[Voutloos]

mithras86 schreef op maandag 13 november 2006 @ 11:13:
[...]
Volgens mij is het principe van md5 dat op elkaar lijkende strings een zo verschillend mogelijke hash krijgen. Een md5(md5(md5(iets))) is dus onveiliger dan een md5(iets). Dat je tussendoor nog iets toevoegt lijkt me niet significant uit te maken.

Beetje rare gevolgtrekking. Meerdere keren hashen is niet per se minder veilig. Verder wil je dus meerdere keren hashen: je wil een hash opslaan van het wachtwoord en je wil bij inloggen hashen om zo een mooi challenge-response systeem te kunnen maken welke niet vatbaar is voor replay attacks.

Wat ik verder lees in de ook voor mij nuttige bijdrage, is dat ook clientside een md5 hash wordt gemaakt. Vergroot het je veiligheid? Het enige wat je hierdoor voorkomt is dat het wachtwoord niet onversleuteld naar je server wordt gestuurd. Het kán dus onderschept worden tijdens je POST. Maar hoe groot is die kans?

Nee, je zorgt er ook voor dat in jouw DB niet het originele wachtwoord in plaintext staat. Dit beperkt de schade als de inhoud van je DB op straat komt te liggen. Overigens staat dit ook in het stuk dat je quote.

l0c4lh0st schreef op maandag 13 november 2006 @ 11:46:
Bij het kijken of ID's bestaan (in de URL bijv.) doe ik ook altijd een preg_match('/^([0-9]+)$/is', ...) om te kijken of het ook echt een getal is. Helaas wil ik daar nog wel eens de ^ en $ vergeten.

Dit werkt en het is goed dat je dit soort zaken checkt, maar het kan gewoon veel eenvoudiger: Als iets een geheel getal moet zijn, cast het dan gewoon naar een int.

[Woy]

Als je je wachtwoord clientside md5't dan moet je dat zeker ook met een salt doen die al serverside bepaald is. Anders stuur je elke keer dat de gebruiker inlogt precies dezelfde md5. Als je dan die md5 opstuurt dan kan je daar ook gewoon mee inloggen en het is dus ( bijna ) net zo onveilig als gewoon het clear-text pasword over de lijn sturen. Het enige wat je er mee op schiet is dat de hacker je wachtwoord niet heeft.

[crisp]

rwb schreef op maandag 13 november 2006 @ 11:56:
Als je je wachtwoord clientside md5't dan moet je dat zeker ook met een salt doen die al serverside bepaald is. Anders stuur je elke keer dat de gebruiker inlogt precies dezelfde md5. Als je dan die md5 opstuurt dan kan je daar ook gewoon mee inloggen en het is dus ( bijna ) net zo onveilig als gewoon het clear-text pasword over de lijn sturen. Het enige wat je er mee op schiet is dat de hacker je wachtwoord niet heeft.

True, wij salten met het huidige sessie-id; na inloggen krijgt de client vervolgens een nieuw sessie-id.

[Verwijderd]

mithras86 schreef op maandag 13 november 2006 @ 11:13:
Bij inloggen:

1. POST wachtwoord + gebruikersnaam
2. md5 wachtwoord en kijk of md5(wachtwoord)/username combinatie in user tabel voorkomt
3. Zo ja, creer een sessie id, sla sessie id+ip+user id op in sessie tabel van database, maak een session aan die sessie id bevat.

Voor extra veiligheid wil ik misschien het wachtwoord of de sessie salten, maar deze opzet is een stuk makkelijker, en volgens mij even veilig als de eerder voorgestelde maatregelen.

Klinkt interessant, maar wat als de gebruiker nou een dynamisch IP adres heeft, dan heb je toch kans dat de sessie niet meer werkt naar een reboot?

[Verwijderd]

Verwijderd schreef op maandag 13 november 2006 @ 12:02:
Klinkt interessant, maar wat als de gebruiker nou een dynamisch IP adres heeft, dan heb je toch kans dat de sessie niet meer werkt naar een reboot?

Een sessie is toch ook niet meer geldig zodra een een browser wordt afgesloten. Dus na een reboot wordt er van een gebruiker verwacht dat hij/zij opnieuw inlogt. Maar zo is het niet meer zo makkelijk om een sessie te stelen omdat deze aan een ip adres is gekoppeld.

[mithras]

Voutloos schreef op maandag 13 november 2006 @ 11:52:
[...]
Beetje rare gevolgtrekking. Meerdere keren hashen is niet per se minder veilig. Verder wil je dus meerdere keren hashen: je wil een hash opslaan van het wachtwoord en je wil bij inloggen hashen om zo een mooi challenge-response systeem te kunnen maken welke niet vatbaar is voor replay attacks.

Ik bedoel met meerdere keren hashen een hash maken van een md5 hash, om die vervolgens weer md5 te encoden. Natuurlijk moet je je password in de database als md5 hash opslaan (tijdens registratie), om vervolgens het verkregen wachtwoord over POST ook te hashen, en die beide strings te vergelijken

[...]
Nee, je zorgt er ook voor dat in jouw DB niet het originele wachtwoord in plaintext staat. Dit beperkt de schade als de inhoud van je DB op straat komt te liggen. Overigens staat dit ook in het stuk dat je quote.

Nee, zie hierboven. Het gaat om

code:

md5(md5(password) + md5(salt))

tov

code:

md5(password + salt)

rwb schreef op maandag 13 november 2006 @ 11:56:
Als je je wachtwoord clientside md5't dan moet je dat zeker ook met een salt doen die al serverside bepaald is. Anders stuur je elke keer dat de gebruiker inlogt precies dezelfde md5. Als je dan die md5 opstuurt dan kan je daar ook gewoon mee inloggen en het is dus ( bijna ) net zo onveilig als gewoon het clear-text pasword over de lijn sturen. Het enige wat je er mee op schiet is dat de hacker je wachtwoord niet heeft.

Dan heb ik eigenlijk de functie van 'secure inloggen' niet begrepen (en nu wel): het gaat alleen om te voorkomen dat een hacker de verzonden string (password of md5 van password) niet kan "begrijpen", doordat de string elke keer anders is door de salt die meegestuurt wordt. En alleen op dat punt zal de md5 hash clientside een extra beveiligingsmaatregel zijn.

Verwijderd schreef op maandag 13 november 2006 @ 12:02:
[...]
Klinkt interessant, maar wat als de gebruiker nou een dynamisch IP adres heeft, dan heb je toch kans dat de sessie niet meer werkt naar een reboot?

Tja, daar heb ik niet bij stil gestaan. De cookie zal de gebruiker dus bij een nieuwe visit alleen inloggen wanneer je hetzelfde ip adres hebt. Ik had dit bedacht om op deze manier min of meer zeker van te zijn dat de gebruiker ook dezelfde pc gebruikt (wat je extra zekerheid geeft dat het geen hacker op andere locatie betreft).
Deze manier zorgt ervoor dat mensen met een dynamisch ip adres elke keer binnen een sessie opnieuw moeten inloggen.
Maar dit is bij T.net toch ook zo? /me kijkt naar devver:p

[crisp]

mithras86 schreef op maandag 13 november 2006 @ 12:12:
[...]
Maar dit is bij T.net toch ook zo? /me kijkt naar devver:p

Als jij je sessie hier op Tnet locked op je IP en je hebt na een reboot een ander IP dan zal je sessie als ongeldig worden gemarkeerd en ben je dus effectief niet meer ingelogd.

[MIster X]

crisp schreef op maandag 13 november 2006 @ 12:15:
Als jij je sessie hier op Tnet locked op je IP en je hebt na een reboot een ander IP dan zal je sessie als ongeldig worden gemarkeerd en ben je dus effectief niet meer ingelogd.

En als je je sessie niet locked?

[crisp]

MIster X schreef op maandag 13 november 2006 @ 12:20:
[...]


En als je je sessie niet locked?

Dan ben je met die sessie vanaf elk willekeurig IP ingelogd.

[Paul]

mithras86 schreef op maandag 13 november 2006 @ 12:12:
Nee, zie hierboven. Het gaat om

code:

md5(md5(password) + md5(salt))

tov

code:

md5(password + salt)

Je zegt het eronder zelf inderdaad al (bijna): Op die 2e manier kun je serverside alleen controleren of het klopt als je wachtwoord plaintext in de DB staat, of je md5(wachtwoord+salt) in de DB staat waardoor de salt steesd hetzelfde moet zijn en je dus nog steeds vatbaar bent voor replay attacks

Een clientside hash heeft (ook zonder salt) verder nog het voordeel dat je password neit plaintext over de lijn gaat.
Zet maar eens een hubje tussen je netwerk en je router, en ga HTTP-verkeer sniffen, dan kun je precies zien wat er allemaal langskomt. En iedereen met fysiek toegang tot een van de netwerken tussen jou en de server kan precies dat doen, of op afstand: de router hacken / BGP vergiftigen / je webserver hacken / etc.

Dit staat allemaal heel mooi en uitgebreid en simpel uitgelegd op http://www.pajhome.org.uk/crypt/md5/auth.html inclusief de concepten en gedachtes erachter

[ Voor 24% gewijzigd door Paul op 13-11-2006 12:29 ]

[Zyppora]

Wat ik doe is het volgende (of dit veilig is weet ik niet, vziw zijn de meeste lekken gewoon beveiligd):

1. User vult username en wachtwoord in

2. Verstuurt deze dmv. formulier naar server

3. Server:

code:

SELECT password FROM users WHERE username='htmlentities($loginname)'

4. Vergelijk de (md5 encoded) password van de DB met die van het formulier (welke door de server eerst md5 encoded wordt).

5. Als deze overeenkomen, wordt er een cookie gestuurd met de volgende informatie:
- userid
- md5(wachtwoord)
- md5(IP adres)

Op alle pagina's controleer je dan het cookie op de drie gegevens.

Deze methode is vziw beveiligd tegen de volgende dingen:
- Cookie Grabbers (IP wordt gecontroleerd)
- SQL Injection (of dit nu htmlentities of mysql_real_escape_string (of een van de andere tientallen functies) moet gebruiken, maakt volgens mij niet zoveel uit)

Op deze manier is het overigens wel gevoelig voor sniffers (denk ik), omdat het wachtwoord rechtstreeks naar de server gestuurd wordt. Ik denk echter dat het risico hierop vrij klein is. Het kan bijvoorbeeld alleen maar binnen netwerken voorkomen, en dan is het IP toch hetzelfde.

[CodeCaster]

Op je lokale netwerk ben je toch nooit veilig. Alle verkeer is captureable, en het externe IP komt ook nog eens overeen. Jat iemands cookies en je bent binnen.

[Zyppora]

CodeCaster schreef op maandag 13 november 2006 @ 12:28:
Op je lokale netwerk ben je toch nooit veilig. Alle verkeer is captureable, en het externe IP komt ook nog eens overeen. Jat iemands cookies en je bent binnen.

Moet je wel in eerste instantie op hetzelfde netwerk zitten. En dan denk ik niet zozeer aan een irritant broertje of zusje, maar meer aan een wifi roamer/hacker. En dan komt het neer op je netwerk beveiligen.

EDIT: Is geen excuus, weet ik wel ... Magoed, da's iets waar ik dan nog wat tijd in moet steken.

[ Voor 9% gewijzigd door Zyppora op 13-11-2006 12:32 ]

[Voutloos]

Zyppora schreef op maandag 13 november 2006 @ 12:26:
- md5(IP adres)

En wat is die check dan? md5 van ip adres huidige request? In dat geval slaat het echt nergens op, want iedereen kan zijn eigen ip adres wel op deze manier hashen.

- SQL Injection (of dit nu htmlentities of mysql_real_escape_string (of een van de andere tientallen functies) moet gebruiken, maakt volgens mij niet zoveel uit)

Maakt _wel_ uit. Er zijn niet veel functies omdat men het maar leuk vind om elke keer een functie te bedenken... Pak nou niet at random een van de functies, maar gewoon degene welke het meest gepast is.

[Paul]

Zyppora schreef op maandag 13 november 2006 @ 12:26:
2. Verstuurt deze dmv. formulier naar server

Plaintext WW over de lijn

3. Server:

code:

SELECT password FROM users WHERE username='htmlentities($loginname)'

Laat single-quotes intact, is hier totaal niet voor bedoeld (dit is om [bijvoorbeeld] users HTML-rechten te ontnemen, niet om SQL-injection tegen te gaan.)

5. Als deze overeenkomen, wordt er een cookie gestuurd met de volgende informatie:
- userid
- md5(wachtwoord)
- md5(IP adres)

Waarom IP md5en? IP heb je toch al bij de pagina-aanvraag? Die moet je juist serverside opslaan, niets houdt mij tegen om in een gejat cookie een andere md5(ipadres) te zetten.
Waarom het wachtwoord erbij? En nu ineens wel in MD5? Ga je iedere keer weer je wachtwoord controleren?

Ik denk dat je beter een (serverside) sessie-ID op kunt slaan, dan kan men lokaal niets meer aanpassen. Ja, een ander sessie-ID gokken, maar door de IP-check vang je dat af. Tevens je sessie-ID dusdanig groot/random maken dat er geen gokken aan is.

[Verwijderd]

Zyppora schreef op maandag 13 november 2006 @ 12:26:
Een heel verhaal...

Op deze manier is het overigens wel gevoelig voor sniffers (denk ik), omdat het wachtwoord rechtstreeks naar de server gestuurd wordt. Ik denk echter dat het risico hierop vrij klein is. Het kan bijvoorbeeld alleen maar binnen netwerken voorkomen, en dan is het IP toch hetzelfde.

Juist over je laatste opmerking gaat het al de hele tijd. Er wordt hier duidelijk gemaakt hoe je een inlogsysteem zo veilig mogelijk maakt. Dan vind ik jou oplossing persoonlijk een beetje karig.

Het feit dat je zelf "denkt" dat het niet veilig is voor sniffers zegt al veel. Misschien moet je je eens inlezen in de concepten om hier achter te komen.

Voutloos schreef op maandag 13 november 2006 @ 12:34:
Maakt _wel_ uit. Er zijn niet veel functies omdat men het maar leuk vind om elke keer een functie te bedenken... Pak nou niet at random een van de functies, maar gewoon degene welke het meest gepast is.

Inderdaad... misschien toch eens wat meer in de documentatie (PHP, algemene concepten) duiken. Kan voorkomen dat je jezelf nog eens in de nesten werkt.

[FragFrog]

CodeCaster schreef op zondag 12 november 2006 @ 23:18:
Ik gebruik zelf de volgende functie voor het opvragen van POST-variabelen:
[code]

Grappig, ik maak gebruik van bijna dezelfde functies Mijn standaard data opruim blokje:

PHP:

function postHandler($post = false) {
  $post = $post ? $post : $_POST;
  $var = array();
  foreach($post as $index => $variable) 
    $var[$index] = checkVar($variable);
  return $var;
}

function checkVar($variable) {
  $variable = htmlspecialchars($variable, ENT_QUOTES);
  if(!get_magic_quotes_gpc()) 
    $variable = mysql_real_escape_string($variable);
  return $variable;
}

Een simpele en veilige manier om POST data te verkrijgen. Zeker bij grote formulieren erg fijn, aangezien je kan volstaan met een enkele keer $post = posthandler(); waarna je direct bij je data kan.

Janoz schreef op maandag 13 november 2006 @ 11:02:
Als iedereen maar een stapeltje dingen aanneemt krijg je van die vreemde constructies waarbij mensen een html_special_chars over hun input heenhalen voordat het de database in gaat.

Vergeef me, heb er verder ook niet voor doorgeleerd, maar waarom is het vreemd om htmlspecialchars te gebruiken voor je data naar een database stuurt? Natuurlijk, mysql_real_escape_string is nuttig, maar dan moet je gaan meuken met addslashes en trimslashes wat, laten we wel wezen, uiteindelijk meer problemen oplevert dan dat het oplost. Eerst htmlspecialchars gebruiken is voor zover ik weet dan ook een nuttige aanvulling?

[Erkens]

FragFrog schreef op maandag 13 november 2006 @ 12:47:
Vergeef me, heb er verder ook niet voor doorgeleerd, maar waarom is het vreemd om htmlspecialchars te gebruiken voor je data naar een database stuurt?

htmlspecialchars moet je alleen gebruiken voor (zoals de naam al zegt) als je met HTML werkt.

Natuurlijk, mysql_real_escape_string is nuttig, maar dan moet je gaan meuken met addslashes en trimslashes wat, laten we wel wezen, uiteindelijk meer problemen oplevert dan dat het oplost.

Nee, dat is het nu juist, als je mysql_real_escape_string gebruikt hoef je je geen zorgen te maken over addslashes/trimslashes etc, je krijgt namelijk de data dan precies zo terug zoals je het erin gestopt hebt.

Eerst htmlspecialchars gebruiken is voor zover ik weet dan ook een nuttige aanvulling?

nee, want dan zit je met rommel in je database, gebruik die functies alleen als je data terug aan de browser geeft, en hou de data in je database gewoon schoon. (tenzij je caching dingen wilt gaan doen, maar dan nog behoor je ook de originele data te bewaren)

[Voutloos]

FragFrog schreef op maandag 13 november 2006 @ 12:47:
Natuurlijk, mysql_real_escape_string is nuttig, maar dan moet je gaan meuken met addslashes en trimslashes wat, laten we wel wezen, uiteindelijk meer problemen oplevert dan dat het oplost.

Lees gewoon wat die functie doet. Staat heel duidelijk in de documentatie. Als je verder rekening houdt met server settings als magic quotes (wordt in gegeven link ook uitgekauwd, zie quote_smart() best practice voorbeeld) mag het niet 'voor problemen zorgen'. Dit soort functies zorgen gewoon niet voor problemen. Je krijgt alleen problemen als je ze fout gebruikt, of dubbel escaped of whatever. Als je zelf consistent te werk gaat (wat wel handig is als je programmeert) krijg je never nooit niet problemen met deze functie.

[Erkens]

magic_quotes moet gewoon dood, de meest nutteloze "feature" maar toch irritante feature die ze ooit hebben bedacht, mijn applicaties weigeren gewoon als je die aan hebt staan. Tuurlijk het is simpel om het ongedaan te maken, maar juist uit security oogpunt vind ik dat je die uit moet hebben.

[Voutloos]

Magic quotesmoet ook dood, dar ben ik het helemaal mee eens. Punt is gewoon dat jij dus rekening houd met de magic quotes setting.

[FragFrog]

Erkens schreef op maandag 13 november 2006 @ 12:55:
Nee, dat is het nu juist, als je mysql_real_escape_string gebruikt hoef je je geen zorgen te maken over addslashes/trimslashes etc, je krijgt namelijk de data dan precies zo terug zoals je het erin gestopt hebt.

Erm, hier zet ik toch mijn vraagtekens bij - zeker bij aanwezigheid van magic_quotes_gpc. Direct uit de manual:

Note: If magic_quotes_gpc is enabled, first apply stripslashes() to the data. Using this function on data which has already been escaped will escape the data twice.

Data netjes houden ben ik heel hard voor, maar als je kan kiezen tussen of een slash ervoor zetten of omschrijven naar bijvoorbeeld &#039 schrijf ik het liever om - zeker omdat PHP en MySQL data bijna altijd wel ergens op een website terecht komt en je dus vroeger of later alsnog htmlspecialchars moet gebruiken.

Ik ben bang dat ik het argument "/' is netter dan $#039;" niet echt reden vind om me het gezeur met slashes op de hals te halen

//edit

Voutloos schreef op maandag 13 november 2006 @ 12:58:
[...]

Lees gewoon wat die functie doet.

Lees het zelf eens

En ja, je kan magic_quotes detecteren en desnoods uitzetten, of je kan er vanuit gaan dat magic_quotes niet gebruikt wordt, maar het is IMHO achterlijk om apps te ontwikkelen die van dat soort geintjes afhangen. Kun je voor jezelf doen, maar zodra je dingen gaat publiceren kun je dat niet maken.

[ Voor 18% gewijzigd door FragFrog op 13-11-2006 13:13 ]

[Erkens]

FragFrog schreef op maandag 13 november 2006 @ 13:07:
Erm, hier zet ik toch mijn vraagtekens bij - zeker bij aanwezigheid van magic_quotes_gpc. Direct uit de manual:
[...]

waarom denk je dat ik zeg dat die magic_quotes dood moet? troep is het

Data netjes houden ben ik heel hard voor, maar als je kan kiezen tussen of een slash ervoor zetten of omschrijven naar bijvoorbeeld ' schrijf ik het liever om - zeker omdat PHP en MySQL data bijna altijd wel ergens op een website terecht komt en je dus vroeger of later alsnog htmlspecialchars moet gebruiken.

een ' is gewoon een geldig teken binnen HTML, geen noodzaak om daar ' van te maken

Ik ben bang dat ik het argument "/' is netter dan $#039;" niet echt reden vind om me het gezeur met slashes op de hals te halen

nooit software geschreven die hergebruikt word?

[Voutloos]

FragFrog schreef op maandag 13 november 2006 @ 13:07:
Lees het zelf eens

Dus? Ik heb het gelezen (al een hele tijd terug btw ) en ik houd rekening met brakke servers waar incompetente admins in een vlaag van verstandverbijstering magic quotes aangeslingerd hebben. That's it. Dat noem ik niet 'dingen op de hals halen'.

En ja, je kan magic_quotes detecteren en desnoods uitzetten, of je kan er vanuit gaan dat magic_quotes niet gebruikt wordt, maar het is IMHO achterlijk om apps te ontwikkelen die van dat soort geintjes afhangen. Kun je voor jezelf doen, maar zodra je dingen gaat publiceren kun je dat niet maken.

Juist als je iets gaat publiceren moet je het doen. Als je iets puur op je eigen bak neer zet weet je wel wat de configuratie is. Ik snap echt gewoon niet waarom je deze werkwijze zo eng vind dat je per se een minder geschikte functie er tegenaan wil gooien.

[Cloud]

FragFrog schreef op maandag 13 november 2006 @ 13:07:
Erm, hier zet ik toch mijn vraagtekens bij - zeker bij aanwezigheid van magic_quotes_gpc. Direct uit de manual:

Waarom vraagtekens? Als je voor mysql_real_escape_string gaat hoef je je gewoon echt niet meer zorgen te maken over slashes. Tenzij je natuurlijk al geescaped hebt en of dat nou via een andere escape functie is, of magic_quotes, doet er niet toe. Logischerwijs moet je altijd maar één keer escapen. Daarom is magic_quotes ook zo'n dodelijke rot "feature" die van mij ook wel verwijderd mag worden

of begrijp ik je 'vraagtekens' nu verkeerd?

[crisp]

FragFrog schreef op maandag 13 november 2006 @ 13:07:
[...]
zeker omdat PHP en MySQL data bijna altijd wel ergens op een website terecht komt en je dus vroeger of later alsnog htmlspecialchars moet gebruiken.

Er zijn situaties genoeg waar je juist geen HTML-encoding wilt hebben, mail bijvoorbeeld. Verder worden single quotes niet automatisch omgezet bij het gebruik van htmlspecialchars() of htmlentities(), je moet daarvoor expliciet ENT_QUOTES opgeven.

[Janoz]

FragFrog schreef op maandag 13 november 2006 @ 13:07:
Ik ben bang dat ik het argument "/' is netter dan $#039;" niet echt reden vind om me het gezeur met slashes op de hals te halen

Welke van de twee netter is is compleet niet interresantt. Waar het om gaat is dat de ene een vertaling is en de ander een escape karakter. Zoals ik eerder al zei, begrijp wat er gebeurt, niet aannemen.

Volgende situatie:

janoz' test

Deze tekst wil ik invoeren in de database. Ik heb de volgende query:

insert into tabel values ('...');

Gaan we nu beide methoden loslaten. Eerst mysql_escape.De gegenereerde query is dan als volgt:

insert into tabel values ('janoz\' test')

Het veld in de tabel is nu dus gevult met de volgende tekst:

janoz' test

Nu nemen we de html_special_chars versie van jou. De gegenereerde query is nu:

insert into tabel values ('janoz#039; test')

Het veld in de tabel is nu dus gevult met de volgende tekst:

janoz#039; test

Ik neem aan dat nu zo langzamerhand wel duidelijk is waarom je juist voor de mysql_escape variant moet kiezen?


---
Dezelfde 'problemen' zie je wanneer mensen met reguliere expressies gaan werken in php. Hierin moet je juist dubbel escapen. De eerste keer voor de parser van je php script en de volgende keer voor de reguliere expressie. Voor elke \ in je reguliere expressie zul je in php \\ moten gebruiken. Vandaar ook dat een referentie altijd \\1 en \\2 is ipv \1 en \2

[ Voor 13% gewijzigd door Janoz op 13-11-2006 13:30 ]

[Zyppora]

Voutloos schreef op maandag 13 november 2006 @ 12:34:
[...]
En wat is die check dan? md5 van ip adres huidige request? In dat geval slaat het echt nergens op, want iedereen kan zijn eigen ip adres wel op deze manier hashen.

Dat kan inderdaad. Het idee erachter is dus dat de hacker/cookie grabber/etc. niet weet dat het in de cookie om een md5 encoded IP adres gaat. Die ziet alleen een code, en mag van mij raden wat er ge-md5'd is. Het IP kan worden opgeslagen op de server, maar dat wordt meer werk om mensen met een dynamisch IP te ontzien. Cookie binden aan IP was mijn oplossing. Of deze veiliger/efficiënter is weet ik niet, vandaar mijn eerste post in dit topic

Voutloos schreef op maandag 13 november 2006 @ 12:34:
[...]
Maakt _wel_ uit. Er zijn niet veel functies omdat men het maar leuk vind om elke keer een functie te bedenken... Pak nou niet at random een van de functies, maar gewoon degene welke het meest gepast is.

Wat ik geleerd heb is dat er bepaalde tekens zijn die je wilt mijden in je SQL. Quotes onder andere. Als een functie die quotes onderschept, dan is het toch goed? Of ben ik nu naief?

Paul Nieuwkamp schreef op maandag 13 november 2006 @ 12:38:
[...]
Plaintext WW over de lijn

[...]
Laat single-quotes intact, is hier totaal niet voor bedoeld (dit is om [bijvoorbeeld] users HTML-rechten te ontnemen, niet om SQL-injection tegen te gaan.)

Kijk, daar kan ik wat mee. Je geeft hier dus niet alleen aan dat het niet verstandig is een bepaalde functie te gebruiken, je geeft ook aan waarom niet. Ik ken inmiddels ook de ENT_QUOTES truuks, maar zoals ik hierboven al zei, heiligt het doel niet gewoon de middelen? Als ik het met een setje str_replace() calls wil doen (ik noem maar even iets, hoor), kan dat toch ook (mits goed opgezet)?

Paul Nieuwkamp schreef op maandag 13 november 2006 @ 12:38:
[...]
Waarom IP md5en? IP heb je toch al bij de pagina-aanvraag? Die moet je juist serverside opslaan, niets houdt mij tegen om in een gejat cookie een andere md5(ipadres) te zetten.
Waarom het wachtwoord erbij? En nu ineens wel in MD5? Ga je iedere keer weer je wachtwoord controleren?

Vraagje: hoe weet jij überhaupt dat een bepaalde md5 string een hash van een IP adres is? Of van een wachtwoord?

Het wachtwoord zet ik encoded in het cookie om deze continu te vergelijken met de in de DB onder hetzelfde user ID opgeslagen wachtwoord. Deze constructie stamt uit de tijd dat ik nog geen encoded IP in het cookie zette, en waarbij dus (lekker veilig) alleen een unencoded user ID in het cookie opgeslagen wordt. Om veiligheidsredenen heb ik hem erin laten staan.

Paul Nieuwkamp schreef op maandag 13 november 2006 @ 12:38:
Ik denk dat je beter een (serverside) sessie-ID op kunt slaan, dan kan men lokaal niets meer aanpassen. Ja, een ander sessie-ID gokken, maar door de IP-check vang je dat af. Tevens je sessie-ID dusdanig groot/random maken dat er geen gokken aan is.

Ik denk dat ik maar eens wat dingetjes ga veranderen aan mijn scriptje. Toen het huidige login geval tot stand kwam, kende ik deze sessie-ID manier nog helemaal niet. Bedankt!

[AW_Bos]

l0c4lh0st schreef op maandag 13 november 2006 @ 11:46:
Deze functie gebruik ik standaard in elk script:

PHP:

<?php
if (get_magic_quotes_gpc() == 1)
{
    function undo_magic_quotes_gpc($pmVariable)
    {
        if (is_array($pmVariable))
        {
            return array_map('undo_magic_quotes_gpc', $pmVariable);
        }
        else
        {
            return stripslashes($pmVariable);
        }
    }
    $_GET = undo_magic_quotes_gpc($_GET);
    $_POST = undo_magic_quotes_gpc($_POST);
    $_COOKIE = undo_magic_quotes_gpc($_COOKIE);
    $_REQUEST = undo_magic_quotes_gpc($_REQUEST);
}
?>

Vervolgens doe ik in query's altijd addslashes() over de data en bij het printen van data altijd htmlspecialchars().

Bij het kijken of ID's bestaan (in de URL bijv.) doe ik ook altijd een preg_match('/^([0-9]+)$/is', ...) om te kijken of het ook echt een getal is. Helaas wil ik daar nog wel eens de ^ en $ vergeten.


Maar volgens mij is bovenstaand veilig genoeg, niet dan?

je kan ook de functie: is_numeric() gebruiken

[mithras]

Zyppora schreef op maandag 13 november 2006 @ 13:30:
[...]

Ik denk dat ik maar eens wat dingetjes ga veranderen aan mijn scriptje. Toen het huidige login geval tot stand kwam, kende ik deze sessie-ID manier nog helemaal niet. Bedankt!

Ik heb dus afgelopen weekend een opzet gemaakt van een nieuw login systeem, en heb daarbij met een schuin oog gekeken naar T.net.
Het principe van meerdere sessie's hanteren (ik lock dan automatisch op ip) beviel me wel, omdat je hierdoor ook als dezelfde user achter meerdere clients kan inloggen: op je werk en thuis. Zo ben je bij beide ook automatisch ingelogd als je dat wil (dmv een cookie).

Als je dan een "veiligheidsmethode" op gaat zetten kom je eigenlijk elke keer min of meer op dezelfde methode uit. Ik mis dan nu het clientside hashen met een salt, maar buiten die implementatie werkt het systeem hetzelfde. En dat is ook het meest veilige en het meest user-friendly (itt andere fora/blogs, waar je niet op twee plaatsen ingelogd kan zijn. Een tweede inlog logt je eerste inlog uit. Niet heel handig imho).

[Verwijderd]

even terzijde... wanneer je gebruik maakt van wachtwoorden die met 1x -> Xx geMD5'd zijn zonder salt, moet je er rekening mee houden dat er databases zijn met wachtwoord - MD5 hash combinaties waarmee gechecked kan worden welk wachtwoord het zou kunnen zijn... indien je dit toch wilt gebruiken kan je met een API op onderstaande site checken of deze in de database voorkomt...

http://md5.rednoize.com/

Uiteraard is het gebruik van een salt wenselijk!

[Voutloos]

Zyppora schreef op maandag 13 november 2006 @ 13:30:
[...]


Dat kan inderdaad. Het idee erachter is dus dat de hacker/cookie grabber/etc. niet weet dat het in de cookie om een md5 encoded IP adres gaat.

Het is wel een van de dingen die ik zou proberen, zeker als het cookie 'ip' zou heten. Dit is een voorbeeld van een situatie waar een salt geen kwaad kan.

Het IP kan worden opgeslagen op de server, maar dat wordt meer werk om mensen met een dynamisch IP te ontzien

Bij iemand met een dynamisch IP verandert dat cookie ook niet opeens, dus je bent nu niet ook niet aardig jegens mensen met een dynamisch IP .

[FragFrog]

Voutloos schreef op maandag 13 november 2006 @ 13:15:
Juist als je iets gaat publiceren moet je het doen. Als je iets puur op je eigen bak neer zet weet je wel wat de configuratie is. Ik snap echt gewoon niet waarom je deze werkwijze zo eng vind dat je per se een minder geschikte functie er tegenaan wil gooien.

Als je mijn code-voorbeeld leest zie je dat ik dat ook doe Ik gebruik niet -in plaats van- een minder geschikte functie, ik gebruik -in additie tot- een 'minder geschikte' functie

crisp schreef op maandag 13 november 2006 @ 13:23:
Er zijn situaties genoeg waar je juist geen HTML-encoding wilt hebben, mail bijvoorbeeld. Verder worden single quotes niet automatisch omgezet bij het gebruik van htmlspecialchars() of htmlentities(), je moet daarvoor expliciet ENT_QUOTES opgeven.

Wederom, lees m'n code, natuurlijk gebruik ik ENT_QUOTES, anders is inderdaad het hele nut ervan weg Maar je hebt een puntje dat het voor email wellicht minder handig is (HTML email daarentegen...) - then again, ik gebruik PHP's mail functie eigenlijk zo goed als nooit

Janoz schreef op maandag 13 november 2006 @ 13:24:
Welke van de twee netter is is compleet niet interresantt. Waar het om gaat is dat de ene een vertaling is en de ander een escape karakter. Zoals ik eerder al zei, begrijp wat er gebeurt, niet aannemen.

Ik -weet- wat er gebeurt Janoz, thank you very much Maar zoals ik al zei: ik geef er juist de voorkeur aan als iets vertaalt wordt in plaats van escaped. Neem voor de grap eens <input type='text' value='value met aanhalingsteken erin'>. Als je escaped wordt ondanks die slash alles na de ' er netjes uitgebonjoured. Dezelfde code werkt echter in een <textarea></textarea> omgeving weer -wel-. Met vertalen heb je daar simpelweg geen problemen mee!

Natuurlijk, dan kun je wel -eerst- escapen en daarna trimslashes doen en vertalen, maar waarom die extra stappen als het niet noodzakelijk is? Gegevens die enkel voor webrepresentatie bedoeld zijn gooi ik dan liever vertaald in m'n database. Bovendien wordt data toch al centraal gecontroleerd voor het m'n database in gaat, maar niet als het eruit gehaald wordt. Dan scheelt het aanmerkelijk in je code om op die centrale plaats ervoor te zorgen dat het in het gewenste formaat in je db komt te staan.

Ik begrijp dat er ook nadelen aan deze manier van werken zitten, helemaal achterlijk ben ik ook weer niet maar IMHO wegen die niet op tegen de voordelen Helemaal omdat -als- je ooit gegevens moet exporteren naar niet-HTML het simpel genoeg is om die vertaalslag andersom te maken.

//edit

Verwijderd schreef op maandag 13 november 2006 @ 14:19:
even terzijde... wanneer je gebruik maakt van wachtwoorden die met 1x -> Xx geMD5'd zijn zonder salt, moet je er rekening mee houden dat er databases zijn met wachtwoord - MD5 hash combinaties waarmee gechecked kan worden welk wachtwoord het zou kunnen zijn... indien je dit toch wilt gebruiken kan je met een API op onderstaande site checken of deze in de database voorkomt...

De reden waarom ik zelf alleen nog maar sha1 gebruik, die's wat lastiger te kraken

[ Voor 9% gewijzigd door FragFrog op 13-11-2006 14:32 ]

[Verwijderd]

Ik zal dan wel te puristisch denken maar ik ben het niet met je eens. Representatie moet mijn inziens los staan van het opslaan van de eigenlijke data in een database. Wat je zegt is waar maar het is mijn inziens niet 'netjes' en niet makkelijk te onderhouden.

PHP bied je juist deze hulpmiddelen en je zou ze dan niet gebruiken omdat je dan enkele extra stappen moet ondernemen (wat een werk ). Persoonlijk vind ik dat erg kort door de bocht en ik zou er dus ook niet voor kiezen.

[Janoz]

FragFrog schreef op maandag 13 november 2006 @ 14:31:
Ik -weet- wat er gebeurt Janoz, thank you very much Maar zoals ik al zei: ik geef er juist de voorkeur aan als iets vertaalt wordt in plaats van escaped.

Weet je het zeker? In jou geval staat er een vertaling van je data in de database. In mijn geval staat gewoon de data in de database. Lees ook nog het verhaal wat eronder staat. Door te escapen komen er geen slashes in de database terecht. Het escapen is enkel voor het genereren van het berichtje dat je naar de database stuurt. Als je je gegevens eruit haalt krijg je gewoon de orginele gegevens terug. Als je die vervolgens in een textarea wilt gebruiken dan gooi je er op dat moment html_special_chars over heen. Gebruik je het echter in een mail dan kun je het rechtstreeks gebruiken. Gebruik je het als javascript variable dan kun je er escape overheen gooien en gebruik je het in een URL dan kun je er urlencode overheen halen. 3 van de 4 zijn nog steeds html gerelateerde dingen, en elke drie hebben ze een andere manier van 'escapen'.

[ Voor 5% gewijzigd door Janoz op 13-11-2006 14:54 ]

[Zyppora]

Voutloos schreef op maandag 13 november 2006 @ 14:28:
[...]
Het is wel een van de dingen die ik zou proberen, zeker als het cookie 'ip' zou heten. Dit is een voorbeeld van een situatie waar een salt geen kwaad kan.

Het cookie heet dan ook geen 'ip'

Voutloos schreef op maandag 13 november 2006 @ 14:28:
[...]
Bij iemand met een dynamisch IP verandert dat cookie ook niet opeens, dus je bent nu niet ook niet aardig jegens mensen met een dynamisch IP .

Jottem. Die zag ik dus even niet aankomen. Komt omdat het script alleen nog maar op mijn interne netwerk draait, en ik dus altijd hetzelfde IP heb. Maar goed, hoe meer tips, hoe beter.

* Zyppora voelt zich nu wel

[OxiMoron]

Ik heb zelf een headerfile waar alle post en get vars automatisch met mysql_real_escape gedaan worden.
Nadeel is wel dat als je ze niet meteen in de database zet, maar bijvoorbeeld nog weer wilt geven je ze niet makkelijk kunt unescapen

Best jammer dat er geen mysql_unescape is, je kunt het natuurlijk wel handmatig doen met een regex, maar echt netjes is dat natuurlijk niet.

[CodeCaster]

OxiMoron schreef op maandag 13 november 2006 @ 15:22:
Ik heb zelf een headerfile waar alle post en get vars automatisch met mysql_real_escape gedaan worden.
Nadeel is wel dat als je ze niet meteen in de database zet, maar bijvoorbeeld nog weer wilt geven je ze niet makkelijk kunt unescapen

Best jammer dat er geen mysql_unescape is, je kunt het natuurlijk wel handmatig doen met een regex, maar echt netjes is dat natuurlijk niet.

Wat is er mis met stripslashes? Lijkt me afdoende voor de meeste standaardgevalletjes. Ik gebruik het ook voor mijn preview-functies, dus post zonder insert.

[Verwijderd]

OxiMoron schreef op maandag 13 november 2006 @ 15:22:
Ik heb zelf een headerfile waar alle post en get vars automatisch met mysql_real_escape gedaan worden.
Nadeel is wel dat als je ze niet meteen in de database zet, maar bijvoorbeeld nog weer wilt geven je ze niet makkelijk kunt unescapen

Best jammer dat er geen mysql_unescape is, je kunt het natuurlijk wel handmatig doen met een regex, maar echt netjes is dat natuurlijk niet.

Nee, dat is inderdaad niet netjes... het is pas netjes als je je variabelen escaped voordat je ze in een query gebruikt. En dat doe je zelf nu juist ook niet.

Dus de redenatie dat het een nadeel is van PHP dat ze geen unescape mogelijkheid hebben is hier ook niet helemaal correct. Gebruik het escapen gewoon wanneer het nodig is

[eghie]

Lees ook deze guides over veilig PHP programmeren:
http://www.ilovejackdaniels.com/php/writing-secure-php
http://www.ilovejackdaniels.com/php/writing-secure-php-2
http://www.ilovejackdaniels.com/php/writing-secure-php-3

[Verwijderd]

Wat ik zo zie is een subset van het artikel wat te vinden is op phpfreakz (pdf versie). Maar een goed begin, dat zeker

Wat vinden jullie overigens van dit artikel? Is het een goed artikel of mist de schrijver bepaalde zaken, ik was er zelf behoorlijk over te spreken en het heeft me veel geleerd.

[Olaf van der Spek]

CodeCaster schreef op maandag 13 november 2006 @ 12:28:
Op je lokale netwerk ben je toch nooit veilig. Alle verkeer is captureable, en het externe IP komt ook nog eens overeen. Jat iemands cookies en je bent binnen.

SSL/TLS.
En IP adres locks zijn ook irritant. Elke keer als je een ander IP adres hebt, kun je weer opnieuw inloggen.

[ Voor 16% gewijzigd door Olaf van der Spek op 13-11-2006 17:15 ]

[FragFrog]

Janoz schreef op maandag 13 november 2006 @ 14:51:
Weet je het zeker?

Nee

Deels de reden waarom ik hier reageer is omdat het nooit kwaad kan security en in het algemeen processen te herevalueren. De functies die ik gebruik zijn over de jaren gegroeid maar komen voort uit een basis die geschreven is door iemand met maar bar weinig PHP ervaring. checkVar heeft voor mij altijd gewerkt en gedaan wat ik ervan verwachtte, ik ben ongetwijfeld niet de enige die een serie antieke scripts heeft die'ie telkens weer gebruikt zonder er echt bij na te denken

Nochtans ben ik niet heel erg geneigd over te gaan op enkel mysql_real_escape_string om eerder genoemde redenen, maar wellicht dat ik in de toekomst in een positie kom waarin dat wel voordelen op gaat leveren.. Vond het in ieder geval een leerzame discussie

[.oisyn]

OxiMoron schreef op maandag 13 november 2006 @ 15:22:
Ik heb zelf een headerfile waar alle post en get vars automatisch met mysql_real_escape gedaan worden.
Nadeel is wel dat als je ze niet meteen in de database zet, maar bijvoorbeeld nog weer wilt geven je ze niet makkelijk kunt unescapen

Je doet het imho ook verkeerd om, net als CodeCaster aan het begin van deze draad. Je wilt helemaal niet alle GPC variabelen besmeuren met html entities en escape sequences - die dingen wil je er pas in hebben als duidelijk is wat je ermee gaat doen. Check dus of magic_quotes_gpc aan staat (de meest idiote optie in IT history!), en doe dan een stripslashes op al je GPC variabelen zoals l0c4lh0st al liet zien.

Pas als je een variabele voor iets specifieks nodig hebt pas je de juiste functie toe. Wil je 'm bijvoorbeeld in een database stoppen, gebruik dan de mysql_real_escape. Wil je 'm direct outputten naar een html document, gebruiken dan htmlspecialchars(). Wil je 'm gewoon in een tekstbestand opslaan, dan doe je er niets mee.

[eghie]

.oisyn schreef op maandag 13 november 2006 @ 17:33:
[...]

Je doet het imho ook verkeerd om, net als CodeCaster aan het begin van deze draad. Je wilt helemaal niet alle GPC variabelen besmeuren met html entities en escape sequences - die dingen wil je er pas in hebben als duidelijk is wat je ermee gaat doen. Check dus of magic_quotes_gpc aan staat (de meest idiote optie in IT history!), en doe dan een stripslashes op al je GPC variabelen zoals l0c4lh0st al liet zien.
...knip...

Ben ik, en heel veel meer mensen, blij als PHP6 mainstream wordt en geen register_globals en magic_quotes_gpc worden ondersteund. Alleen wat dan weer jammer gaat worden is dat ze die functies dan zelf weer gaan bouwen.

Gebruik overigens nooit $_GET["naampje"], maar doe aan input filtering en doe het via een centrale manier, die later ook aan te passen is. Bijvoorbeeld zo:

PHP:

$inpLayer = new InputLayer();


$variable = $inpLayer->getInput('naampje', $inpLayer->PARAM_SINGLELINE_STRING, $inpLayer->SOURCE_GET, array('defaultval' => 'aapje', 'maxlength' => 10, 'regexp' => '^[a-z0-9]*$');

Met iets als dit in de class:

PHP:

class InputLayer
{
    // param types
    public const PARAM_SINGLELINE_STRING = 0;
    public const PARAM_MULTILINE_STRING = 1;
    public const PARAM_INT = 2;
    public const PARAM_BOOL = 3;
    public const PARAM_EMAIL = 4;

    // param sources
    public const SOURCE_GET = 0;
    public const SOURCE_POST = 1;
    public const SOURCE_COOKIE = 2;
    public const SOURCE_SESSION = 3;
    public const SOURCE_CONFIG = 4;

    public function __construct()
    {
         $this->checkAndDieOnMagicQuotes();

         $this->checkAndDieOnRegisterGlobals();
    }

    public function getInput($paramname, $paramtype = $this->PARAM_SINGLELINE_STRING, $source = $this->SOURCE_GET, $extraoptions = array())
    {
          // validate parameters
          // if not valid log it and return default
          // else return parameter value
    }
}

Kijk ook eens hier naar: PHP: Filter Functions.

[ Voor 25% gewijzigd door eghie op 13-11-2006 19:19 ]

[Olaf van der Spek]

eghie schreef op maandag 13 november 2006 @ 19:05:
Ben ik, en heel veel meer mensen, blij als PHP6 mainstream wordt en geen register_globals en magic_quotes_gpc worden ondersteund. Alleen wat dan weer jammer gaat worden is dat ze die functies dan zelf weer gaan bouwen.

Staat magic_quotes_gpc in 5.2 niet nog gewoon aan?
Het lijkt me handig als ze dat eerst uitzetten en dan pas verwijderen.

Ook zou het goed zijn als PHP de default config in overeenstemming brengt met alle veiligheidsmaatregelen die ze aanraden.

[eghie]

Olaf van der Spek schreef op maandag 13 november 2006 @ 23:03:
[...]

Staat magic_quotes_gpc in 5.2 niet nog gewoon aan?
Het lijkt me handig als ze dat eerst uitzetten en dan pas verwijderen.

Ook zou het goed zijn als PHP de default config in overeenstemming brengt met alle veiligheidsmaatregelen die ze aanraden.

Volgens mij wel ja. Maar veel -- ontwikkelaars die weten wat ze doen -- hebben er waarschijnlijk over geklaagd. Ik zelf vind het ook een zwaar irritante feature en wordt er niet echt vrolijk van dat het zoveel wordt gebruikt. Dit gaf mij veelste vaak WTF reacties. Nu weet ik dat het bestaat en wat het doet en houd er dus rekening mee. Ik heb ik in de loop der jaren een library opgebouwd die ik gebruik en waarbij die standaard al uit wordt gezet.

[Verwijderd]

eghie schreef op maandag 13 november 2006 @ 15:29:
Lees ook deze guides over veilig PHP programmeren:
http://www.ilovejackdaniels.com/php/writing-secure-php
http://www.ilovejackdaniels.com/php/writing-secure-php-2
http://www.ilovejackdaniels.com/php/writing-secure-php-3

Bedankt, dat is nou eens wat ik echt nodig had/zocht, uitgebreide en goed te begrijpen uitleg over security van php

BTW: Ik zal ook blij zijn zodra PHP6 uit is en mainstream is, zijn we (hopelijk toch) inderdaad van die irritante register_globals af (een oud stagiair (circa 2 jr terug) bij ons op het werk heeft dus het intranet geschreven met register_globals on )

[ Voor 22% gewijzigd door Verwijderd op 14-11-2006 00:15 ]

[Tanuki]

Ariën Clay schreef op maandag 13 november 2006 @ 13:34:
[...]

je kan ook de functie: is_numeric() gebruiken

Kan, maar die zou van 1e4 ook vinden dat het een getal is.

Het is trouwens, als je gebruik maakt van een database class, aan te raden om mysql_real_escape_string() te gebruiken (zoals iemand anders in dit topic ook al aangaf):

PHP:

<?php
...
function escape($psString)
{
      return (function_exists('mysql_real_escape_string') ? mysql_real_escape_string($psString) : addslashes($psString));
}
...
?>

Of nog beter, maak de functie gewoon zelf als die nog niet bestaat en gebruik altijd mysql_real_escape_string().

[Olaf van der Spek]

l0c4lh0st schreef op dinsdag 14 november 2006 @ 14:32:
Het is trouwens, als je gebruik maakt van een database class, aan te raden om mysql_real_escape_string() te gebruiken (zoals iemand anders in dit topic ook al aangaf):

Wanneer is er een verschil tussen beide functies dat onveilig is?

[Dutch2007]

Verwijderd schreef op dinsdag 14 november 2006 @ 00:12:
[...]


Bedankt, dat is nou eens wat ik echt nodig had/zocht, uitgebreide en goed te begrijpen uitleg over security van php

BTW: Ik zal ook blij zijn zodra PHP6 uit is en mainstream is, zijn we (hopelijk toch) inderdaad van die irritante register_globals af (een oud stagiair (circa 2 jr terug) bij ons op het werk heeft dus het intranet geschreven met register_globals on )

heb ergens wel een simpel stukje code, waar door ie dat met die magic quotes & register_globals checked, ken je die site/pages gewoon draaien terwijl de rest/PHP op register_globals = off staat

ooit uns gemaakt voor scriptje da, vrij oud was, en dit nodig had, (door script dus niet meer), script zorgt er inprincipe voor dat wat register_globals doet voor elke file, dat dat, alleen nog maar gebeurt voor die pages waar da stukkie code in zit (simpele include moet dan wel voldoende zijn )

[Janoz]

Zeg Dutch2007, zou je je best kunnen doen om Nederlands te gebruiken? Dit is echt onleesbaar. Verder raad ik je aan om de rest van dit topic eens door te lezen om te zien waarom jouw werkwijze uit security oogpunt niet wenselijk is.

[ Voor 5% gewijzigd door Janoz op 14-11-2006 14:50 ]

[Bargemanos]

Dutch2007 schreef op dinsdag 14 november 2006 @ 14:46:
[...]


heb ergens wel een simpel stukje code, waar door ie dat met die magic quotes & register_globals checked, ken je die site/pages gewoon draaien terwijl de rest/PHP op register_globals = off staat

ooit uns gemaakt voor scriptje da, vrij oud was, en dit nodig had, (door script dus niet meer), script zorgt er inprincipe voor dat wat register_globals doet voor elke file, dat dat, alleen nog maar gebeurt voor die pages waar da stukkie code in zit (simpele include moet dan wel voldoende zijn )

Ik vind de taal PHP al moeilijk, laat staan de beveiliging, maar dit slaat echt alles