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
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.
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
...
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.
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.
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.
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.
mysql_query("SELECT FROM Users WHERE name = '" . $user_name . "'");
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:
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.
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
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?
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)
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
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.
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.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
