Veiligste manier
Een jaartje terug ben ik met php beginnen werken.
Ik heb in mijn vrije tijd al veel projecten afgemaakt.
Soms zet ik php scripts in een html bestand en echo de juiste tekst die in de html weergegeven moet worden en soms stuur ik met javascipt een xml request naar een apart php bestand en stuur dan json terug.
Nu is mijn vraag wat de beste, snelste en veiligste manier van werken is?
Alvast bedankt
Groetjes Yorick
Ikzelf heb een eigen MVC frameworkje gebouwd, waarin ik de view in Smarty templates (tegenwoordig zou ik Twig gebruiken) verwerk. Maar als de output JSON is, dan zorg ik gewoon voor die output en heb ik Smarty niet nodig.
Andersom kan wel.
Met javascript en html bouw ik de website op.
Met php haal ik een variabel aantal gegevens uit de database of voeg data toe.
Ik weet niet welke manier het veiligste tegen hackers.
@Pipo Clown: Ik heb het fout verwoord. Het gaat wel degelijk over een .php bestand. Hierin staat een html/javascipt website met stukjes php script
@Pipo: Dat kan wel met dit in htaccess: "AddType application/x-httpd-php .html .htm", maar het is best zinloos. Als je html-extenties wilt tonen kan je je beter richten op mod_rewrite waarmee de URL alleen maar herschrijft.
Wat houdt dit in?
Filter Input
Indien je bepaalde invoer en/of invoer van een bepaalde vorm verwacht, bijvoorbeeld je verwacht een numerieke querystring-variabele "id" op grond waarvan je een database-item laadt, dan controleer en filter je hier op. Je controleert dus zowel op het bestaan van $_GET['id'] en ook of deze variabele een numerieke waarde bevat (dit kan op verschillende manieren). Indien NIET aan deze voorwaarden is voldaan zou je applicatie een fout moeten genereren of zou deze dit moeten ondervangen. Het heeft in ieder geval geen zin om bijbehorende query uit te voeren, want $_GET['id'] is niet beschikbaar of ongeschikt.
Dit principe geldt ook voor de verwerking van formulier-invoer, initialisatie van gegevens et cetera. Eigenlijk zou je in alles wat je doet jezelf moeten afvragen: moet ik hier filteren / iets controleren?
Escape Output
Dit is eigenlijk de tegenhanger van filter input. Ten eerste moet je je te allen tijde bewust zijn van het feit dat je altijd in een context werkt. Bijvoorbeeld je bent een HTML-document aan het opbouwen, dan ben je in de HTML-context bezig. Of je doet iets met JavaScript (JS-context) of je bent een query aan het opbouwen (SQL-context).
In al deze contexten zijn er speciale karakters die speciale betekenissen hebben. Denk bijvoorbeeld aan de karakters <, >, & en " in HTML. Deze hebben mogelijk een betekenis die verder voert dan bijvoorbeeld enkel "het kleiner dan teken". Dit kan het begin zijn van een HTML-tag. Vaak is het verstandig om dit soort speciale karakters te ontdoen van hun speciale betekenis binnen die context. Te meer als deze invoer afkomstig is van eindgebruikers (User Input).
Elke context heeft speciale escaping-functies om data te ontdoen van de speciale betekenis die deze data mogelijk heeft. Zo is daar htmlspecialchars() voor het onschadelijk maken van HTML en de _real_escape_string() functies voor MySQL.
Het is echter HEEL BELANGRIJK dat deze escaping-functies op de juiste manier toegepast worden. De correcte werking van het escapen van data hangt namelijk nog van iets anders af: de character encoding. Dit is de opslagmethode van data in het geheugen. Afhankelijk van de character encoding kan een karakter (bijvoorbeeld ë) verschillende encoderingen (representaties in het geheugen) hebben, maar op je scherm zie je nog steeds een ë, mits je document voorzien is van een aanduiding van een overeenkomstige character encoding, bijvoorbeeld door middel van een meta-tag of een PHP header().
De beste manier is om altijd expliciet te vermelden om welke character encoding het gaat.
Ingeval van PHP waarbij je html wilt escapen met behulp van htmlspecialchars() kun je dit aangeven d.m.v. de derde parameter.
Ingeval je iets wilt escapen in een SQL-string (om het onderscheid te maken tussen SQL en DATA om zodoende SQL-injectie te voorkomen) moet je bij het maken van een connectie aangeven in welke character encoding je wenst te communiceren. Dit doe je doorgaans door middel van een _set_charset() methode net na het maken van een connectie of door een charset-parameter op te nemen in je DSN indien je van PDO gebruik maakt. De character encoding instellen na afloop van het maken van een connectie met behulp van SET NAMES of iets dergelijks is de verkeerde manier!
En om dingen nog complexer te maken dien je _real_escape_string() functies ALTIJD te gebruiken in combinatie met quotes. Het een is namelijk niet veilig zonder het ander, de _real_escape_string() functies zijn namelijk geen wondermiddel en ESCAPEN NIETS ALS ER NIETS TE ESCAPEN VALT.
Als je op enigerlei wijze de volgende string in een query kunt krijgen dan is SQL-injectie mogelijk als je wel _real_escape_string() toepast, maar geen quotes:
Code (php)
1
OR 1=1
Dit komt namelijk omdat _real_escape_string() geen karakters escaped in bovenstaande string. Deze DATA zal dus (door het ontbreken van extra quotes) als SQL geinterpreteerd worden waarmee de SQL-injectie in principe is geslaagd.
En tot slot: Never Trust User Input. Simpelweg omdat je gebruikersdata eenmaal in je database hebt gekregen wil niet zeggen dat deze ineens onschadelijk is dus wanneer je deze weer uitleest (om bijvoorbeeld in een HTML-document te worden weergegeven) begint het spel opnieuw: deze zal opgehaald moeten worden met de character encoding die je in het document wilt gebruiken en zal vervolgens in overeenkomstige character encoding ge-escaped moeten worden bij het weergeven, tenzij je de gebruiker voldoende vertrouwt en/of dat het daadwerkelijk de bedoeling is dat deze zelf HTML kan schrijven. Er zijn natuurlijk altijd uitzonderingen mogelijk maar deze zouden dan wel gedocumenteerd moeten worden.
Gewijzigd op 01/08/2017 01:28:43 door Thomas van den Heuvel
Bedankt voor je uitleg.
Ik had al een beetje gehoord over deze veiligheidsfuncties maar ik wist nooit wanneer ik deze moest gebruiken. Nu weet ik het dus wel.
Als ik je uitleg goed begrijp, maakt het eigenlijk niet uit of ik werk met een aparte php pagina of niet?
Ik moet gewoon altijd zorgen dat mijn data niet gehackt kan worden?
Of heb ik het fout begrepen?
Je hoeft er niet per se voor te zorgen dat je data niet gehacked kan worden in die zin dat je op voorhand alles desinfecteert met DDT zodat alles morsdood is - escape-on-input bijvoorbeeld (data op voorhand permanent onschadelijk maken) is meestal niet wenselijk (omdat je af en toe niet weet in welke context deze gebruikt gaat worden, op voorhand escapen voor een specifieke context is dan ook niet verstandig).
Wel moet je er voor zorgen dat je er altijd rekening mee houdt dat deze data potentieel gevaarlijk is, en vervolgens neem je passende maatregelen (waar nodig input filtering en output escaping).
Op het moment dat deze bewustwording er is, en je je altijd elke keer afvraagt "hee, dit is data uit bron X, moet hier iets speciaals mee" (en hier vervolgens op acteert, uiteraard) dan ben je al een heel eind.
Gewijzigd op 01/08/2017 19:31:47 door Thomas van den Heuvel
Ik heb nog één vraag.
Je zei dat inhoud in je webdirectory altijd opvraagbaar is.
Kan je php code dan ook opvragen?
Maar je moet wel rekening houden dat je geen lekken openzet waarmee mensen files op de server kunnen uitlezen, zoals bijvoorbeeld met $_GET i.c.m. met file-functies.
Gewijzigd op 03/08/2017 22:59:45 door - Ariën -
Bedankt iedereen!