Door
Tim Wolf
op 19-02-2016 20:28
gewijzigd op 19-02-2016 20:30
3.765 views
Hallo PHPHulp,
Ik maak gebruik van gratis hosting die binnenkort php 5.4 niet meer ondersteund en overgaat naar 7.0 (je kunt nog wel kiezen uit 5.6) Maar mijn vraag is als ik 7.0 aanzet dan zie ik allemaal errors met mysql en meer. Aangezien dit een lange topic wordt aangezien er meerdere delen van een script aan bot komt.
1ste error. Toevoeging: Error 1:
Mijn eerste error is
Fatal error: Uncaught Error:
Call to undefined function mysql_connect() in /home/prive/public_html/members_area/config.php:12
Stack trace: #0 /home/prive/public_html/members_area/index.php(2):
include() #1 {main} thrown in /home/prive/public_html/members_area/config.php on line 12
Volgens mij niet Bart, stripslashes() wordt éérst uitgevoerd, en dan pas de real_escape_string functionaliteit. Wat hier dus uiteindelijk uitkomt is veilig (of liever gezegd, veiliger, zie kanttekening hieronder) in de MySQL-context mits je character encoding klopt.
Overigens worden er ook al enige tijd geen backslashes meer automatisch toegevoegd aan waarden van superglobal variabelen, omdat magic_quotes_gpc ook (en al eerder) is verdwenen (verwijderd vanaf PHP 5.4.0). Het enige "gevaar" met het gebruik van stripslashes -sinds het verdwijnen van magic_quotes_gpc- is dus dat er mogelijk teveel backslashes worden verwijderd uit de invoer, die echt onderdeel uitmaakten van de invoer, en niet (per definitie) bedoeld waren voor escaping.
EDIT: cruciale kanttekening: het is pas echt veilig als het ge-real_escape-te deel tussen (enkele) quotes in je query staat. Alleen deze combinatie is veilig. Het een is niet veilig zonder het ander want real_escape_string escapet alleen maar gevaarlijke karakters. Als invoer geen gevaarlijke karakters bevat, bijvoorbeeld:
41 OR 1 = 1
Dan escapet real_escape_string niets omdat er niets te escapen valt!
real_escape_string is dus geen wondermiddel, je moet hier nog steeds voorzichtig mee omgaan!
Zoals eerder aangegeven, mogelijk zorgen de voorkomens van stripslashes ervoor dat er teveel gestript wordt. Dit stamt nog uit een tijdperk dat er aan de superglobals ($_GET, $_POST, $_COOKIE) automagisch extra slashes werden toegevoegd middels magic_quotes_gpc (en dit was niet eens vanwege security, maar meer vanuit gebruikersgemak). Deze voorziening is inmiddels verdwenen. Indien je de voorkomens van stripslashes() dan niet ook verwijdert, worden er mogelijk teveel slashes gestript uit je invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Zoals eerder aangegeven, mogelijk zorgen de voorkomens van stripslashes ervoor dat er teveel gestript wordt. Dit stamt nog uit een tijdperk dat er aan de superglobals ($_GET, $_POST, $_COOKIE) automagisch slashes werden toegevoegd middels magic_quotes_gpc. Deze voorziening is inmiddels verdwenen. Indien je de voorkomens van stripslashes() dan niet ook verwijderd, worden er mogelijk teveel slashes gestript uit je invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Klopt wordt bij de tool ook aangegeven: "Note that absolutely no security checks are performed", lijkt mij ook dat je dit zelf doet.
Security is ook een factor, maar ik had het hier meer over mogelijk ongewenste manipulatie/verminking van je invoer. Uiteraard dient de invoer zowel volledig (en (dus) ongewijzigd) en veilig worden aangeboden aan de database. Maar dit zijn echt twee verschillende dingen.
