Template - Sicherheit

[-Mindfreak-]

HI,

ich schreibe ein Skript, bei dem die Nutzer das Aussehen selbst bestimmen können.
Dazu benutze ich eine einfache Template-Routine, die Templates werden auf dem Server gespeichert.

  
$template = file_get_contents("templates/header.html");  
[...] // Hier Platzhalter ersetzen  
echo $template;  

Meine Frage ist: Wie sicher ist das? Ich will natürlich nicht, dass in das Template z.B. ein get_defined_vars() eingeschmugelt wird.

Ich habe bereits probiert, dass ein einfaches

  
<?php  
print_r(get_defined_vars());  
?>  

im Template nicht funktioniert. Aber gibt es eine andere Möglichkeit, PHP-Code im Template ausführen zu lassen?

Gruß

[dedlfix]

echo $begrüßung;

$template = file_get_contents("templates/header.html");

[...] // Hier Platzhalter ersetzen
echo $template;

>   
> Meine Frage ist: Wie sicher ist das? Ich will natürlich nicht, dass in das Template z.B. ein get\_defined\_vars() eingeschmugelt wird.  
  
Bei einem echo wird kein PHP-Code ausgeführt. Auch liefert file\_get\_contents() einen Dateiinhalt, ohne ihn zu interpretieren.  
  

> Ich habe bereits probiert, dass ein einfaches  
> ~~~php

<?php  

> print_r(get_defined_vars());?>

im Template nicht funktioniert. Aber gibt es eine andere Möglichkeit, PHP-Code im Template ausführen zu lassen?

Wenn du die Datei auf dem üblichen Wege über include und Konsorten einbindest, wird auch darin enthaltener PHP-Code ausgeführt.

Wenn du dir schon Gedanken über das Einschleusen unerwünschten PHP-Codes machst, musst du sie dir konsequenterweise auch über clientseitigen Code machen, denn der kann so auch unabhängig vom PHP-Code wirken.

echo "$verabschiedung $name";

[-Mindfreak-]

Hi,

also Javascript wollte ich auch nicht zulassen.

Gibts da eine bessere Methode, als "javascript" (z.B. in type="text/javascript") durch "java script" zu ersetzen? ;)

Gruß

[dedlfix]

echo $begrüßung;

also Javascript wollte ich auch nicht zulassen.
Gibts da eine bessere Methode, als "javascript" (z.B. in type="text/javascript") durch "java script" zu ersetzen? ;)

Das reicht nicht, weil Javascript auch in Eventhandlern (onxxx=...) vorkommen kann und auch mittels IFrames fremde Inhalte eingebettet werden können. Mit kontextgerechter Maskierung bekommst du alle interpretierbaren Zeichen entschärft. Dumm ist das nur, wenn du bestimmte Sachen doch wieder zulassen möchtest. Beispielsweise: Es soll (fast) alles HTML eingegeben werden können aber keine clientseitigen Scriptsprachen-Elemente. Da musst du dann schon etwas mehr Aufwand treiben, um die unerwünschten Elemente einerseits erstmal alle lückenlos zu benennen und sie dann programmatisch zu berücksichtigen.

echo "$verabschiedung $name";

[-Mindfreak-]

Hi,

und wie mach ich das am Besten?
Muss ich jeden Event einzeln mit einer RegEx rausfiltern?

Gruß

[Harlequin]

Yerf!

und wie mach ich das am Besten?
Muss ich jeden Event einzeln mit einer RegEx rausfiltern?

Man könnte sich zunutzen machen, dass alle Events mit on beginnen.

Allerdings würde ich auch die <script>-Blöcke komplett entfernen und mich nicht darauf verlassen, dass ein zerstückeltes type-Attribut die Ausführung verhindert (die Fehlerkorrektur der Browser wird da anderer Meinung sein).

Gruß,

Harlequin

[dedlfix]

echo $begrüßung;

und wie mach ich das am Besten?

Das kann ich dir nicht sagen, weil ich von deinem Vorhaben nur einen ganz kleinen Ausschnitt kenne.

Muss ich jeden Event einzeln mit einer RegEx rausfiltern?

Das kann ein Teil der Lösung sein. Inwieweit er zu deinen Daten passt, ...

echo "$verabschiedung $name";

[EisFuX]

(Hallo|Hi(ho)|Tag) -Mindfreak-,

und wie mach ich das am Besten?
Muss ich jeden Event einzeln mit einer RegEx rausfiltern?

Nicht einzeln, '/on[a-zA-Z]+/' eingepackt in die Erkennungsroutine|den Erkenungs-RegEx für Attribute und ihre Werte dürfte genügen.

... aber was ist mit sowas?

  
...  
<a href="javascript:alert('Very Bad!')">bla</a>  
...  

... oder gar sowas?

  
...  
<p style="background-image:url('javascript:alert(document.URL)')">Irgendein Text</p>  
...  

http://forum.de.selfhtml.org/archiv/2006/11/t141240/#m917699

MffG
EisFuX