• Inloggen
  • Registreer
  • Zoeken
Dit topic
  • Overal
  • Dit topic
  • Dit forum
  • Artikelen
  • Pagina's
  • Forum
  • Downloads
  • Meer opties

ICTscripters

Dé plek voor IT

Dé plek voor IT

Aanmelden

Geavanceerde opties
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
    3. Onopgeloste topics
  3. ICT Nieuws
  4. Blog
  5. Marktplaats
    1. Werk
    2. Advertenties
    3. Domeinnamen
    4. Websites
    5. Design & lay-outs
    6. Scripts
    7. Overige
  6. Design
  7. Leden
    1. Actieve bezoekers
    2. Team
    3. Leden zoeken
  8. Downloads
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
    3. Onopgeloste topics
  3. ICT Nieuws
  4. Blog
  5. Marktplaats
    1. Werk
    2. Advertenties
    3. Domeinnamen
    4. Websites
    5. Design & lay-outs
    6. Scripts
    7. Overige
  6. Design
  7. Leden
    1. Actieve bezoekers
    2. Team
    3. Leden zoeken
  8. Downloads
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
    3. Onopgeloste topics
  3. ICT Nieuws
  4. Blog
  5. Marktplaats
    1. Werk
    2. Advertenties
    3. Domeinnamen
    4. Websites
    5. Design & lay-outs
    6. Scripts
    7. Overige
  6. Design
  7. Leden
    1. Actieve bezoekers
    2. Team
    3. Leden zoeken
  8. Downloads
  1. Dé plek voor IT - ICTscripters
  2. Forum
  3. Marktplaats
  4. Vraag & Aanbod Werk

Forum

  • [Beta] Ottomaan: gratis browserspel met een echte, levende stad. Feedback gezocht!

    frio 27 oktober 2026 om 12:22
  • Port Father: beta van een browsergame in Antwerpen 1931, feedback welkom

    Jeroen.G 26 oktober 2026 om 10:33
  • Maffia Hotel: een browsergame waarin je van lobbygast naar spil van het hotel groeit

    eeyk 22 oktober 2026 om 18:43
  • Crime Club volledig herschreven vanaf nul

    frio 19 oktober 2026 om 23:57
  • Malavita (nieuwe maffia game, van 0)

    jos 19 oktober 2026 om 23:18
  • Herkent deze Notion-structuurscan echte problemen?

    Jeroen.G 19 oktober 2026 om 15:09
  • 🚀 WE ZOEKEN TESTERS! 🚀

    Servertjee 3 oktober 2026 om 10:56
  • Luchtvaartsoftware: Hoe technologie de moderne luchtvaart verandert

    saggy2829 30 september 2026 om 19:31

Marktplaats

  • [TE KOOP] Malavita.be [Maffiaspel, gebaseerd op omicidio.nl, unieke code]

    Dpm_x 26 oktober 2026 om 00:22
  • TK: Kraai.eu

    frio 25 oktober 2026 om 11:39
  • [TE KOOP] Likeboost24.nl: complete SMM-webshop met eigen merk, volautomatische levering en betalen op de eigen pagina

    Jeroen.G 16 oktober 2026 om 14:27

