• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Nutzereingaben in .php speichern - Wie maskieren?

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
Hi Leute,

[src=php]$host = $_POST['host'];
$user = $_POST['user'];
$pw = $_POST['pw'];
$name = $_POST['name'];

$databaselogin = "<?php"."\n";
$databaselogin .= "\$db['host'] = '".$host."';"."\n";
$databaselogin .= "\$db['user'] = '".$user."';"."\n";
$databaselogin .= "\$db['pw'] = '".$pw."';"."\n";
/*...*/[/src]
Wenn ich etwas deratiges habe. Wie sollte ich dann die Daten maskieren, damit mir damit keine "bösen" Daten in die Datei geladen werden können?

Ich habe leider vergeblich nach etwas wie phpspecialchars() oder so gesucht.

Ich lasse während ein "Install"-Skript durchläuft mehrere Dateien erstellen die halt so, oder so ähnlich erstellt werden.
Allerdings könnte, solange der Installationsvorgang noch zugänglich ist, theoretisch (zufällig) ein Angreifer in diesen 10min oder so, auf die Datei zugreifen und unerwünschte Dateien einschleusen. Muss ich mir da selber extra eine Funktion überlegen, die auf php-Funktionen prüft?
Wie könnte die aussehen, was muss ich beachten?

Bei all meinen Suchen habe ich bisher immer nur gefunden wie man Formulare mit php erzeugt, aber nicht wie man über ein Formular (sicher) php-Code erzeugt.

Vielleicht kann mir hier ja einer weiterhelfen.

LG
 

sars

Agent Provocateur

Registriert
15 Juli 2013
Beiträge
54
Du könntest anhand der Nutzer-Eingaben erstmal testen ob eine Verbindung zur Datenbank damit möglich ist, bevor du die Login-Daten in eine Datei schreibst. Andere Datensätze lassen sich ggf. auch vorher validieren. Eine sichere Methoden PHP-Code zu filtern/maskieren wäre mir nicht bekannt.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #3
Du könntest anhand der Nutzer-Eingaben erstmal testen ob eine Verbindung zur Datenbank damit möglich ist, bevor du die Login-Daten in eine Datei schreibst.

