Community

9dots.de Webdesign Board

 

 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 

 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 


Tutorial: Sicherheit in PHP

 
Neues Thema eröffnen   Neue Antwort erstellen    9dots.de Webdesign Community Foren-Übersicht -> Coding-Tutorials
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
xaan
Mitglied
Mitglied


Angemeldet: 19.04.2005
Beiträge: 370
Wohnort: Bayern
Interessen: C#, C++, PHP, Security

BeitragVerfasst am: 31.08.2005, 23:11    Titel: Tutorial: Sicherheit in PHP Antworten mit Zitat
Da ja das Thema "Tutorial für ein" CMS gerade im vorherigen Thread Diskutiert wurde denke ich mal das es vielleicht nützlich wäre erfahrungen über die Sicherheit in PHP scripten zu erläutern. Falls ich eine falschaussage machen bitte umgehend Korrigieren, ich versuche hier nur MEIN Wissen und Erfahrungen zu erläutern, kann aber nicht garantieren das es auch stimmt.

Ich hoffe jemand kann das gebrauchen. Viel Spass Winken Ach ja meine c Taste ist ein wenig ausgeleihert also bitte nich wundern!

Punkt I Globale Variablen:

Ein Beispiel für eine Globale Variable ist zum Beispiel "index.php?global=wert". Das global wird im PHP Dokument als $global annerkannt.

Dies Funktionier allerdings nur, wenn in der PHP Konfigurations Datei "regeister_globals" auf "on" ist.

Diese Funktion bringt Vorteile bzw. Erleichterungen aber auch Sicherheitslücken mit sich.

Wenn jetzt zum Beispiel:
Code:

<?php
   if ($loggedin == TRUE) {
      
      // geschuetzter bereich
   } else {
      die("nice try");
   }
?>

Als Adminbereich Abfrage verwendet wird, könnte man die URL so: "index.php?loggedin=TRUE" Manipulieren.

Desswegen sollte in der Konfigurationsdatei von PHP "register_globals" auf "off" gesetzt werden, wie es seit PHP 4.0 bereits Standart ist.

Um jetzt Url Variablen trotzdem zu verwenden kann man ganz einfach das array $_GET Benutzen. z.B.
Code:

if (isset($_GET['site'])) { $site = $_GET['site']; } else { $site="home"; }


// UPDTE

Danke Unex, hab noch ein paar wichtige Dinge vergessen.

Zitat:

2.) wenn ihr eine content variable benutzt um die jeweiligen Inhalte zu includen, verwendet für jeden content ein alias, anhand dem ihr dann den Dateinamen zuweist. Postet nicht direkt den Dateinamen als Contentvariable.


In fast jedem PHP Seitenaufbau werden Content-includes verwendet, viele Programmierer machen den fehler, den richtigen Dateinamen anzugeben z.B.:
Code:

include($_GET['page'].".php");

Je nach Konfiguration der php.ini ist es erlaubt auch dateien von anderen Server zu includen, was wirklich verherrend seien kann!
Wenn man jetzt die URL so manipuliert: http://www.boeserhost.de/bösesscript, könnte jeder machen was er willt, zum beispiel alle datien per mail an sich senden wodurch er die z.B. mysql daten ohne Probleme rauskriegen würde!

Ein Beispiel für ein sicheres Content include script:

Code:

if (isset($_GET['content'])) { $content = $_GET['content']; } else { $content = "home"; }


   switch ($content) {
   case "home":
      $content = "home.php";
   break;
   case "news":
      $content = "news.php";
   break;
        }
        include($content);


--------------------

Punkt II Variablen Prüfen:

Wer vielleicht schon erfahrungen in anderen Programmiersprachen gesammelt hat wird vielleicht wissen, dass man in Sprachen wie c, c++ und Java Variablen Deklarieren muss, in PHP ist dies nicht direkt möglich, aber durch einen einfachen start werte bevor die Variable benutzt wird zu umgehen. z.B.

Code:

$row; // hat noch einen null wert kann aber nich über die url manipuliert werden
for ($x=0;$x=10;$x++) {
if ($bedingung)
       $row++;
}


