Archiv der Kategorie: webdev

PHP bringt prinzipiell alles mit, um anständiges Hashing zu betreiben. bcrypt ist der Way To Go, aber auch ohne bcrypt kann man mit vernünftigem Einsatz der vorhanden Hashing-Algorithmen (Iterationen + Salt) gut zurechtkommen – Symfony machts im MessageDigestPasswordEncoder.php richtig. Hauptproblem ist aber, dass vom Durchschnitts-Nutzer zuviel Wissen abverlangt wird, um wirklich sicheres Hashing zu betreiben. Deswegen schickt sich jetzt in PHP 5.5 eine Hashing-Library an, es besser zu machen. Bis es soweit ist und die Funktionalität im Core ankommt, gibt es für PHP = 5.3.7 eine Compatiblity-Library, die das Verhalten der kommenden Hashing-Funktionen nachbildet.

Die Signaturen der Funktionen aus der Compat-Library sind wie folgt:

password_hash($password, $algo, $options = array())

Wobei im Options-Array der cost-Factor von bcrypt und das salt spezifiziert wird.… Den ganzen Post lesen

In der PHP-Welt scheint der Mythos vorzuherrschen, dass die Nutzung von htmlspecialchars sämtlichen Input in sämtlichen Situation sicher macht. Quasi die „one fits all“ – Funktion. Beginnen wir gleich mal mit einem Beispiel. Kein Witz, so gesehen:

function get_user_id($db)
{
	$username = htmlspecialchars(trim($_POST['username']));
	$res = $db->query("SELECT `id` FROM `accounts` WHERE `login` = '$username' LIMIT 1");
	return $res[0]['id'];
}

Cool! Schauen wir uns doch mal die Signatur von htmlspecialchars an:

string htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode = true ]]] )

Das verflixte Hochkomma

Besonderes Augenmerk sei auf die Flags gelegt.… Den ganzen Post lesen

Das Problem Cross-Site-Scripting / XSS ist präsenter denn je – ständig hört man von neuen Angriffen mit teils verheerenden Folgen, die weit über das Entstellen von Gästebüchern hinausgehen. Seit 2009 in der Entwicklung und mittlerweile mit einer fast vollständigen Implementierung in Chrome und Firefox schickt sich die Content Security Policy nun an, XSS den Kampf anzusagen. Aktuell befindet sich die CSP noch im Status W3C Working Draft und wird speziell um HTML5-relevante Features wie etwa Web-Sockets ergänzt. Das heißt umgekehrt, dass man sie bereits heute problemlos verwenden kann. Aber von vorne.… Den ganzen Post lesen

Als uns mit PHP 5.2 die filter_var-Funktion geschenkt wurde, war die Zeit solcher Monster vorbei (hier entliehen):

$urlregex = "^(https?|ftp)\:\/\/([a-z0-9+!*(),;?&=\$_.-]+(\:[a-z0-9+!*(),;?&=\$_.-]+)?@)?[a-z0-9+\$_-]+(\.[a-z0-9+\$_-]+)*(\:[0-9]{2,5})?(\/([a-z0-9+\$_-]\.?)+)*\/?(\?[a-z+&\$_.-][a-z0-9;:@/&%=+\$_.-]*)?(#[a-z_.-][a-z0-9+\$_.-]*)?\$";
if (eregi($urlregex, $url)) {echo "good";} else {echo "bad";}

Die simple, aber effektive Syntax:

filter_var($url, FILTER_VALIDATE_URL)

Als dritten Parameter können Filter-Flags übergeben werden, im Bezug auf die URL-Validierung gibt es die folgenden 4 Kandidaten:

FILTER_FLAG_SCHEME_REQUIRED
FILTER_FLAG_HOST_REQUIRED
FILTER_FLAG_PATH_REQUIRED 
FILTER_FLAG_QUERY_REQUIRED 

Dabei sind die ersten beiden FILTER_FLAG_SCHEME_REQUIRED und FILTER_FLAG_HOST_REQUIRED default.

Ans Eingemachte

So, dann schauen wir uns doch mal ein paar kritische Kandidaten an:

filter_var('http://example.com/"><script>alert("xss")</script>', FILTER_VALIDATE_URL) !==