• Login
  • Register
  • Zoek
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Filebase Entry
  • More Options

ICTscripters

Dé plek voor IT

Dé plek voor IT

Login

Geavanceerde opties
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
  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
  9. Goedkope domeinnamen
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
  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
  9. Goedkope domeinnamen
  1. Home
  2. Forum
    1. Alle berichten
    2. Recente activiteiten
  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
  9. Goedkope domeinnamen
  1. Dé plek voor IT - ICTscripters
  2. Forum
  3. Marktplaats
  4. Vraag & Aanbod Werk

Forum

  • Beta-testers gezocht voor Crypto-oefenplatform

    Syntax 29 januari 2026 om 16:11
  • Na 15 jaar terug van weggeweest: iCriminals.nl is terug (BETA)!

    Syntax 19 januari 2026 om 09:34
  • Developer Gezocht

    Mikevdk 10 januari 2026 om 18:57
  • Op zoek naar de legends

    Syntax 5 januari 2026 om 13:50
  • [FREE] WeFact Hosting module

    Jeroen.G 13 oktober 2025 om 14:09
  • Help testers nodig voor android app Urgent

    urgentotservices 26 september 2025 om 10:21
  • Versio vervanger

    Jeroen.G 25 augustus 2025 om 15:56
  • Afspraken systeem met planbeperking

    Lijno 1 augustus 2025 om 23:04

Marktplaats

  • 321 Nieuwe Domeinnamen December 2025

    shiga 1 januari 2026 om 10:26
  • Meerdere mafia game template te koop

    Syntax 26 december 2025 om 00:07
  • Van een pixelige afbeelding naar een strakke, moderne website

    Syntax 21 december 2025 om 17:05

Scripter aangeboden

  • dmeigenaar
  • 23 januari 2019 om 19:51
  • FangorN
    Professional
    Ontvangen Reacties
    196
    Articles
    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.

  • Guest, wil je besparen op je domeinnamen? (ad)
  • AarClay
    Intermediate
    Ontvangen Reacties
    34
    Berichten
    423
    • 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
    Ontvangen Reacties
    196
    Articles
    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
    Intermediate
    Ontvangen Reacties
    34
    Berichten
    423
    • 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
    Ontvangen Reacties
    196
    Articles
    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
    Intermediate
    Ontvangen Reacties
    34
    Berichten
    423
    • 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
    Ontvangen Reacties
    196
    Articles
    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
    Intermediate
    Ontvangen Reacties
    34
    Berichten
    423
    • 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
    Ontvangen Reacties
    196
    Articles
    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.

Participate now!

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

Maak een account aan Login

ICT Nieuws

  • Fijne feestdagen

    tcbhome 28 december 2025 om 13:55
  • Kritieke update voor Really Simple Security-plug-in

    K.Rens 16 november 2024 om 16:12
  • ING Nederland streeft naar ondersteuning van Google Pay tegen eind februari

    K.Rens 2 november 2024 om 16:09

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

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