Alle variablen die man erhält von z.B. $_GET, $_POST und $_COOKIE sollten überprüft werden um die sicherheit zu gewähhren.

--------------------

Punk III Sessions richtig verwenden:

Übliherweise werden Sessions anhand der Session ID überüprüft, was ja schön und gut ist aber ein enormes Problem mit sich zieht.
Falls ein Benutzer einer z.B. Community einen anderen nutzer den link einen Threads oder deraritges schickt und seine Session ID dranhängt, hatt der Benutzer vollen zugriff auf den Account von denjenigen, der ihm den link geshickt hat. Desswegen versuhen wir eine Alternative zu den Session ids zu finden.

Es gibt sicherlih mehrere effiziente Alternativen zu der Session ID, aber die von mir verwqendete methode geht so:
Code:

if (falls benutzerdaten stimmen) {
   $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
   $_SESSION['user'] = $uname;
}

hier wird die IP des Benutzers in der Session auf dem server gespeichert.
falls sih jetzt jemand eine Datei die Geshützt sein soll wird geprüft ob die IP des Benutzers mit der der Session übereinstimmt
Code:

   if ((isset($_SESSION['user'])) && ($_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])) {
// geschüttzt
} else {
die("nice try");
}


--------------------

// UPDATE: Punkt IV Mysql daten schützen:

Falls der Server mal einen Fehler hat und die PHP Dteien im Klartext anzeigt, was im ernstfall durchaus vorkommen kann, sollte man die Datei in der die Msql Daten stehen ein verzeichniss unter das öffentliche tun, denn da zeigt der server nichts an!

--------------------

// UPDATE: Punkt V Sich gegen SQL Injections Schützen:

Eine SQL Injection ist, wenn jemand einen string in der URL Manipuliert welcher direkt in einer SQL abfrage verwendet wird z.b. bei "weiter" und "zurück" links (index.php?page=news&site=2)
Ich kann nur empfehlen sich weiter darüber zu informieren, um den ernst der Sache zu verstehen. Winken
http://php3.de/manual/de/security.database.sql-injection.php

Um dies vorzubeugen habe ich eine einfache Funktion geschrieben:
Code:

function strisint ($string)
{

   $isint = "/[^0-9]/";
   if (!preg_match($isint, $string)) {
      return $string;

   } else {
      return "0";
   }
}

Die Funktion überprüft ob der String auch wirklich ein Integer ist und gibt im Positiven falle den String wie er ist aus und im Negativen falle 0.

Das Fazit daraus ist alle Strings aus der URL Übergabe die in SQL Abfragen verwendet werden genauestens überprüfen! Mehr dazu unter der angegebenen URL!



Ich hoffe ich hab mich verständlich ausgedrückt, und die wichtigsten Kriterien angesprochen. Bitte nicht vor fragen oder Kritik scheuen!
Ich hoffe ich konnte helfen!

// EDIT
Wer noch was anfügen möchte nehmt gerne euch an unex ein Beispiel Winken[/b][/code]


