[PHP/HTML] </textarea> in een textarea?

[TygeR]

Hallo, ik heb een simpele editor gemaakt die uit een database waardes laad en die in een textarea zet:

Pseudo code:

code:

$text = $database->getfield(text,1);
echo "<textarea>$text</textarea>";

De text die uit de database geladen wordt is in sommige gevallen HTML, nu kan het voorkomen dat de tag </textarea> zich in deze text bevind. Dit resulteert bijv: in de volgende HTML code:

<textarea> beschrijving <textarea> vul hier uw bescrijving in. </textarea> <input type=submit> </textarea>

Je voelt hem al aankomen, niet alle inhoud van de $text variabele is meer te zien in het textarea omdat dit wordt afgesloten na de eerste </textarea> tag, resulterend in een fout op de pagina.

Graag wil ik wel </textarea> in het veld weergeven, heeft er iemand iedeën om dit toch vanuit php voor elkaar te krijgen (javascript textarea.value = $text, mogelijk ken ik en werkt goed, maar ik wil in deze fase voor deze module liever nog geen javascript gebruiken).

Wie heeft er ideeën om dit op te lossen?

[Verwijderd]

Kijk hier maar eens: http://nl.php.net/htmlentities

[Verwijderd]

Je moet daar sowieso alle tekens met betekenis in HTML escapen. Je hoort überhaupt alle variablen in de output te escapen tenzij er HTML in mag staan of ze geen HTML kúnnen bevatten.
Dat betekent dat je voor waarden van formulierelementen altijd al een escape functie zoals htmlentities moet gebruiken.

[ Voor 3% gewijzigd door Verwijderd op 01-08-2008 20:04 ]

[TygeR]

Bedankt voor de snelle reactie! htmlentities(); verhelpt het probleem!

[Verwijderd]

TygeR schreef op vrijdag 01 augustus 2008 @ 20:08:
Bedankt voor de snelle reactie! htmlentities(); verhelpt het probleem!

Hopelijk zie je ook in dat je deze functie al 60.000 keer vaker had moeten gebruiken

[Johnny]

Je kan trouwens beter htmlspecialchars() gebruiken zodat je geen risico loopt dat je content vervuild raakt met allerlei HTML-entities. Als je UTF-8 als encoding gebruikt kan je alle karakters overal gewoon gebruiken zonder dat je entities nodig hebt.

[Verwijderd]

Johnny schreef op vrijdag 01 augustus 2008 @ 20:15:
Je kan trouwens beter htmlspecialchars() gebruiken zodat je geen risico loopt dat je content vervuild raakt met allerlei HTML-entities.

Welke content zou volgens jou vervuild moeten raken?

Als UTF-8 geëncode HTML is nog steeds gewoon HTML. En waarom zou de user agent de entities meegeven bij het posten van een formulier? Feitelijk maakt het in dit geval niets uit wat je gebruikt. Het resultaat hoort altijd hetzelfde te zijn.

Je moet escapen zodat de waarden niet als HTML geïnterpreteerd worden. Zodra het document is geïnterpreteerd, kunnen de entities makkelijk helemaal verdwenen zijn. In het Document Object Model c.q. het geheugen van de browser, kunnen de entities prima zijn vervangen door de karakters waar ze voor stonden. Dat mag gewoon. Sterker nog, bij het verwerken van het document hoort het eigenlijk geen enkel verschil te maken. Het document kan in tussentijd genormaliseerd zijn.

[ Voor 54% gewijzigd door Verwijderd op 01-08-2008 20:31 ]

[Johnny]

Verwijderd schreef op vrijdag 01 augustus 2008 @ 20:21:
[...]

Welke content zou volgens jou vervuild moeten raken?

