Hintergrund Bild aus Node field in page.tpl Sicherheits Risiko?
Eingetragen von patrici (107)am 13.12.2014 - 21:05 Uhr in
Hallo,
Ich versuche derzeit einen DIV mit einen Hintergrundbild zu bestücken. Dazu habe ich folgendes in der page.tpl datei eingefügt:
<?php if ($page['bannerimg']): ?>
<?php $banner = token_replace('[node:field-fan-art-url]', array('node' => $node)); ?>
<div id="banner" style="background-image: url("<?php print $banner; ?>");">
<?php endif; ?>
<div class="wrap clearfix">
<?php if ($page['slider']): ?>
<div id="slider">
<?php print render($page['slider']); ?>
</div> <!-- /#slider -->
<?php endif; ?>
<?php if ($page['headlines']): ?>
<div id="headlines">
<?php print render($page['headlines']); ?>
</div> <!-- /#headlines -->
<?php endif; ?>
</div></div><!-- /#spotlight -->
<?php endif; ?>
<?php if ($page['bannerimg']): ?>
</div>
<?php endif; ?>field-fan-art-url ist eine externe URL die auch von Nutzern geändert werden kann.
Mal davon abgesehen das der Code so nicht funktioniert weil token_replace die / entfernt frage ich mich ob das ganze so überhaupt sicher sein kann?
Falls es nicht sicher ist habt ihr Vorschläge wie ich es sonnst lösen könnte?
- Anmelden oder Registrieren um Kommentare zu schreiben
Das Konstrukt ist rechtlich zweifelhaft
am 14.12.2014 - 13:55 Uhr
Du trägst die Verantwortung für die Darstellungen auf deiner Website, verlinkst aber auf Bilder, die außerhalb deines Einflußbereichs sind.
Ich gehe mal davon aus, dass dies wirklich nur Bilder sind, deren Einfügung du erlaubst.
Lässt du zu, dass diese Bilder mit einem Klickziel verbunden werden können, wird es nochmals schwieriger, dann du dann die Kontrolle endgültig verlierst.
Zitat:Lässt du zu, dass
am 14.12.2014 - 14:50 Uhr
Lässt du zu, dass diese Bilder mit einem Klickziel verbunden werden können, wird es nochmals schwieriger, dann du dann die Kontrolle endgültig verlierst.
Den Satz verstehe ich nicht. Was meinst du mit Klickziel? Meine Frage hat sich hauptsächlich auf sql injections oder Ähnliches bezogen.
Hi, statt token_replace würde
am 14.12.2014 - 22:08 Uhr
Hi, statt token_replace würde ich das mit field_get_items() lösen.
PS; Was Roland meint ist dass es irgendwie gefährlich ist Banner mit einem Hintegrund zu produziern von dem Du nicht weisst ob die Links korrekt sidn und später auch noch existieren.
Roter Teppich für "Cross Site Scripting"
am 14.12.2014 - 22:17 Uhr
Daß hier mal ein Link nicht funktioniert wäre meine geringste Sorge. Benutzer-Eingaben sollte man niemals ungefiltert ins HTML schreiben. Da sollte wenigstens ein XSS-Filter zwischen:
https://api.drupal.org/api/drupal/includes%21common.inc/function/filter_...
Kann Carsten nur
am 15.12.2014 - 11:31 Uhr
Kann Carsten nur zustimmen...allerdings übernimmt token_replace das laut der Funktionsbeschreibung, wenn es nicht "ausgeschaltet" wird: https://api.drupal.org/api/drupal/includes!token.inc/function/token_replace/7
Außerdem sollten solche Prozesse nie in einer Template-Datei gemacht werden.... maximal in der template.php, besser aber in einem eigenen Modul
Danke für eure Antworten.
am 15.12.2014 - 11:48 Uhr
Danke für eure Antworten.
Ich hab das jetzt so gelöst das mittels des Moduls Field validate überprüfe ob das Feld eine Url ist.
Ich denke das reicht vorerst aus?
Was genau spricht denn dagegen es in einer Template Datei zu machen?
Und wie ist es möglich so etwas über ein modul zu lösen?
Templates sind dazu da,
am 15.12.2014 - 17:38 Uhr
Templates sind dazu da, vorher bereits aus der Datenbank abgefragte und bearbeitete Daten darzustellen. Wenn man das in den Modulen macht, das fertige Ergebnis ans Template ausliefert und dann im Template munter weitere Daten hinzugefügt, wird es schnell sehr unübersichtlich, woher jetzt welche Daten kommen.
Templates sind NUR für die DARSTELLUNG der fertig gelieferten Daten da. Braucht man zusätzliche Daten, kann man das in kleinem Rahmen noch in Preprocess-Funktionen in der template.php erledigen... aber du willst ja sicher nicht, dass der Banner bei einem Template-Wechsel nicht mehr funktioniert, sondern dann auch in dem neuen Template eingebunden werden kann. Noch ein Grund, das in einem Modul zu erledigen.
Also spricht performance und
am 16.12.2014 - 11:34 Uhr
Also spricht performance und sicherheitstechnisch nix dagegen? Ich würde es am liebsten in der page.tpl lassen.