Zuletzt bearbeitet von xaan am 01.09.2005, 06:10, insgesamt 5-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen AIM-Name
unex`9dots
Administrator
Administrator


Angemeldet: 02.08.2003
Beiträge: 1106
Wohnort: Karlsruhe
Interessen: Coding, Segeln, Schwimmen, PC

BeitragVerfasst am: 01.09.2005, 04:51    Titel: Antworten mit Zitat
Der Thread gefällt mir! Gute Idee!

Dein Post scheint mir auch sehr solide zu sein und beinhaltet schonmal die wichtigsten Sachen.

Zum Thema Session empfehle ich aber trotzdem die schon bekannten Threads im Board zu lesen, da es ein sehr komplexes Thema ist und die Methode mit der IP auch seine Tücken hat. Alle die hinter einem Proxy sitzen haben die gleiche IP. Dies ist z.B. in Firmen und auch bei manchen Providern der Fall. Ausserdem gibt es auch Provider die ihre IP ständig neu verteilen, bis vor kurzem Zählte, soweit ich mich erinnere, AOL auch dazu, was zur Folge hat das die IP-Überprüfung Fehlerhaft ist.

Da es sich nicht lohnt das Thema hier wirklich zu diskutieren, hier eine Dokumentation die die Problematik sehr ausgiebieg und komplett erörtert. Auch wenn es auch Englisch ist, LEST ES!
http://www.sans.org/rr/whitepapers/webservers/1594.php

Jetzt noch 5 Sachen die mir gerade in den Sinn kommen:

1.) legt in jeden Ordner eurer Seite eine index.html, so könnt ihr vermeiden das jemand in eurem Filesystem rumstöbern kann, insofern directorylisting aktiv ist.

2.) wenn ihr eine content variable benutzt um die jeweiligen Inhalte zu includen, verwendet für jeden content ein alias, anhand dem ihr dann den Dateinamen zuweist. Postet nicht direkt den Dateinamen als Contentvariable.

3.) Wenn ihr eingabefelder habt, denkt daran html zeichen etc. zu escapen, da sonst code ausgeführt werden kann.

4.) Sorgt gegen SQL-Injections vor! Da mir das jetzt aber zu kompliziert ist um es zu erklären poste ich euch mal den entsprechenden link: http://php3.de/manual/de/security.database.sql-injection.php

5.) wenn ihr nicht wollt das jemand in euren Template Dateien schnüffeln kann, dann sperrt einfach die endung der templatedateien (meistens *.tpl o.ä.) per .htaccess[/url]


Zuletzt bearbeitet von unex`9dots am 01.09.2005, 11:36, insgesamt 3-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
xaan
Mitglied
Mitglied


Angemeldet: 19.04.2005
Beiträge: 370
Wohnort: Bayern
Interessen: C#, C++, PHP, Security

BeitragVerfasst am: 01.09.2005, 06:13    Titel: Antworten mit Zitat
uneX`9dots hat folgendes geschrieben:

Zum Thema Session empfehle ich aber trotzdem die schon bekannten Threads im Board zu lesen, da es ein sehr komplexes Thema ist und die Methode mit der IP auch seine Tücken hat. Alle die hinter einem Proxy sitzen haben die gleiche IP. Dies ist z.B. in Firmen und auch bei manchen Providern der Fall. Ausserdem gibt es auch Provider die ihre IP ständig neu verteilen, bis vor kurzem Zählte, soweit ich mich erinnere, AOL auch dazu, was zur Folge hat das die IP-Überprüfung Fehlerhaft ist.


Ich denke hier ist die Gelegenheit dies nochmal zusammenzufassen bzw. nochmal Auszudiskutieren. Winken hab jetzt im moment aber leider keine Zeit mehr dafür, an das mit der IP hab ich ehrlichgesagt ger nicht gedacht, dumm von mir ^^
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen AIM-Name
unex`9dots
Administrator
Administrator


Angemeldet: 02.08.2003
Beiträge: 1106
Wohnort: Karlsruhe
Interessen: Coding, Segeln, Schwimmen, PC

BeitragVerfasst am: 01.09.2005, 11:39    Titel: Antworten mit Zitat
Da es wohl relativ sinnlos die Sache mit den Session und deren Sicherheit einfach so zu diskutieren habe ich meinen ersten Post editiert und ein Dokument angegeben, welches wir als Grundlage für jegliche Diskussionen nehmen sollten, auch wenn es auf Englisch ist. Alles andere macht wohl wenig Sinn.

