[JS] Veilig </script> tag doorgeven

[Marientjuh]

Ik zit met het volgende probleem waar Google mij geen antwoord op kan geven (of waar mijn creativiteit in zoek termen formuleren faalt)

Ik moet een waarde doorgeven vanuit PHP aan een dynamisch tekst vak. Dit doe ik door een stukje javascript te genereren met variabelen welke de waarde bevatten. Dan word de pagina geladen en op basis van enkele condities word het veld wel of niet weergegeven, en gevuld met de waarde die aangeleverd is via PHP.

Voorbeeld: (ter illustratie)

PHP:

echo 'var javascript_variable = "'. addslashes($phpvariable) .'";';

Nu kan ik alles in de php variabele stoppen behalve de </script> tag, dan sluit de browser direct het script blok.

Wat moet ik doen om dit te voorkomen?

htmlentities werkt opzich wel maar dan krijg je in het veld letterlijk alle html varianten te zien van de speciale tekens.

[MueR]

Dit past meer in Webdesign, Markup & Clientside Scripting, aangezien het om javascript gaat.

Wat je kan doen is je </script> tag opdelen in 2 delen.

JavaScript:

var foo = '</'+'script>';

[DexterDee]

Op deze manier kan het vrij eenvoudig zonder de string halverwege te hoeven knippen:

PHP:

echo 'var javascript_variable = unescape("'. urlencode($phpvariable) .'");';

[Bosmonster]

Kun je dan niet beter gewoon JSON-notatie schrijven?

[Marientjuh]

@muer
Thanks, verkeerd ingeschat

@dexterdee
Met een kleine aanpassing werkt hij nog beter urlencode word rawurlencode!

Thanks! Het werkt, alle XSS crap word genegeerd.

@bosmonster
Je bedoelt gewoon:

variabele = json_encode($var);

?

[DexterDee]

Bosmonster schreef op dinsdag 16 november 2010 @ 10:53:
Kun je dan niet beter gewoon JSON-notatie schrijven?

Je bedoelt waarschijnlijk JSON escaping (e.g. het escapen van forward slashes).
Dat werkt inderdaad ook en is nog een stukje compacter:

PHP:

echo 'var javascript_variable = ' . json_encode($phpvariable) . ';';

@Marientjuh: let op dat de quotes al gegenereerd worden door json_encode, deze zijn dus weggelaten

[Marientjuh]

De json_encode werkt inderdaad ook erg goed!

/me Marientjuh loves JSON

[crisp]

MueR schreef op dinsdag 16 november 2010 @ 10:41:
Dit past meer in Webdesign, Markup & Clientside Scripting, aangezien het om javascript gaat.

Wat je kan doen is je </script> tag opdelen in 2 delen.

JavaScript:

var foo = '</'+'script>';

Dat kan, netter is om gewoon de forward slash te escapen:

JavaScript:

var foo = '<\/script>';

Je moet sowieso al escapen voor het geval er een single quote voorkomt; ik doe meestal dit in PHP:

PHP:

echo 'var foo = \'' . addcslashes($data, "\0\n\r\t\\'/") . '\';';

[ Voor 18% gewijzigd door crisp op 16-11-2010 11:15 ]

[Bosmonster]

DexterDee schreef op dinsdag 16 november 2010 @ 11:05:
[...]

Je bedoelt waarschijnlijk JSON escaping (e.g. het escapen van forward slashes).
Dat werkt inderdaad ook en is nog een stukje compacter:

PHP:

echo 'var javascript_variable = ' . json_encode($phpvariable) . ';';

@Marientjuh: let op dat de quotes al gegenereerd worden door json_encode, deze zijn dus weggelaten

Ik bedoel gewoon JSON gebruiken en uiteraard bijbehorende escaping. Voordeel is dat je een complete object-notatie tot je beschikking hebt ipv alleen een enkele variabele wegschrijft.

Wel zo handig als je er in de toekomst meer mee wilt doen en ook wel zo handig om die communicatie te standaardiseren in je backend.

[Marientjuh]

@crisp
De json_encode handelt dit nu toch voor je af?

