login  Naam:   Wachtwoord: 
Registreer je!
 Forum

$xx gebruik ipv $_GET['xx']

Offline Martijn - 29/05/2013 09:29
Avatar van MartijnCrew PHP De vraag maakte een lastige titel 

Ik heb een hoop oude sites onder mijn beheer, waarvan een paar de instellingen ouderwets hebben staan. Er kan $voorbeeld worden gebruikt als $_GET['voorbeeld'] of $_POST['voorbeeld'] een waarde heeft.

Dat is niet zo erg op onze eigen servers (langzaam is dit aan het verbeteren), maar 1 van onze sites gaat naar een nieuwe server waar dit niet meer kan.
Weet iemand hoe die heet (en dan bedoel ik niet 'verkeerd':P) en of er een manier is om deze op te zoeken via bv de commandline? Zou een heel hoop tijd kunnen schelen

12 antwoorden

Gesponsorde links
Offline Koen - 29/05/2013 09:39
Avatar van Koen PHP expert Hoi Martijn,

Ik denk dat je op zoek bent naar de instelling "register globals" die bij jou aan staat. Alle global arrays (GET, POST, SESSION, ...) worden ge-extract naar gewone variabelen. Vanaf PHP4.2 staat deze standaard uit ivm beveiliging. Bijvoorbeeld: admin.php?logged_in=true zorgt ervoor dat $logged_in (die eigenlijk van een session komt) alsnog op true komt te staan.

Ik denk dat deze functie je aardig op weg zal helpen.

Have fun 
Bedankt door: Martijn
Offline Martijn - 29/05/2013 09:47
Avatar van Martijn Crew PHP Oke, ik weet niet of ik exact iets aan die functies heb zoals ze zijn, maar ik heb er wel een goed idee door gekregen hoe ik ze kan vinden. Bedankt, dit was exact wat ik zocht. Ik weet dat het slecht is Daarom wilde ik het goed aanpakken.


Ik laat die topic nog heel even staan, dan kunnen anderen het even lezen
Offline Koen - 29/05/2013 09:53
Avatar van Koen PHP expert Blij dat te horen. Succes ermee!
Offline Martijn2008 - 30/05/2013 14:46
Avatar van Martijn2008 PHP beginner
Koen schreef:
...
Vanaf PHP4.2 staat deze standaard uit ivm beveiliging. Bijvoorbeeld: admin.php?logged_in=true zorgt ervoor dat $logged_in (die eigenlijk van een session komt) alsnog op true komt te staan.
...


Dat is een interessante tip, want hoe nu om te gaan met XSS en SQL-injection? Dat zou volgens mij betekenen dat iedere waarde minimaal door mysql_real_escape_string() moet worden gehaald.
Offline Martijn - 30/05/2013 16:18 (laatste wijziging 30/05/2013 16:19)
Avatar van Martijn Crew PHP Iedere waarde moet sowieso minimaal door mysql_real_escape_string() heen gehaald moeten worden tenzij je absoluut zeker bent dat een user de inhoud van de variabel niet kan bepalen, linksom of rechtsom.

Edit: Opheldering is handig voor het laatste stukje. Stel je slaat de input van iemand op in je database, dan real_string(), maar als je die waarde in een andere query gebruikt, dan real_string() je m ook.
Offline Koen - 31/05/2013 09:51
Avatar van Koen PHP expert Er is een reden waarom mysql_* statements deprecated zijn vanaf PHP versie 5.5. Het is gewoon te gevaarlijk om de bescherming tegen SQL injections (tegenwoordig van fundamenteel belang) enkel door de programmeurs te laten doen.

Het is aangeraden om over te stappen op PDO (PHP Data Objects), MySQLi of een soortgelijk systeem voor de datamanipulatielaag. Om de meeste SQL injections tegen te gaan is het al voldoende om gebruik te maken van prepared statements.

Prepared statements kan je in zekere zin vergelijken met stored procedures.

Voorbeeldje (met pdo):

  1. <?php
  2. $pdoStatement = $DB->prepare("INSERT INTO USERS (name, email) VALUES (:name, :email)");
  3.  
  4. $pdoStatement->execute(':name' => array($_POST['name'], ':email' => $_POST['email']));
  5. ?>

