[PHP/(My)SQL] voor dummies #97

Beste PHP devvers,

Even een vrij basale vraag. Voor mijn werkgever heb ik een php applicatie in elkaar geknutseld waarbij men intern mensen in kan roosteren en mensen extern aan kunnen geven wanneer ze beschikbaar zijn. Ziekte en verlof worden ook allemaal geregeld, iedereen blij. Alleen nu het steeds meer en meer gebruikt wordt door deze middelgrote organisatie begint mijn zorg over de veiligheid te stijgen. Laat ik eerlijk zijn: ik heb het in elkaar gezet met trail en error, heb nooit een PHP boek of cursus gedaan en met frunniken lukt me eigenlijk altijd wel wat ik wil. Maar ik weet ook dat het waarschijnlijk niet de veiligste en meest efficiente manier is.

Waar ik vooral tegen aan loop en wil vragen hoe jullie dat doen;

Als ik variabelen door minimaal 2 verschillende page's moet loodsen, gebruik ik de HTML "hidden input" tag om deze vast te houden en vervolgens weer door te zetten naar de volgende pagina die er wat mee doet.

Nou heb ik er nooit bij stilgestaan dat een kwaadwillende gebruiker deze hidden input tag kan invullen naar wens en vervolgens terug kan sturen naar de server met allerlei kwaadaardige code. In het geval van mijn appje zou dat een catastrofe zijn, want het zit bomvol met dit soort code om de eerder opgegeven waarde vast te houden.

Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.

Hoe lossen jullie dit op? Alvast bedankt!

quote:

Op donderdag 5 januari 2012 11:05 schreef boem-dikkie het volgende:
Dat script van die leraar trouwens. Je hele HTML echo'en.

Deed ik heel vroeger ook (toen ik 16-17 was), nu werk ik volgens OOP en MVC.

Liever een onderhoudsvriendelijk bulkproject dan een klein compact en onoverzichtelijk pakketje.

quote:

Op donderdag 5 januari 2012 21:40 schreef Dokay het volgende:
Beste PHP devvers,

Even een vrij basale vraag. Voor mijn werkgever heb ik een php applicatie in elkaar geknutseld waarbij men intern mensen in kan roosteren en mensen extern aan kunnen geven wanneer ze beschikbaar zijn. Ziekte en verlof worden ook allemaal geregeld, iedereen blij. Alleen nu het steeds meer en meer gebruikt wordt door deze middelgrote organisatie begint mijn zorg over de veiligheid te stijgen. Laat ik eerlijk zijn: ik heb het in elkaar gezet met trail en error, heb nooit een PHP boek of cursus gedaan en met frunniken lukt me eigenlijk altijd wel wat ik wil. Maar ik weet ook dat het waarschijnlijk niet de veiligste en meest efficiente manier is.

Waar ik vooral tegen aan loop en wil vragen hoe jullie dat doen;

Als ik variabelen door minimaal 2 verschillende page's moet loodsen, gebruik ik de HTML "hidden input" tag om deze vast te houden en vervolgens weer door te zetten naar de volgende pagina die er wat mee doet.

Nou heb ik er nooit bij stilgestaan dat een kwaadwillende gebruiker deze hidden input tag kan invullen naar wens en vervolgens terug kan sturen naar de server met allerlei kwaadaardige code. In het geval van mijn appje zou dat een catastrofe zijn, want het zit bomvol met dit soort code om de eerder opgegeven waarde vast te houden.

Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.

Hoe lossen jullie dit op? Alvast bedankt!

Extra sessies zijn eigenlijk ook slechts lapmiddelen.

Ik zou de gegevens gewoon controleren totdat een gebruiker zijn opdracht volledig heeft voltooid.

Dus onder andere: waarden typecasten (in een voor jouw gunstige type), reguliere expressies, htmlentities, strip_tags. Ik stel voor de controlemodellen in een aparte map op te slaan en de bestanden hierin alleen aan te roepen als het echt nodig is.

Desgewenst kun je je projectje ook naar mij toesturen als je het echt niet ziet zitten...

quote:

Op donderdag 5 januari 2012 22:00 schreef Ofyles2 het volgende:

[..]

Extra sessies zijn eigenlijk ook slechts lapmiddelen.

Ik zou de gegevens gewoon controleren totdat een gebruiker zijn opdracht volledig heeft voltooid.

Dus onder andere: waarden typecasten (in een voor jouw gunstige type), reguliere expressies, htmlentities, strip_tags. Ik stel voor de controlemodellen in een aparte map op te slaan en de bestanden hierin alleen aan te roepen als het echt nodig is.

Desgewenst kun je je projectje ook naar mij toesturen als je het echt niet ziet zitten...

Bedankt voor je snelle reactie,