Zodra je de content naar een ander formaat dan HTML wilt omzetten, of gebruikers zelf vage dingen gaan doen met ampersands en puntkomma's. Vooral als ze teksten vanuit andere bronnen gaan kopiëren Zoals wanneer je hier op GoT &euro; wilt laten zien je &amp;euro; moet typen. Ook als je bijvoorbeeld de content wilt indexeren in de database zal deze vaak entities niet herkenen en dus een "café" niet kunnen matchen met een zoekopdracht voor "cafe" omdat het in de database staat als "caf&eacute;", en ook voor andere vergelijkingen in programma-code kunnen twee strings die hetzelfde worden weergegeven een compleet andere inhoud en lengte hebben.

Je moet escapen zodat de waarden niet als HTML geïnterpreteerd worden. Zodra het document is geïnterpreteerd, kunnen de entities makkelijk helemaal verdwenen zijn. In het Document Object Model c.q. het geheugen van de browser, kunnen de entities prima zijn vervangen door de karakters waar ze voor stonden. Dat mag gewoon. Sterker nog, bij het verwerken van het document hoort het eigenlijk geen enkel verschil te maken. Het document kan in tussentijd genormaliseerd zijn.

Er is dus geen enkele reden om gebruik te maken van entities, het is een oplossing voor een encoding probleem wat inmiddels niet meer bestaat.

[ Voor 5% gewijzigd door Johnny op 01-08-2008 21:27 ]

[Verwijderd]

€
[edit] Mijn toetsenbord bevat dit teken. Daarom zo eenvoudig. Maar aanvullend:

mysql_real_escape_string gebruik ik voor iedere data die in de database moet.
stripslashes om de informatie op te halen.
nl2br en (htmlspecialchars OF htmlentities) voor de weergave van de (tekst) informatie.

Ik hoop dat dit naar wens is volgens medetweakers. Anders opper ik dit als antwoord

Voor Johnny, gebruik die entities maar, voor je site-injections hebt zoals bij gratis profiel/webspace aanbieders vast wel eens gebeurd is.

[edit2]Tekentje nodig?

[ Voor 118% gewijzigd door Verwijderd op 01-08-2008 21:45 ]

[Nvidiot]

Johnny schreef op vrijdag 01 augustus 2008 @ 21:25:
*knip*

Er is dus geen enkele reden om gebruik te maken van entities, het is een oplossing voor een encoding probleem wat inmiddels niet meer bestaat.

htmlentities moet gebruikt worden op elke plek waar je niet-controleerbare input (van een gebruiker, van een RSS-feed, etc) terug stuurt naar de browser. Doe je dit niet loop je zeer veel kans op XSS, wat gevaarlijker is dan dat veel mensen in eerste instantie denken.

Dit soort XSS problemen komt op *zeer* veel websites voor, zeker niet alleen de kleine hobby-bob sites, maar ook grote sites als Myspace, twitter, etc.

[Johnny]

Ik kan me geen voorbeeld bedenken waarbij htmlspecialchars een beveiligingslek opent dat htmlentities zou voorkomen. Als je een voorbeeld daar van kan geven dan hoor ik het graag.

[Verwijderd]

Johnny schreef op vrijdag 01 augustus 2008 @ 21:25:
[...]

Er is dus geen enkele reden om gebruik te maken van entities, het is een oplossing voor een encoding probleem wat inmiddels niet meer bestaat.

Daar reageer ik op, het is belangrijk het wel te doen, maar kies zelf maar welke. Er zit volgens mij niet wezenlijk veel verschil in.

[Nvidiot]

Johnny schreef op vrijdag 01 augustus 2008 @ 21:52:
Ik kan me geen voorbeeld bedenken waarbij htmlspecialchars een beveiligingslek opent dat htmlentities zou voorkomen. Als je een voorbeeld daar van kan geven dan hoor ik het graag.

http://ha.ckers.org/blog/...ecialchars-strikes-again/
http://shiflett.org/blog/2005/dec/google-xss-example
http://sla.ckers.org/forum/read.php?2,28

[ Voor 11% gewijzigd door Nvidiot op 01-08-2008 22:04 . Reden: 2 links toegevoegd ]

[Verwijderd]

Johnny schreef op vrijdag 01 augustus 2008 @ 21:25:

