Sicherheit

[Sven Rautenberg]

Moin!

Effektiv benötigst du hier keinen ternären Operator, sondern ein echtes IF: Wenn die Testbedingung für "bösen Inhalt" zutrifft, willst du das Skript mit die() abtöten und stoppen. Hier den ternären Operator zu verwenden verschleiert diese Tatsache.

Im Grunde aber doch auch richtig oder? Es funktioniert ja so, wie es soll.

"Funzt doch" ist kein Argument. Funktionieren kann viel. Programmieren ist aber mehr als nur das Herstellen der gewünschten Funktion. Es geht auch immer darum, dass man später auch wieder versteht, was man da programmiert hat.

Dieses Verständnis wird extrem erleichtert, wenn man für die gleichen Dinge immer die gleichen Strukturen und Muster benutzt. Denn in Mustererkennung ist unser menschliches Auge sehr gut. Was gleich aussieht, ist auch gleich - diesen Vorteil sollte man sich auch beim Betrachten von Programmcode zunutze machen, denn angucken wird man den Code viel häufiger, als man ihn schreiben wird.

Ich habe es jetzt geändert:

$query_request_check = preg_replace('|?.+$|', '', $_SERVER['REQUEST_URI']);

if (  (!preg_match("#http|include|<|>|%3C|%3E|%22|'|ftp|:|script|select|order|distinct|delete|drop|insert|update#i", $_SERVER['REQUEST_URI']))
    AND (strlen($_SERVER['REQUEST_URI']) > 0 && strlen($_SERVER['REQUEST_URI']) < 90) )
  {
    $aufgerufene_url = array_pop (explode( "/", $query_request_check) );
  }
  else
  {
    $aufgerufene_url = '';
    die('was wird das?');
  }

  
Sieht besser aus.  
  

> > Warum nicht sowas: `$sql = "SELECT .... WHERE feld = '".$dat_verbindung->real_escape_string($aufgerufene_url)."' ...";`{:.language-php}  
>   
> Das kannte ich nicht, Danke für den hinweis.  
  
Das ist teilweise nicht deine Schuld, die PHP-Doku zu mysqli ist, wie ich gerade entdeckt habe, nicht in allen Fällen konsistent. Da werden in den OOP-Beispielen unabsichtlich mal prozedurale Aufrufe benutzt, obwohl es auch objektorientiert ginge.  
  

> > Solch ein Array kommt auch direkt aus der Datenbank, wenn du z.B. "`SELECT titel, headline, content FROM tabelle`{:.language-sql}" abfragst und mit $db->fetch\_assoc() abholst.  
>   
> Das habe ich jetzt ein wenig geändert, meinst du sowas in der Art?  
  
Ich habs mal geändert in das, was ich mir vorstelle:  
  
~~~php
  
$seiten_abfrage = "SELECT title_tag as titel_name, description as my_description, meta_tags as my_keywords, body_id as my_body_id, inhalt_ueberschrift as my_headline, inhalt_text as my_content, marginalien as my_marginalien FROM ....";  
// Der Query liefert dir durch die Verwendung von Aliasnamen in fetch_assoc jetzt die "korrekten", direkt verwendbaren Variablennamen, wie sie im Smarty-Template benutzt werden.  
  
$smarty = new Smarty; // Da du zweifelsfrei ohnehin ein Template benötigst, sollte dieses Objekt eigentlich schon direkt zu Beginn des Skripts erzeugt werden, nicht erst so spät.  
  
if ($mySite = $dat_verbindung->query($seiten_abfrage))  
  {  
    if (($siteRow = $mySite->fetch_assoc())!== false) // Da du nur einen einzigen Datensatz abfragst, ist while hier überflüssig. In den Query gehörte stattdessen ans Ende ein "LIMIT 1".  
    {  
       $siteRow['my_content'] = My_bb_Object($siteRow['my_content']); // Inhalt BB-formatieren.  
       $siteRow['my_marginalien'] = My_marginalien_bb_Object($siteRow['my_marginalien']); // dito für Marginalien  
       $smarty->assign($siteRow);  
    }  
    else  
    {  
      // Error 404  
    }  
  }  

Alternativ könntest du auch die Einzelvariablenvariante von assign nutzen:

$smarty->assign("templatevar", $wertvariable);

Damit kannst du, auch nachträglich überschreibend, jeden bereits gesetzten Wert einzeln übergeben. Das ist u.U. besser, als sich erst umständlich ein Array zu konstruieren.

Übrigens siehst du, dass es ziemlich aufwendig und umständlich ist, die gewählten Spaltennamen in deiner Tabelle für die Ausgabe in Smarty alle umzubenennen. Es wäre deutlich schlauer gewesen, entweder die Spaltennamen identisch zu den Templatevariablen zu wählen, oder umgekehrt die Templatevariablen identisch zu den Datenbankspaltennamen zu wählen.

Das ist nämlich wieder so ein Muster: Gleiche Namen bedeuten gleiches - sowohl im Template, als auch in der DB. Es ist viel anstrengender, wenn man im Kopf immer diese Namenswechsel behalten muss. Bei manchen Namen mag das weniger anstrengend sein (z.B. description == my_description), aber es ist auch sehr fehleranfällig, wenn man unabsichtlich das "my_" vergisst oder hinzufügt. Genauso nervig ist aber die Namensverbindung von inhalt_ueberschrift zu my_headline.

- Sven Rautenberg