Ik ging ervanuit dat de gebruiker geen manier heeft om te zien wat er in een server sided sessie gebeurt, tegenover de hidden value HTML tag die vanaf de gebruikers' machine wordt verstuurd. Ik strip inderdaad al form input van ongewenste mogelijke injectie input, maar zit nog steeds met het feit dat ik weet dat de verkeerde methode gebruikt wordt om variabelen door te geven.

Wat ook moeilijk is is vanaf een initieel overzicht de waarde aan een php script doorgeven. Wat ik hiermee bedoel (voorbeeld alert..);

Ik heb een lijst met zeg 30 diensten, welk allemaal uit de database worden getrokken en onder elkaar gezet. Elke dienst heeft een unieke "id", waarmee deze word onderscheiden van andere diensten. Deze unieke dienst id word voor elke dienst opgeslagen in een bijbehorende "hidden input" HTML tag. De gebruiker kan zich opgeven voor een openstaande dienst door op de knop "Inschrijven" te drukk die naast elke dienst wordt weergeven. Tot zover goed.

Nou wil een kwaadwillende gebruiker eens het systeem in de war schoppen en besluit deze id aan te passen en wellicht al toegewezen diensten over te schrijven door een al bestaande id van een andere dienst op te geven, of het systeem te laten crashen door sql injectie code in de hidden value te plaatsen of een andere foutieve waarde.

Vraag: Hoe kan ik het systeem laten begrijpen om welke dienst het gaat die de gebruiker selecteert, maar wel dat het veilig is en dat de gebruiker er geen misbruik van zou kunnen maken?

In dat geval zou ik ook voor de 30 diensten een aparte MySQL-tabel maken. Het id-nummer zou ik meegeven met de URL.

Wat betreft SQL-injecties: deze kun je tegengaan door invoerwaarden te controleren en eventueel te escapen (mysql_real_escape_string).

Off-topic:

Een veel betere aanrader is PDO (hier een tutorial), waarmee je meerdere databasesystemen kunt gebruiken zonder complete codeblokken om te ploegen.

quote:

Op donderdag 5 januari 2012 22:29 schreef Ofyles2 het volgende:
In dat geval zou ik ook voor de 30 diensten een aparte MySQL-tabel maken. Het id-nummer zou ik meegeven met de URL.

Wat betreft SQL-injecties: deze kun je tegengaan door invoerwaarden te controleren en eventueel te escapen (mysql_real_escape_string).

Off-topic:

Een veel betere aanrader is PDO (hier een tutorial), waarmee je meerdere databasesystemen kunt gebruiken zonder complete codeblokken om te ploegen.

Of je verdiept je een keer in classes en bent ook per direct van het gezeik af. Dan ben je nog flexibeler

quote:

Op donderdag 5 januari 2012 21:40 schreef Dokay het volgende:
Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.

Dat gaat in dezelfde sessie, je kunt $_SESSION['blahblah'] met vullen en daarna $_SESSION['user'] met wat anders.

quote:

Op donderdag 5 januari 2012 22:34 schreef GlowMouse het volgende:

[..]

Dat gaat in dezelfde sessie, je kunt $_SESSION['blahblah'] met vullen en daarna $_SESSION['user'] met wat anders.

Bedankt voor je tip, ik ga het morgen meteen uitproberen!
Is er ook een mogelijkheid om van te voren gedefinieerde waarden (welke ik nu in hidden HTML tags heb staan) veilig over te dragen tijdens de POST naar de volgende pagina..? (Behalve strip tags, eigenlijk dat er geen wijzingen in welke zin dan ook mogelijk zijn van de huidige waarde..)

quote:

Op donderdag 5 januari 2012 22:37 schreef Dokay het volgende:

[..]

Bedankt voor je tip, ik ga het morgen meteen uitproberen!
Is er ook een mogelijkheid om van te voren gedefinieerde waarden (welke ik nu in hidden HTML tags heb staan) veilig over te dragen tijdens de POST naar de volgende pagina..? (Behalve strip tags, eigenlijk dat er geen wijzingen in welke zin dan ook mogelijk zijn van de huidige waarde..)

Yep.

Je kunt bepaalde dingen hashen, met een POST/GET meesturen en aan de andere kant checken. Dat kan natuurlijk alleen met dingen waarvan je aan beide kanten weet wat het ongeveer moet zijn, statische data dus. Andere data zou ik, mits dat niet teveel problemen oplevert via de sessie opslaan, mocht het data zijn die je langer nodig hebt dan een sessie idd in de db.

quote:

Op donderdag 5 januari 2012 22:31 schreef Pakspul het volgende:

[..]

Of je verdiept je een keer in classes en bent ook per direct van het gezeik af. Dan ben je nog flexibeler

Klopt, daar ben ik ook zeer grote voorstander van (als onderdeel van MVC- en OOP-programmeren).

Bedankt voor jullie reacties! Ik ga morgen eens kijken of ik verder kom.

Hadden jullie dit al gezien?

http://tweakers.net/nieuw(...)ia-sql-injectie.html

.

Er zijn teveel amateurs