Sollte jemand das bedürfnis Haben über den ein oder anderen Punkt genauer diskutieren zu wollen, so würde ich euch bitten diesen Thread relativ sauber zu halten und gezielt nachzuhaken. Lange unüberschaubare "1-Satz" Diskussionen nehmen dem Tut seinen Reiz es zu lesen Smilie
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Thomas`tiweb
Mitglied
Mitglied


Angemeldet: 03.08.2004
Beiträge: 115
Wohnort: Bruchsal

BeitragVerfasst am: 02.09.2005, 14:57    Titel: Antworten mit Zitat
Noch ein paar Tipps und Sicherheitsfakten von mir:

1. die oben angebenene Funktion macht dasselbe wie if(is_numeric($var)) {} ... aber is_numeric sollte um einiges schneller sein Winken

2. Viel leichter geht das mit einem typecast: einfach (int) davor und nichts kann mehr in den MySQL-Query dringen (z.b. ids/seiten/etc) - umbedingt trotzdem vorher auf fehler abfragen, aber ein (int) davor ist sehr sicher

3. alle einkommenden $_GET, $_POST oder $_COOKIE Eingaben mit addslashes() sichern (wird normalerweise automatisch gemacht, aber manchmal ist magic_quotes_gpc aus ...)

4a. Wie oben schon steht, globale Variablen vermeiden (register_globals umbedingt ausstellen (das geht auch im script per ini_set('register_globals', '0')Winken) - benutzt stattdessen Konstanten, ist viel einfacher

4b. Man kann jedoch alle Konstanten auflisten (ich mein mit get_defined_constants()), deswegen sollte man Passwoerter o.a. nicht in Konstanten abspeichern oder dies verschluesselt machen

5. Am Anfang jeder Include Datei eine Abfrage machen
Code:

if (!defined('LOADED')) exit();

und bei eurer Start-Datei (oder die Kerndatei, welche ihr immer zuerst includet) einfach define('LOADED', '1');
So koennen keine reinen Include-Dateien (welche evtl. auch noch auf andere Funktionen aufbauen) nicht mehr ausgefuehrt werden.

6. Immer auch die PHP-Notices abfragen, es macht euren Code besser und sicherer (z.b. wenn ihr Variablen abfraegt, welche nicht initialisiert sind) - einfach per error_reporting(E_ALL); einstellen und ihr bekommt jede Notice raus


Tipp1: Je weniger Leute euren Code sehen, desto sicherer ist er. Es gibt verschiedene Verschluesselungssysteme fuer PHP-Dateien (z.b. Ioncube oder Zend) - sind zwar teuer, aber auch sehr effektiv. Sie compilieren euren PHP-Code vor, der Kunde sieht nurnoch Bytemuster -> Der Code wird somit auch schneller, jedoch benoetigt ihr immer einen besonderen Loader, welcher auf dem Server installiert werden muss

Tipp2: Benutzt SSL fuer kritische Operationen - es ist zwar langsamer, aber ALLE HTTP Daten werden unverschluesselt uebertragen (ja, auch Passwoerter, etc ...) - SSL hat aber nichts mit PHP zu tun, ich wollts hier nur mal erwaehnen

Tipp3: Falls ihr via PHP Mails verschickt und auch MassMailer (also z.b. Mailinglisten, etc) eingebaut habt, schreibt in den Header jeder Mail verschiedene Informationen des Benutzers hinein, welcher die Mail geschrieben und abgeschickt hat. So habt ihr keinen Stress mehr mit Spams, da ihr sofort wisst, wer diesen geschickt hat (welcher User, wann, von welchem Server, etc)


Ich hatte auch mal etwas zu dem Thema angefangen, evtl. koennt ihr da noch was herauslesen (speziell die Beispiele habe ich oben ausgelassen):

Zitat:

1. Kein register_globals

Ihr solltet es kennen: Das Flag "register_globals". Seit PHP 4.x.x ist es standardmaessig auf off, dennoch gibt es noch einige Server die es an haben.
Falls ihrs nicht kennt, hier eine kleine Erklaerung: Es war ueblich $_POST, $_GET oder $_COOKIE Variablen (welche ja vom Client stammen), direkt als Variablennamen zu deklarieren.
Was sich ein bissle komisch anhoert ist in Wirklichkeit ganz leicht:

Was heute $_POST['blubb'] ist, war frueher (und kann immernoch so eingestellt werden), dass ihr einfach mittels $blubb auf den Wert zugreifen koennt.
Falls ihr jedoch intern eine Variable $blubb verwendet und diese nicht initialisiert (z.b. auf 0 stellt), kann so sehr viel Unfug getrieben werden.

Also deswegen: register_globals = Off. Wie? Einfach per Befehl mittels:
Code:

ini_set('register_globals', '0');


Am besten ihr schreibt das in eure Konfigurationsdatei oder so rein.



2. Generell keine Globalen Variablen

Es ist einfach schlechter Stil und auch sehr fehleranfaellig. Eine "richtige" Sicherheitsluecke ist dies aber nicht (nicht dass ihr denkt, dass jetzt jeder auf den Wert der Variablen zugreifen kann, nur weil sie global ist.



3. Abfangen falscher Werte

Generell gilt: Jede User-Eingabe und jeder Parameter, der eurem PHP-Skript zugrunde liegt sollte abgefangen werden.

Wie ihr das tut bleibt euch ueberlassen. Es gibt einfache, komplizierte und sichere Loesungen. Hier mal ein paar meiner Varianten:


Typecast
========
Sehr einfach ist der typische Typecast. Falls ihr z.b. einen Query mit einer ID abfragen wollt, dann macht ihr das so:

Code:

$qry = mysql_query("SELECT * FROM `blubb` WHERE `id`='" . (int)$_GET['id'] . "'");


Und schon kann theoretisch niemand mehr ueber diesen Query unfug treiben. Selbst wenn falsche Integer-Werte herauskommen, kann man damit nicht den Query veraendern.



Konstanten
==========
Fuer die obige Variante brauchen wir in jedem Query einen Typecast. Was ist wenn wir mal einen vergessen?

Sehr nützlich ist daher folgender Codeschnipsel:

Code:

//Ist der Parameter gesetzt
if (isset($_GET['id']))
{
  //Konstante deklarieren
  define('GET_ID', (int)$_GET['id']);
}
else define('GET_ID', 0);


In euren Queries greift ihr dann einfach so darauf zu:
Code:

$qry = mysql_query("SELECT * FROM `blubb` WHERE `id`='" . GET_ID . "'");




Abfragen
========
Um wirklich sicher zu gehen, dass der User keinen Mist baut, kann man z.b. auch gleich abfragen, ob diese ID ueberhaupt in der Datenbank ist.
Oder ob der User nur bestimmte Zeichen nutzen darf.

Beispiel:

Code:

//Ist der Parameter gesetzt
if (isset($_GET['id']))
{
  //Abfrage, ob es einen Datensatz mit dieser ID gibt
  //@ sollte davor, da es sonst zu Fehlern kommen kann, da es die Reihe evtl. nicht gibt
  $qry = @mysql_query("SELECT `id` FROM `mytable` WHERE `id`='" . (int)$_GET['id'] . "'");
  $row = @mysql_fetch_row($qry);
  //Konstante deklarieren
  define('GET_ID', (int)$row[0]);
}
else define('GET_ID', 0);


Aber Achtung: Solche Abfragen (speziell mit Queries) koennen die Performance runterziehen.
Ihr koennt solche ID oder Page abfragen generell in einer separaten Datei ausfuehren, welche jedesmal ausgefuehrt wird - vorrausgesetzt ihr benutzt immer dieselben Namen.

So koennt ihr euch euren eigenen Abfragestandard bauen, ohne dass ihr euch um Werte sorgen muesst.

Ideal ist z.b. die Abfrage ob eine korrekte ID gesetzt ist: if (defined('GET_ID')) { ... }
Aber Achtung: Mit obigen Beispiel wird (falls keine korrekte ID) GET_ID 0 gesetzt, das heisst sie ist defined und er führt den Code aus.


4. Abfangen vieler Werte
========================
Falls ihr grosse Formulare habt und viele verschiedene Eingaben, z.B. ein Userprofil aktualisieren, dann solltet ihr das evtl. ueber ein temporaeres Array machen.
Ich (wir) arbeiten mit Klassen, d.h. wir wissen welches Attribut welchen Datentyp hat, bzw. welche Zeichen erlaubt sind und welche nicht.
Das alles kann man wunderbar dynamisch Abfragen und beim kleinsten Fehler eine Exception casten (Fehlermeldung an den User).

Da so ein System aber ungemein aufwendig ist, hier eine kleinere, abgespeckte Version:

Code:

//temporaeres Array initialisieren
$myarr = array();

//temporaerer Wert (zum Arbeiten)
$tmp = "";

//Abfragen ob $_POST ueberhaupt deklariert (sollte sein, aber foreach ist ein bissle allergisch)
if (is_array($_POST))
{
  //Jedes Element von $_POST durchgehen
  //Achtung: $_POST kann auch weitere Arrays enthalten, das ist hier nicht beruecksichtigt
  foreach($_POST AS $key => $value)
  {
    //unsinnige Leerzeichen (Anfang/Ende) kuerzen
    $tmp = trim($value);
   
    //Escape-Zeichen hinzufuegen (z.b. \" statt ", schadet so nicht den Datenbank Abfragen etc)
    $tmp = addslashes($tmp);
   
    //Weitere Sachen die ihr haben wollt ;)
   
    $myarr[$key] = $tmp;
  }
}


Hierbei solltet ihr aber auch darauf achten, dass hier stripslashes() ausfuehren muesst, wenn ihr wieder Werte aus der DB lest.

Und schon koennt ihr mit einem sichereren (100% sicher ist nie was), weiterarbeiten.


PHP führt standardmäßig automatisch die Funktion addslashes() bei Usereingaben ($_GET, $_POST, $_COOKIE) durch. Jedoch gibt es auch Server, die das ausgeschaltet haben.
Ob das der Fall ist, koennt ihr mittels get_magic_quotes_gpc() ueberpruefen. Falls nicht, solltet ihr addslashes() manuell drueber laufen lassen:

Code:

if (!get_magic_quotes_gpc())
{
  aaslashes($_GET);
  aaslashes($_POST);
  aaslashes($_COOKIE);
}

function aaslashes(&$foo)
{
  if (is_array($foo))
  {
    foreach($foo AS $key => $value)
    {
      //Falls $foo wieder ein Array ist, rekursiver Aufruf
      if (is_array($value)) $foo[$key] = aaslashes($value);
      //Falls nicht, Slashes adden
      else $foo[$key] = addslashes($value);
    }
  }
  else $foo = addslashes($foo);
  return $foo;
}




Generell: Verlasst euch nie auf irgendwelche Server-Vorgaben oder sonstiges. Fragt immer alles ab, auch Sachen von der DB (welche eigentlich sicher sein sollten), koennen Admins kaputtschiessen. Also auch hier Vorsicht!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
sparkY`-
Newcomer
Newcomer


