Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

Webprogrammeren & scripting

[php] htmlspecialchars en magic quotes

Anoniem
None
17 antwoorden
  • Beste,

    Er is de laatste tijd veel te doen over de beveiliging van je website.

    Ik heb er veel over gelezen (en eerder (2004) een topic over geopend) maar veel mensen hebben een andere mening.

    Nu is mijn vraag of htmlspecialchars voldoende is om een textinput van een formulier te reinigen van kwaadwillende code. bv:

    $var_naam = htmlspecialchars($_POST['var_naam']);

    Daarmee zet ik alle html en JS toch buiten spel? Als ik de uitkomst van bovenstaande in een database zet kan me toch niet veel meer gebeuren?

    Dit is uiteraard zonder de controle of bv een emailadres wel een emailadres is maar het gaat me om kwaadwillende code.

    2e vraag is: alles wat via de $_POST komt, wordt automatisch door addslashes gehaald, klopt het dat ik dan alles met stripslashes moet weergeven? Er staat me een artikel bij van iemand die afraadt om stripslashes te gebruiken. Ik weet echter niet meer wie en waar dat was en waarom.

    Graag jullie ervaring over het "reinigen" van formulieren input. Ik wil graag voorkomen dat mensen gekke dingen invoeren die mijn script om zeep helpen.
  • [quote:8acb4ffed0="sander16v"]Beste,

    Er is de laatste tijd veel te doen over de beveiliging van je website.

    Ik heb er veel over gelezen (en eerder (2004) een topic over geopend) maar veel mensen hebben een andere mening.

    Nu is mijn vraag of htmlspecialchars voldoende is om een textinput van een formulier te reinigen van kwaadwillende code. bv:

    $var_naam = htmlspecialchars($_POST['var_naam']);

    Daarmee zet ik alle html en JS toch buiten spel? Als ik de uitkomst van bovenstaande in een database zet kan me toch niet veel meer gebeuren?

    Dit is uiteraard zonder de controle of bv een emailadres wel een emailadres is maar het gaat me om kwaadwillende code.

    2e vraag is: alles wat via de $_POST komt, wordt automatisch door addslashes gehaald, klopt het dat ik dan alles met stripslashes moet weergeven? Er staat me een artikel bij van iemand die afraadt om stripslashes te gebruiken. Ik weet echter niet meer wie en waar dat was en waarom.

    Graag jullie ervaring over het "reinigen" van formulieren input. Ik wil graag voorkomen dat mensen gekke dingen invoeren die mijn script om zeep helpen.[/quote:8acb4ffed0]

    Ik gebruik altijd het volgende om form input te "reinigen":

    $var_naam = trim(stripslashes(htmlspecialchars($_POST['var_naam'],ENT_QUOTES)));
  • Bedankt voor je antwoord, kan je misschien ook zeggen waarom?

    je haalt de slashes meteen weg maar dan kan je in de knoei komen als je iets doet met die input?

    wat doet die ENT_quotes?? zoeken op quotes brengt me overal maar niet waar ik zijn wil.
  • [quote:6daa6aa25b="sander16v"]Bedankt voor je antwoord, kan je misschien ook zeggen waarom?

    je haalt de slashes meteen weg maar dan kan je in de knoei komen als je iets doet met die input?

    wat doet die ENT_quotes?? zoeken op quotes brengt me overal maar niet waar ik zijn wil.[/quote:6daa6aa25b]

    Met trim haal je de witte spaties aan het begin en einde van de variabel weg, met stripslashes haal je alle "" weg en met htmlspecialchars converteer je de karakters &, ", ', < en > die voor problemen kunnen zorgen in de code.

    ENT_QUOTES zorgt ervoor dat " en ' geconverteerd worden.
  • klopt het dus dat wanneer je ENT_QUOTES gebruikt het hele addslash en stripslash verhaal niet meer nodig is?

    een ' hoeft niet meer ge-escaped te worden?
  • [quote:945b23f99e="sander16v"]klopt het dus dat wanneer je ENT_QUOTES gebruikt het hele addslash en stripslash verhaal niet meer nodig is?

    een ' hoeft niet meer ge-escaped te worden?[/quote:945b23f99e]

    Volgens mij klopt dit niet. Als de input bijv " O'Reilly " is, dan is $_POST['var_naam'] = " O'Reilly ".

    Na htmlspecialchars met ENT_QUOTES geldt $_POST['var_naam'] = " O\&-#039;Reilly ".

    Na stripslashes geldt $_POST['var_naam'] = " O&-#039;Reilly ".

    En na trim geldt $_POST['var_naam'] = "O&-#039;Reilly".
  • Dus jij steekt O&-#039;Reilly in de database en niet O'Reilly ?

    zie ik het zo goed?

    Op deze manier kunnen lieden geen Javascript, php of HTML meer neerzetten toch?
  • [quote:b407aa7ecc="sander16v"]Dus jij steekt O&-#039;Reilly in de database en niet O'Reilly ?

    zie ik het zo goed?

    Op deze manier kunnen lieden geen Javascript, php of HTML meer neerzetten toch?[/quote:b407aa7ecc]

    Zo doe ik dat. Ik steek O&-#039;Reilly in de database, maar als je het in een webbrowser uitprint, zie je O'Reilly.
  • [quote:e9c4023684="DeNasio"]
    Zo doe ik dat. Ik steek O&-#039;Reilly in de database, maar als je het in een webbrowser uitprint, zie je O'Reilly.[/quote:e9c4023684]
    Deze oplossing heeft een aantal nadelen:
    1. Voor elke quote heb je 7 (!) karakters nodig in de database. Bijv: als je veldlengte 10 chars lang is, dan zou je daar niet O'Reilly kunnen invoeren.
    2. Je stopt niet alleen de data in de database, maar bewerkt deze eerst naar html. Zo maak je de data ongeschikt voor andere toepassingen.

    Voor het 'onschadelijk' maken van input van een gebruiker moet je kijken wat je met de data gaat doen. Voor invoer in de database is het alleen noodzakelijk dat de quotes worden ge-escaped. Bij tonen op een pagina vervang je schadelijke tekens in de data die uit de database worden gehaald. Wanneer je input gebruikt voor het versturen van een mail, dan moet je weer controleren op Mail-header injection. Zo heeft elke toepassing van de data weer z'n eigen regels.
  • De genoemde velden worden puur gebruikt als naam en beschrijving van een object.

    Op dit moment wordt het dus alleen maar weergegeven. De admin kan deze gegevens wel via een formulier wijzigen dus O/'Reilly in de database komt me beter uit.

    htmlspecialchars icm stripslashes bij het weergeven is dus toch de beste manier?
  • [quote:50716c74d1="sander16v"]htmlspecialchars icm stripslashes bij het weergeven is dus toch de beste manier?[/quote:50716c74d1]
    stripslashes zou niet nodig moeten zijn. Als je op de juiste wijze escaped, dan staat er alleen een quote in de database zonder slashes.
  • wat is de juiste methode dan?

    magic-quotes staat aan. dan wordt 's avonds automatisch /'s avonds.

    magic Q kan ik uitzetten maar dan breekt hij een opdracht (bv mysql) af bij de '.
  • leesvoer: http://www.webmasterstop.com/63.html

    korte samenvatting: magic quotes uitzetten
  • Ah dat is het stuk wat ik bedoelde met "absoluut geen stripslashes gebruiken".

    [quote:276db15adb]
    Note that MySQL won't store the backslash escape character in the database - it discards it. [/quote:276db15adb]

    Dit zegt al iets over het feit dat ik hem niet meer hoef te stripslashen bij weergave..

    Tijdens het verder lezen raak ik wel in de war door schrijffouten (of hun manier van stripslashen):

    [quote:276db15adb]
    magic_quotes once seemed like a good idea but have turned out to be a menace, because if you take code where someone is using addslashes() and run it on a server where magic_quotes_gpc is on, this is what will be inserted into the database;

    This is Bob's first post! - we wanted just This is Bob's first post!
    [/quote:276db15adb]

    Zij [i:276db15adb]kunnen[/i:276db15adb] het niet eens fout doen haha..

    ik lees verder iig bedankt!
  • [quote:b7a2e66d57="Annie"]
    stripslashes zou niet nodig moeten zijn. Als je op de juiste wijze escaped, dan staat er alleen een quote in de database zonder slashes.[/quote:b7a2e66d57]

    Inderdaad, je hebt gelijk. 1 x addslashes OF magicQuotes en dan de database in. de \ wordt niet opgeslagen.

    Ik gebruik de genoemde functie wel voortaan.

    Dan terug naar mijn eerste vraag: voor mijn genoemde doel is:

    trim(htmlspecialchars($var_naam)) genoeg?

    Kan ik op deze manier niet door javascript/php/html genekt worden?
  • Als het je er alleen om gaat dat het veilig in de database komt, kom je een heel eind met mysql_escape_string.
    Als je bij het echo'en ervoor wilt zorgen dat er geen HTML-code in de output komt, is htmlspecialchars() in principe genoeg, omdat hiermee < en > worden omgezet in hun HTML-entities. Zo wordt geen enkele HTML-tag meer geparsed, dus ook geen scripts.
  • Deze functie lijkt weer op addslashes. Of lees ik weer te snel ?

    Ik zie het verschil niet zo snel en van die discussie over encode64 wordt ik ook niet wijzer daar… ik ga maar weer even googlen 8)

    waar is de tijd gebleven dat je gewoon een paar basisfuncties had? ik ben halverwege het programmeren van een site en ik kom steeds meer nieuwe dingen tegen… :cry:

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.