@bosmonster
Klopt, ikzelf gebruik eigenlijk altijd JSON alleen dit zat verstopt in een 3rd party framework... Stom van me dat ik niet aan JSON hebt gedacht

[crisp]

Marientjuh schreef op dinsdag 16 november 2010 @ 11:23:
@crisp
De json_encode handelt dit nu toch voor je af?

Klopt, voor gewone strings doet die hetzelfde als de addcslashes die ik postte. Enige nadeel van de PHP json_ functies is dat ze alleen werken met UTF8-data. Probeer dit maar eens met non-UTF8 (bijvoorbeeld gewoon Latin) data:

PHP:

echo json_encode('blègh');

Dan krijg je mooi 'null' terug...

[Marientjuh]

Bedankt voor de uitleg Crisp, weer wat geleerd. Gelukkig is onze applicatie zo goed als volledig UTF-8

[Bosmonster]

crisp schreef op dinsdag 16 november 2010 @ 11:54:
[...]

Klopt, voor gewone strings doet die hetzelfde als de addcslashes die ik postte. Enige nadeel van de PHP json_ functies is dat ze alleen werken met UTF8-data. Probeer dit maar eens met non-UTF8 (bijvoorbeeld gewoon Latin) data:

PHP:

echo json_encode('blègh');

Dan krijg je mooi 'null' terug...

Dat heeft alleen niks te maken met PHP, maar is de vereiste van de JSON-standaard.

http://www.ietf.org/rfc/rfc4627.txt

3. Encoding

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

[crisp]

Bosmonster schreef op dinsdag 16 november 2010 @ 14:07:
[...]


Dat heeft alleen niks te maken met PHP, maar is de vereiste van de JSON-standaard.

http://www.ietf.org/rfc/rfc4627.txt


[...]

SHALL != MUST, en implementaties mogen wmb lenient zijn daarin (desnoods via een switch); die van php is dat helaas niet...

[Bosmonster]

http://www.ietf.org/rfc/rfc2119.txt

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

Persoonlijk lijkt het me niet echt good practice hiervan af te wijken en zie ik de noodzaak ook niet.

Het idee van JSON is dat het uitwisselbaar is. Afspraken over de encoding lijken me derhalve ook niet meer dan logisch.

[ Voor 39% gewijzigd door Bosmonster op 16-11-2010 14:33 ]

[crisp]

Bosmonster schreef op dinsdag 16 november 2010 @ 14:30:
http://www.ietf.org/rfc/rfc2119.txt


[...]


Persoonlijk lijkt het me niet echt good practice hiervan af te wijken en zie ik de noodzaak ook niet.

Het idee van JSON is dat het uitwisselbaar is. Afspraken over de encoding lijken me derhalve ook niet meer dan logisch.

Mja, behalve als het ingegeven is door puristische motivieven in plaats van pragmatische

[R4gnax]

crisp schreef op dinsdag 16 november 2010 @ 16:23:
[...]

Mja, behalve als het ingegeven is door puristische motivieven in plaats van pragmatische

Tja. Da's toch een beetje een hellend vlak. Dan heb ik zelf toch liever een door puristische motieven goed dichtgetimmerde en goed gestandardiseerde specificatie. Als je gaat tornen aan dit soort zaken kom je voordat je het doorhebt uit bij grootschalige interoperability fiascos zoals Internet Explorer of Office.

[crisp]

R4gnax schreef op dinsdag 16 november 2010 @ 21:23:
[...]

Tja. Da's toch een beetje een hellend vlak. Dan heb ik zelf toch liever een door puristische motieven goed dichtgetimmerde en goed gestandardiseerde specificatie. Als je gaat tornen aan dit soort zaken kom je voordat je het doorhebt uit bij grootschalige interoperability fiascos zoals Internet Explorer of Office.

Da's wel een ander uiterste en dan praat je juist over zaken die niet of niet volledig gespecificeerd zijn. In het geval van JSON is er imo geen zwaarwegende reden om serialisatie van bijvoorbeeld Latin-1 of Latin-9 (zoals in ons geval) niet toe te staan, nu zijn wij genoodzaakt om een eigen JSON-serialiser te gebruiken die geen beperking heeft mbt gebruikte character-encoding...