Scripter aangeboden

  • dmeigenaar
  • 23 januari 2019 om 19:51
  • FangorN
    Professional
    Artikelen
    2
    Berichten
    737
    • 27 januari 2019 om 15:45
    • #21
    Citaat van AarClay

    Alleen als je de waarde kan manipuleren, zoals bij $_POST, $_GET, $_COOKIE, $_SESSION, $_SERVER en $_ENV. De laatste twee zijn wat lastiger, maar het zou in de praktijk kunnen.

    Nou, nee dus. Data in je database kwam oorspronkelijk ook uit $_POST. Deze -of liever gezegd, ALLE input- zou je dus nog steeds op dezelfde manier moeten behandelen. Altijd.

    En alles van tevoren al onklaar maken (het escapen van input) is hiertoe geen oplossing.

    Het is helemaal niet erg als er potentieel "gevaarlijke data" in je database zit, zolang je deze maar op een uniforme manier behandelt. Wanneer je output altijd escaped is dit namelijk geen enkel probleem. Natuurlijk moet je zoveel mogelijk vantevoren valideren (filter input) maar dat neemt niet weg dat je alle data op dezelfde manier blijft behandelen. Dit houdt niet op als het de database in gaat.

  • Gast, wil je besparen op je domeinnamen? (ad)
  • AarClay
    Gevorderd
    Berichten
    424
    • 29 januari 2019 om 19:33
    • #22

    Huh?
    Welke input zie je nog meer dan mijn genoemde globals? Die moet je sowieso s
    al escapen!

    Als je een waarde van een fetched result hebt (bijv. $data['user']) in je WHERE-clausule, escape jij die dan ook?

  • FangorN
    Professional
    Artikelen
    2
    Berichten
    737
    • 29 januari 2019 om 19:43
    • #23

    Het is een misvatting om te denken dat je klaar bent met escapen wanneer de data in de database zit. Dit moet je gewoon altijd en overal doen, tenzij je een (gedocumenteerde) reden hebt om dit niet te doen.

    Het altijd consequent escapen van wat voor DATA dan ook is ook veel makkelijker, ik heb al eerder uitgelegd waarom.

  • AarClay
    Gevorderd
    Berichten
    424
    • 29 januari 2019 om 19:50
    • #24

    Ja, nu heb je het over output-escaping volgens mij. Die hoor je ook inderdaad te filteren met htmlentities of htmlspecialchars.

    Want het is natuurlijk niet de bedoeling dat iemand mysqli_real_escape_string() in iets anders dan een query gebruikt.. 8)7

  • FangorN
    Professional
    Artikelen
    2
    Berichten
    737
    • 29 januari 2019 om 19:52
    • #25

    Hoe je DATA escaped hangt van de context af waar je deze DATA gebruikt.

    Maar wellicht moet deze hele discussie naar een ander draadje verhuisd worden.

  • AarClay
    Gevorderd
    Berichten
    424
    • 29 januari 2019 om 19:55
    • #26

    En ikzelf zie die data als input, wat je sowieso moet escapen. Misschien is er verwarring in de communicatie. @FangorN Laat anders dan een voorbeeld zien. Ik ben benieuwd.

    Bewerkt 2 keer, laatst door AarClay (30 januari 2019 om 21:54).

  • FangorN
    Professional
    Artikelen
    2
    Berichten
    737
    • 31 januari 2019 om 00:00
    • #27

    * zucht *

    Citaat van AarClay

    En ikzelf zie die data als input, wat je sowieso moet escapen.

    Input filter je, output escape je.

    DATA kan zowel input als output zijn.

    Beschouw code.php?id=12

    $_GET['id'] is invoer van buitenaf (USER DATA).
    Deze kun je mogelijk filteren je om te zien of deze aan een bepaald formaat voldoet als je voor het gebruik hiervan bepaalde eisen stelt.
    Bijvoorbeeld een check om te zien of dit een positief geheel getal is, ten minste gelijk aan het cijfer 1 zodat je in ieder geval een zekere garantie hebt dat het een geldig auto-increment id bevat.

    $_GET['id'] is vervolgens ook uitvoer als je:
    - deze weergeeft op je scherm (HTML-context)
    - deze vervolgens (na validatie) verwerkt in een query (SQL-context)

    Indien je deze DATA dus weer als uitvoer ergens in verwerkt dien je deze uitvoer onschadelijk te maken. Altijd en overal. Tenzij je hier een gedocumenteerde reden voor hebt om dit niet te doen.

  • AarClay
    Gevorderd
    Berichten
    424
    • 31 januari 2019 om 01:04
    • #28

    Maar input van buitenaf in een query dien je ook te escapen. En dat zeg je weer niet in je voorbeeld. Maar verder is het duidelijk hoor.

  • FangorN
    Professional
    Artikelen
    2
    Berichten
    737
    • 31 januari 2019 om 01:23
    • #29

    Het heet dan alleen geen input. Je output DATA in de SQL-context. Dit is vervolgens weer input voor je database :). Het hangt er maar vanaf vanuit welk perspectief je kijkt.

    Als je iets vanuit A doorgeeft aan B dan is dat vanuit A gezien output en vanuit B gezien input. Je kunt niet in beide gevallen spreken van "input". Alleen uit optiek van B is dit input.

    Het escapen van input zou zoiets zijn als htmlspecialchars() heengooien over data die de database ingaat. Maar dat streeft het doel voorbij en heeft zijn eigen problematiek. In heel veel gevallen is het op voorhand escapen van input (en dat zal dus altijd voor een of meer specifieke contexten zijn) niet handig. Het escapen doe je doorgaans pas... als (dus net voordat) je het gebruikt in een specifieke context. Hier zijn trouwens wel uitzonderingen op, maar dat is echt maar een handjevol.

    Ten einde allerlei spraakverwarring te voorkomen en het wijdverbreide devies is het dus nog steeds "filter input, escape output" en dus niet "escape input". Als jij het iets anders wilt noemen (filter banaan, escape pindakaas) mij ook best.

Registratie

Nog geen account? Registreer je nu en word deel van onze community!

Nu registreren Aanmelden

ICT Nieuws

  • PHP waarschuwt voor twee ernstige bugs die makkelijk uit te buiten lijken

    Aaron 22 oktober 2026 om 22:19

Blogs

  • Functioneel ontwerp

    Dees 28 december 2014 om 12:38
  • Access Control List implementatie in PHP/MySQL - deel 1/2

    FangorN 28 december 2018 om 12:35
  • Access Control List implementatie in PHP/MySQL - deel 2/2

    FangorN 29 december 2018 om 12:37

Gebruikers die dit topic bekijken

  • 1 Gasten
  1. Marktplaats
  2. Design
  3. Voorwaarden
  4. Ons team
  5. Leden
  6. Geschiedenis
  7. Regels
  8. Links
  9. Privacyverklaring
  10. Contact
ICTscripters ©2005 - 2026 , goedkope hosting door DiMoWeb.com, BE0558.915.582
Sponsors: Beste kattenhotel provincie Antwerpen
Style: Nexus by cls-design
Stylename
Nexus
Manufacturer
cls-design
Licence
Commercial styles
Help
Supportforum
Visit cls-design