[src=php]<?php
if(!isset($_POST['host'],
$_POST['user'],
$_POST['name'],
$_POST['pw'])) {
define('ERROR');
} elseif(!mysql_connect($_POST['host'], $_POST['user'], $_POST['pw'])) {
define('ERROR');
} elseif(!mysql_select_db($_POST['name'])) {
define('ERROR');
} else {
$host = $_POST['host'];
$user = $_POST['user'];
$pw = $_POST['pw'];
$name = $_POST['name'];

$databaselogin = "<?php"."\n";
$databaselogin .= "\$db['host'] = '".$host."';"."\n";
$databaselogin .= "\$db['user'] = '".$user."';"."\n";
$databaselogin .= "\$db['pw'] = '".$pw."';"."\n";
$databaselogin .= "\$db['name'] = '".$name."';"."\n";
$databaselogin .= "\n";
$databaselogin .= "mysql_connect(\$db['host'], \$db['user'], \$db['pw']);"."\n";
$databaselogin .= "mysql_select_db(\$db['name']);"."\n";
$databaselogin .= "?>";
?>[/src]
Also im Endeffekt einfach so?
 

sars

Agent Provocateur

Registriert
15 Juli 2013
Beiträge
54
Joa, so im Prinzip - so ist zumindest sichergestellt, dass die Datenbank-Paramter richtig sind.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Allerdings schützt das nicht zuverlässig vor einer PHP-Code-Injection. Ein Angreifer könnte als Hostname einen eigenen MySQL-Server angeben, welcher beliebige Zugangsdaten akzeptiert, z.B. `';eval($_GET[e]);?>` als Benutzername und/oder Passwort. Ausserdem führt dein Ansatz zu Problemen, wenn der Benutzername oder das Passwort `'` oder `\` enthalten - zumindest diese Zeichen solltest du durch `\'` bzw. `\\` maskieren. Ausserdem wäre sinnvoll, beim ersten Aufruf des Installationsskripts sofort eine Lock-Datei zu erstellen, welche einen weiteren Aufruf verhindert.
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
Du könntest natürlich auch gewisse Zeichen explizit oder implizit ausschließen (bzw. nur einen bestimmten Satz an Zeichen zulassen).
Dass du damit Gefahr läufst dass deine Routine nicht alle (SQL-Server seitig erlaubten) Benutzernamen zulässt, ist natürlich problematisch.

Du könntest die Zeichenfolge natürlich auch base64 kodiert speichern:

[src=php]$databaselogin .= "\$db['user'] = '".base64_encode($user)."';";[/src]

und bei der Verwendeung:

[src=php]base64_decode($db['user']);[/src]
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #7
Wenn ich deine Lösung verwende accC, dann würde jedes weitere maskieren unnötig werden, richtig?
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
Wenn du die Daten nicht irgendwie weiter verwenden möchtest, dann sollte keine weitere Maskierung nötig werden.
Tabellenprefixe, die du in deine Querys einbaust, sollten natürlich weiter maskiert werden, etwa mit mysqli_real_escape_string (wahlweise mit oder ohne i, je nachdem, ob du von dem einen oder anderen Gebrauch gemacht hast) oder einem Äquivalent.
Auch für die Ausgabe müsstest du weiter maskieren, da dann mit htmlspecialchars oder einem Äquivalent.

Ich weiß allerdings auch nicht genau, ob base64 nur unproblematische Ausgaben erzeugt. bevor ich dir jetzt etwas falsches sage, solltest du dir die entsprechende Funktion mal genauer anschauen.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #9
Wenn du die Daten nicht irgendwie weiter verwenden möchtest, dann sollte keine weitere Maskierung nötig werden.
Ich werde lediglich einmal eine Verbindung zu der Datenbank herstellen (in der Abfrage vorher). Danach wird die erzeugte Datei aufgerufen, wenn eine Datenbankverbindung benötigt wird. Sonst werden die Daten nicht mehr verwendet.
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
In einem *_connect() sollte das keine Probleme bereiten.
Nur wie gesagt, denke daran, dass du die Kodierung wieder aufheben musst: mysql(i)_connect(base64_decode($host), ...)
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #11
Wird dran gedacht ;-)

Danke für die Hilfe
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #13
spielt Cross-Site-Scripting keine Rolle?
Im Endeffekt habe ich genau das gefragt.
Damit keine XSS-Schwachstelle entsteht reicht es wohl, wenn ich Datenbankzugangsdaten wie oben beschrieben abspeichere und direkt in die Funktion einsetzte.
Da die gespeicherten Daten durch die base64-Codierung "entschärft" abgespeichert und direkt in die Funktion eingesetzt wurden, können diese Daten nicht mehr in einem anderen Kontext verwendet werden - somit sollte, wie ich es verstanden haben, kein Problem mehr auftreten können.
Zumindest nicht durch diese Eingabe ;-)
 

LemonDrops

Neu angemeldet

Registriert
20 Juli 2013
Beiträge
543
Ich würde an deiner Stelle ein Framework einsetzen, dass dir diese Funktionalität bietet und absichert.
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
spielt Cross-Site-Scripting keine Rolle?

Wenn keine Ausgabe und kein Ausführen der Eingabe angedacht ist, nicht.

In einem mysql_connect(); gewöhnlich nicht, in einem echo(); schon.
Allerdings maskierst du ja auch je nach Weiterverarbeitung anders.

[src=php]$evilString;

mysql_query("DO SOMETHING WITH " . $evilString); // böse
mysql_query("DO SOMETHING WITH " . mysql_real_escape_string($evilString)); // gut

echo "he said: " . $evilString; // böse
echo "he said: " . htmlspecialchars($evilString); // gut[/src]

Im mysql_query will ich mich vor SQL-Injections schützen, daher muss ich "nur" sicherstellen, dass der MySQL-Server im $evilString keinen Code interpretiert. Im Fall von echo möchte ich mich vor bösen HTML und/oder JavaScript "Code" schützen, den der Browser eines Clients dann interpretieren würde.

Der Schnipsel ist natürlich weder vollständig noch bietet er hundertprozentige Sicherheit, er ist lediglich als kurzer Hinweis auf die Unterscheidung gedacht.
 
Oben