Records worden soms te laat opgeslagen

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Data die in je systeem zit zou je niet als veilig moeten zien.

      Stel dat, om wat voor reden dan ook, gebruikersnamen of andere teksten van een profield de input "</div>" toestaan. Als je dit vervolgens zonder escaping weergeeft ligt je layout in puin. En zo zijn er nog wel andere zaken denkbaar zoals AJAX-calls naar een externe site als jij een profiel bekijkt ofzo... Escape altijd output, tenzij je een speciale, en gedocumenteerde, reden hebt om dat niet te doen.

      En om toch terug te komen op het voorgaande, vergelijk:

      PHP Source Code

      1. $sql = "SELECT something FROM table WHERE condition='".$condition."'";
      De vraag is dan elke keer opnieuw: is $condition gevalideerd / veilig? Of beter gezegd: is dat een query die altijd het gewenste resultaat geeft? Iedereen die dat stuk code ziet zou zich dat af moeten vragen. Dat kost elke keer weer (interpretatie)tijd.

      Vergelijk dit met:

      PHP Source Code

      1. $sql = "SELECT something FROM table WHERE condition='".$db->escape($condition)."'";

      Waarbij $db->escape() een shorthand is voor real_escape_string(). Het maakt in dat geval niet uit of $condition veilig was voor gebruik in een query of niet - de combinatie escaping-functie + quotes garandeert dit. Op een soortgelijke wijze zou je prepared statements kunnen gebruiken, ook dat is een methode om te waarborgen dat DATA niet als SQL geinterpreteerd kan worden (dit is in feite wat SQL-injectie mogelijk maakt).

      Het dilemma in het eerste fragment is dus altijd of escaping bewust achterwege is gelaten of per ongeluk is vergeten. Je introduceert hiermee twijfel. Als je gewoon consequent alles escaped is er NOOIT ruimte voor twijfel. Zodat je hier dan ook nooit meer over na hoeft te denken.

      The post was edited 2 times, last by FangorN ().

    • Bedankt FangorN.

      In mijn geval is $ingame altijd geescaped, dit gebeurt al in de config file die overal word toegevoegd (En zonder die is er sowieso geen database connectie mogelijk).
      Ik snap dat op de locatie zelf escapen altijd zorgt dat het goed is en het is gelijk zichtbaar (Mochten er later anderen in de code kijken).
      Maar in dit geval word $ingame op slechts 1 locatie aangemaakt en is daar gelijk geescaped tegen injectie.

      Wanneer ik andere waardes gebruik in een query worden die wel in de query zelf geescaped, maar aangezien $ingame in elk scripts meerdere keren word gebruikt leek me escapen op 1 locatie makkelijker en kan het daardoor ook niet vergeten.
      Maar je uitleg is wel logisch kan het misschien beter op de plek zelf toepassen zodat het duidelijker is.
    • pekelterror wrote:

      en kan het daardoor ook niet vergeten
      Totdat je dit wel een keer doet :p. Het is gewoon wachten op een ongeluk.

      pekelterror wrote:

      Maar je uitleg is wel logisch kan het misschien beter op de plek zelf toepassen zodat het duidelijker is.
      Het is gewoon vele malen consequenter. Plus je hoeft er dan gewoon niet meer over na te denken, dus het is ook gewoon stukken simpeler (ook een goed ontwerpprincipe: Don't Make Me Think). Escape waarden op het moment dat je deze in een context onschadelijk wilt maken. Maar niet vantevoren.

      Als je gewoon deze laatste aanpak gebruikt weet je meteen wanneer iemand vergeten is een waarde te escapen, je hoeft dan niet eens de afweging te maken op grond van de inhoud van de variabele, escape gewoon altijd, maar dan dus wel op het goede moment :).

      Hetzelfde geldt voor de context waarbinnen de waarde ontdaan moet worden van een mogelijk speciale betekenis: wat "speciaal" is hangt van de context af - deze hoeft ook niet altijd op voorhand vast te staan. Zou je dan zo'n variabele maar op voorhand dood moeten escapen voor alle mogelijke contexten? En wat dan als je een dump wilt doen naar een plaintext bestand, ga je dan weer alles un-escapen (denk aan "& amp;" enzo, ga je die weer terugvertalen naar "&"?). Je doet dan waarschijnlijk een hoop werk voor niets, werk waar je je later mogelijk mee in de vingers snijdt.

      Ah well.