Zodra je de content naar een ander formaat dan HTML wilt omzetten, of gebruikers zelf vage dingen gaan doen met ampersands en puntkomma's.

Geef eens een codevoorbeeld van een formulier dat wordt gesubmit en waarbij de waarden verkeerd worden opgestuurd door de user agent. Overigens kun je dat direct als bug inschieten in de tracker van desbetreffende user agent.

Vooral als ze teksten vanuit andere bronnen gaan kopiëren Zoals wanneer je hier op GoT &euro; wilt laten zien je &amp;euro; moet typen.

Dat is GoT. Een "feature" van React waarschijnlijk. Dat React rare dingen doet met input zal mij verder een zorg zijn, het gaat normaal gewoon goed.

Ook als je bijvoorbeeld de content wilt indexeren in de database zal deze vaak entities niet herkenen en dus een "café" niet kunnen matchen met een zoekopdracht voor "cafe" omdat het in de database staat als "caf&eacute;", en ook voor andere vergelijkingen in programma-code kunnen twee strings die hetzelfde worden weergegeven een compleet andere inhoud en lengte hebben.

Dit komt nooit door het escapen van niet-printable ASCII karakters in een HTML formulier.

Je bedenkt dingen die er niet zijn. Dat is net zoiets als het befaamde stripslashes halen over alles wat uit de database komt, omdat je het er met addslashes in hebt gestopt. Dat getuigt gewoon van verkeerd inzicht omtrend het principe van escapen.

Er is dus geen enkele reden om gebruik te maken van entities, het is een oplossing voor een encoding probleem wat inmiddels niet meer bestaat.

Er is geen enkele reden om htmlspecialchars te gebruiken of aan te raden in plaats van htmlentities. Ze doen beiden gewoon wat nodig is. De htmlentities functie geeft vervolgens ook de garantie dat alle karakters "ASCII-safe" zijn. Meestal niet zo boeiend, maar kwaad kan het niet.

[Johnny]

Verwijderd schreef op vrijdag 01 augustus 2008 @ 22:03:
[...]

Dat is GoT. Een "feature" van React waarschijnlijk. Dat React rare dingen doet met input zal mij verder een zorg zijn, het gaat normaal gewoon goed.

Behalve in discussies over entities want daar verdwijnen er opeens karakters...

Dit komt nooit door het escapen van niet-printable ASCII karakters in een HTML formulier.

Ik heb het ook over het gebruik van entities in HTML voor alle doeleinden. Entities hebben geen enkel bestaansrecht in een unicode-wereld. De topicstarter is duidelijk een beginner als het gaat om escaping en krijgt als oplossing de functie htmlentities() voorgeschoteld. Voor het probleem in kwestie is het afdoende, maar er kleven wel nadelen aan het gebruik van entities in bepaalde andere situaties.

Je bedenkt dingen die er niet zijn. Dat is net zoiets als het befaamde stripslashes halen over alles wat uit de database komt, omdat je het er met addslashes in hebt gestopt. Dat getuigt gewoon van verkeerd inzicht omtrend het principe van escapen.

[...]

Er is geen enkele reden om htmlspecialchars te gebruiken of aan te raden in plaats van htmlentities. Ze doen beiden gewoon wat nodig is. De htmlentities functie geeft vervolgens ook de garantie dat alle karakters "ASCII-safe" zijn. Meestal niet zo boeiend, maar kwaad kan het niet.

Wat de functie htmlentities() kan technisch geen kwaad, maar in de praktijk wordt het misbruikt als een oplossing die werkt voor mensen die een probleem hebben met encodings en niet weten wat ze aan het doen zijn. In het geval van HTML werkt dat omdat het probleem wordt gemaskeerd, maar uiteindelijk lopen ze weer tegen een ander probleem met encodings aan maar snappen ze er nog minder van omdat het loslaten van functies zoals htmlenties() en utf8_decode() meestal op magische manier hun probleem wist te verhelpen. Getuige hiervan is de enorme hoeveelheid topics die over dit onderwerp worden geopend.