Angemeldet: 07.02.2004
Beiträge: 17
Wohnort: Karlsruhe

BeitragVerfasst am: 27.12.2005, 15:00    Titel: Antworten mit Zitat
noch ein Tip von mir:
der setzt allerdings eine entsprechende Implementierung vorraus, soll heissen man kann nicht jedes Script einfach so umbauen.

Die Sourcen komplett außerhalb vom jeweiligen www-root im filesystem ablegen und so wenig Rechte wie möglich geben.
Somit habt ihr im besten Fall nacher nur noch eine index.php im jeweiligen öffentlichen www-root liegen.
Und (entsprechende Implementierung wieder vorrausgesetzt) es wird nur eine Instanz des Quellcodes benötigt.
Hat den netten Nebeneffekt, dass man entsprechend mehr Möglichkeiten hat das komplette System/Server sicherer zu machen, würde hier jetzt aber zu weit führen Smilie

Das ganze geht zwa schon eher in Richtung Portal-Theorie, lässt sich aber trotzdem auch bei kleineren Projekten sinnvoll einsetzten.

wünsche noch schönes Rest-Jahr 2005 Smilie
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    9dots.de Webdesign Community Foren-Übersicht -> Coding-Tutorials Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

Board Software by phpBB © 2001, 2005 phpBB Group. Impressum
Dominik Wuttke - Moritz Münchmeyer - Joachim Nagel GbR.
AGB