Zoals je ziet scheiden we de parameters van de SQL query in kwestie. Deze parameters kan je aangeven in twee vormen: ? en :parameter_naam.

Op die manier wordt die SQL Query en zijn parameters apart verzonden. Wanneer je prepare() aanroept op de Database Context, wordt de query al geëvalueerd door de database. Als je dan achteraf dat statement oproept en er de parameters van invult, is er al geweten wat de query is en wat de parameter is.

Dit verschilt dus fundamenteel met de vroegere benaming waarop je gewoon een SQL string rechtstreeks naar de databank stuurde.

  1. mysql_query("SELECT FROM Users WHERE name = '" . $user_name . "'");


Iedereen kan zich vast wel een voorstelling maken van wat er zou gebeuren wanneer $user_name de volgende waarde zou bevatten: Koen'; DROP DATABASE sitemasters; --.


Opgelet: Volgens wat ik gelezen heb, worden bij PDO de prepared statements door PHP standaard "geëmuleerd". Wanneer je dit liever door de database wilt laten afhandelen, gebruik je deze optie op de Database Context:

  1. $DB->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);


Bijkomend voordeel bij het gebruik van prepared statements is dat deze op voorhand worden meegegeven met de databank. De databank kan dan een plan opstellen hoe het optimaal door zijn data kan gaan zoeken. Bij het meermaals gebruik van één en dezelfde prepared statement is er dus maar één query plan nodig bij de database, omdat enkel de parameters veranderen.

Further reading:
http://php.net/manual/en/pdo.prepare.php
http://php.net/manual/en/book.pdo.php
http://php.net/manual/en/book.mysqli.php
http://xkcd.com/327/
http://stackoverflow.com/a/60496/2427543
Bedankt door: Martijn2008
Offline Martijn - 31/05/2013 16:23
Avatar van Martijn Crew PHP Nadeel van de prepared statement is dat de overhead wat hoger is. Prepared statements scoren weer goed bij grote hoeveelheid insert, maar bij enkele queries minder (heb ik een tijd geleden gelezen)

Weet niet hoe het zit met PDO. Ik heb er ook aan zitten denken, want de voordelen zijn wel aangenaam. Maakt het hele injectieverhaal toch een stuk comfortabeler
Bedankt door: Martijn2008
Offline Martijn2008 - 01/06/2013 00:35
Avatar van Martijn2008 PHP beginner Geweldig deze kennisdeling. Hoe denken jullie bijvoorbeeld over een database framework als Propel of Doctrine? Dat in plaats van de oude 'wel vertrouwde' weg of MySqli?

Ik heb laatst met het php framework Symfony een uitstapje gemaakt naar Doctrine. Dat is goed bevallen, lekker snel goede code schrijven.

Is performance echt een groot issue of kan de hedendaagse hardware zo'n database framework wel aan?

Offline WouterJ - 01/06/2013 13:55
Avatar van WouterJ HTML gevorderde Doctrine en propel zijn enorm geoptimaliseerd, je hoeft je geen zorgen te maken over enorme overhead.

Sommige devs zullen orm's slecht vinden, omdat je zelf niet meer de sql schrijft en daarom totaal niet weet wat er aan de hand is. Ik hou wel van orm's. (en daarnaast, de webprofilertoolbar geeft je een mooi inzicht in de queries)
Offline Martijn - 04/06/2013 10:08 (laatste wijziging 10/06/2013 16:20)
Avatar van Martijn Crew PHP Ikzelf vind 'de hardware kan het wel aan' een situatie waar ik geen rekening mee hou. Ik zorg dat mijn code efficiënt is (zover het praktisch haalbaar is). Juist omgaan met je resources, beetje tactisch nadenken... Een hoop is makkelijk te halen. En als je dan hardware hebt die er niet zn best voor hoeft te doen, heb je een turbo website. Na verloop van tijd wordt het een gewoonte en maak je vanzelf websites die lekker opschieten.

Voordeel van deze is dat je moet leren hoe PHP geïnterpreteerd wordt door de machine, voordat je er gebruik van kan maken. Nadeel is dat het wat langer kan duren.
-------------------------------------------------
Edit:
Weet iemand een briljante manier om deze makkelijk te vinden? Via een commandline ofzo? Ik ben bang van niet, maar ik kan het altijd proberen. Het weer uitzetten van register_globals kan namelijk niet zomaar, ons CMS moet wel blijven werken, als ik er 1 mis heb ik een probleem
Offline WouterJ - 10/06/2013 17:04
Avatar van WouterJ HTML gevorderde Je bedoelt het vinden van de variabele $xx? Nee, dat kan niet, aangezien deze variabelen niet verschillen van de gewone variabelen.