quote:

Op vrijdag 6 januari 2012 00:44 schreef GlowMouse het volgende:
Er zijn teveel amateurs

It wasn't me...

quote:

Op vrijdag 6 januari 2012 00:44 schreef GlowMouse het volgende:
Er zijn teveel amateurs

*meldt.

Daarom ga ik ook niet datsoort systemen klussen, Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen? Echt wtf! Blijkbaar heeft iemand er wel over nagedacht dus, maar toen besloten dat mysql_real_escape() te moeilijk was ofzo Nog even los van de vragen over hoe dat in hemelsnaam gehashed is als die input zo de query in geslingerd wordt...

quote:

Op vrijdag 6 januari 2012 00:54 schreef KomtTijd... het volgende:

[..]

Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen?

Die reden zal wel later bedacht zijn. Als hashing ontbreekt zal de lengte van het db-veld de ware reden achter de beperking tot 12 karakters zijn.

quote:

Op vrijdag 6 januari 2012 00:54 schreef KomtTijd... het volgende:

[..]

*meldt.

Daarom ga ik ook niet datsoort systemen klussen, Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen? Echt wtf! Blijkbaar heeft iemand er wel over nagedacht dus, maar toen besloten dat mysql_real_escape() te moeilijk was ofzo Nog even los van de vragen over hoe dat in hemelsnaam gehashed is als die input zo de query in geslingerd wordt...

Zoiets hoor je eerder op te lossen met preg_match en PDO.

quote:

Op vrijdag 6 januari 2012 00:57 schreef Ofyles2 het volgende:

[..]

Zoiets hoor je eerder op te lossen met preg_match en PDO.

Preg_match En ja tegenwoordig doet iedereen dat met PDO of MySQLi (of aanverwanten in andere talen) maar als die website 5 jaar oud is ga je 'm niet helemaal herschrijven daarvoor.

quote:

Op vrijdag 6 januari 2012 00:59 schreef KomtTijd... het volgende:

[..]

Preg_match En ja tegenwoordig doet iedereen dat met PDO of MySQLi (of aanverwanten in andere talen) maar als die website 5 jaar oud is ga je 'm niet helemaal herschrijven daarvoor.

Preg_match voor reguliere expressies. Je kunt nooit 100% zeker zijn dat al je bezoekers zo poeslief zijn...

Ik weet wat preg_match is.

Maar als tientallen mensen die jarenlang gestudeerd hebben op SQL injectie een functie maken die dagelijks door duizenden kwaadwillende mensen beproefd wordt, om alle mogelijke manieren van SQL injectie te voorkomen, maar jij denkt dat je het beter kunt met een preg_match, ben je wel redelijk naief.

quote:

Op vrijdag 6 januari 2012 01:50 schreef KomtTijd... het volgende:
Ik weet wat preg_match is.

Maar als tientallen mensen die jarenlang gestudeerd hebben op SQL injectie een functie maken die dagelijks door duizenden kwaadwillende mensen beproefd wordt, om alle mogelijke manieren van SQL injectie te voorkomen, maar jij denkt dat je het beter kunt met een preg_match, ben je wel redelijk naief.

Ik combineer preg_match met string escapen. Overbeveiliging.

Kort vraagje:
Ik zit met een formulier dat ik wil opslaan in een oracle database. Maar natuurlijk is dit een vrij invoerveld waar oa een naam meegegeven moet worden.
Dus je zit met ' in namen enzo, wekle problemen geven bij de query, dus die moeten eruit.

wat zou de mooiste oplossing hiervoor zijn? Vervangen door een ander teken en die dan weer bij oproep veranderen in een ' ?

Bron: http://php.net/manual/en/function.addslashes.php

quote:

Op vrijdag 6 januari 2012 10:34 schreef Scorpie het volgende:
Bij SQL queries http://php.net/manual/en/function.mysql-real-escape-string.php

Dat dus!

quote:

Op vrijdag 6 januari 2012 10:31 schreef Pakspul het volgende:

[ code verwijderd ]

Bron: http://php.net/manual/en/function.addslashes.php

Die zag ik idd voorbij komen.
Hij komt bij mij dan gelijk met 2 of 3 slashes aanzetten

[ Bericht 15% gewijzigd door Cue_ op 06-01-2012 10:49:14 ]

quote:

Op vrijdag 6 januari 2012 10:34 schreef Scorpie het volgende:
Bij SQL queries http://php.net/manual/en/function.mysql-real-escape-string.php

quote:

Op vrijdag 6 januari 2012 10:34 schreef GI het volgende:

[..]

Dat dus!

quote:

A MySQL connection is required before using mysql_real_escape_string() otherwise an error of level E_WARNING is generated, and FALSE is returned.

Hmm hij blijkt hem zelf al te escapen. Toch vind mijn query hem niet leuk:

http://orafaq.com/wiki/SQL_FAQ

How does one escape special characters when writing SQL queries?