Mijn idee: uitzetten en kijken waar hij vastloopt, die variabele dan in het hele bestand fixen en dan kijken waar hij dan vastloopt, dat ook weer fixen, ect.
Offline Thomas - 17/10/2014 14:50
Avatar van Thomas Moderator Ik kwam toevallig dit topic tegen en ook al is dit topic al wat gedateerd, het behandelde onderwerp en de bijbehorende principes zijn nog altijd actueel.

Als ik het goed begrijp gaat een oude site naar een nieuwe(re) server, waarbij op de nieuwe server register_globals uit staat (of in het geheel niet meer bestaat, en daarmee impliciet uit staat). Daarbij wil je op een of andere manier nagaan of (en vooral welke) variabelen worden gebruikt als superglobals ($_GET, $_POST, $_COOKIE, $_SESSION etc.).

Maar dit zal dus uit het gebruik (de toepassing / de betekenis) van een variabele moeten blijken. Omdat dit verder voert dan een simpele syntax-kwestie, wordt dit vrij lastig (zo niet onmogelijk) om dit geautomatiseerd uit te voeren, de code moet namelijk geïnterpreteerd worden. En zelfs al zou dit kunnen, dan kun je hier niet simpelweg een search and replace op de gevonden resultaten loslaten, wederom vanwege voorgenoemde interpretatie.

Om een heel simpel voorbeeld te geven: je zou in een formulier in de action-property een URL-variable 'X' kunnen hebben. Tegelijkertijd zou de method-property van dit formulier 'post' kunnen zijn, en tevens bevat het formulier een veld met naam 'X'. Hoe zou een machine die de code interpreteert bij de verwerking $_GET['X'] en $_POST['X'] uit elkaar moeten houden?

Daarnaast kunnen oplossingen (denk ook aan "workarounds" en "hacks") die toentertijd zijn gebruikt in het geheel niet meer werken in de nieuwe opzet, je zult in dat geval sowieso code moeten omschrijven.

Ik denk dat de eerste stap die men (dit is iedereen: programmeurs, projectleiders en vooral klanten) moet nemen is het accepteren van het feit dat code veroudert. Ook al verandert programmacode zelf (inhoudelijk) niet, veranderen de technieken eromheen (hardware en software) wel. Op een gegeven moment zal die programmacode dus niet meer doen wat deze zou moeten doen omdat het gat tussen de code en de techniek te groot is geworden.

Het klinkt gewoon alsof je code is verouderd en niet meer past in de nieuwe situatie en je zoekt naar een snelle en goedkope manier om dit op te lossen.
Martijn schreef:
Het weer uitzetten van register_globals kan namelijk niet zomaar, ons CMS moet wel blijven werken, als ik er 1 mis heb ik een probleem
In zekere zin had je al een probleem, dit is het moment waarop je de interest op je technical debt zult moeten inlossen. Ik verwacht niet dat de oplossing snel of pijnloos zal zijn.

Zoals ik het zie zijn er een aantal oplossingen: of je gaat een migratietraject in waarin je de code omschrijft en test (heb je bij wijze van test de code op de nieuwe omgeving al eens uitgeprobeerd?) in een aantal iteraties, waarbij je eerst eens een onderzoek doet naar de haalbaarheid ervan, of je schrijft de code opnieuw. Je zou ook kunnen kiezen voor de uitbesteding hiervan of het aanschaffen van een pakket die een soortgelijke functionaliteit biedt.

Overigens:
Koen schreef:
Iedereen kan zich vast wel een voorstelling maken van wat er zou gebeuren wanneer $user_name de volgende waarde zou bevatten: Koen'; DROP DATABASE sitemasters; --.
Dat is een broodje aap verhaal. mysql_query ondersteunt geen multiple queries (als dat de gebruikte techniek is). Neemt niet weg dat je input filtering en output escaping zou moeten toepassen. Omdat de oorspronkelijke code (zelfs) geen superglobals gebruikt, betwijfel ik of dit gebeurt.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.377s