Dois-je mysql_real_escape_string tous les cookies que je reçois de l'utilisateur pour éviter l'injection de mysql en php?

Question

Lorsqu'un utilisateur accède à mon site, mon script recherche 2 cookies qui stockent l'identifiant de l'utilisateur + une partie du mot de passe pour les connecter automatiquement.

Il est possible d'éditer le contenu des cookies via un éditeur de cookies. Il est donc possible d'ajouter du contenu malveillant à un cookie écrit?

Devrais-je ajouter mysql_real_escape_string (ou autre chose) à tous mes appels de cookies ou existe-t-il une procédure intégrée qui ne permettra pas que cela se produise?

Answer 1

Ce que vous vraiment devez faire, c’est ne pas envoyer ces valeurs de cookies qui sont piratables au départ. Au lieu de cela, pourquoi ne pas hacher le nom d’utilisateur, le mot de passe et un sel (secret) et le définir comme valeur de cookie? c'est-à-dire:

define('COOKIE_SALT', 'secretblahblahlkdsfklj');
$cookie_value = sha1($username.$password.COOKIE_SALT);

Ensuite, vous savez que la valeur du cookie sera toujours une chaîne hexadécimale de 40 caractères, et vous pouvez comparer la valeur renvoyée par l'utilisateur à ce qui se trouve dans la base de données pour décider si elle est valide ou non:

if ($user_cookie_value == sha1($username_from_db.$password_drom_db.COOKIE_SALT)) {
  # valid
} else {
  #not valid
}

mysql_real_escape_string crée un hit supplémentaire dans la base de données, BTW (beaucoup de gens ne se rendent pas compte que cela nécessite une connexion à une base de données et interroge MySQL).

La meilleure façon de faire ce que vous voulez si vous ne pouvez pas modifier votre application et insister sur l'utilisation de valeurs de cookies hackables est d'utiliser instructions préparées avec des paramètres liés .

Answer 2

L'intérêt de mysql_real_escape_string n'est pas de se protéger contre les attaques par injection, mais bien de garantir que vos données sont stockées avec précision dans la base de données. Ainsi, il devrait être appelé sur N'IMPORTE QUELLE chaîne entrant dans la base de données, quelle que soit sa source.

Vous devriez cependant également utiliser des requêtes paramétrées (via mysqli ou PDO) pour vous protéger de l'injection SQL. Sinon, vous risquez de vous retrouver comme la petite école de Bobby Tables .

Answer 3

J'utilise uniquement mysql_real_escape_string avant d'insérer des variables dans une instruction SQL. Vous allez vous perdre si certaines de vos variables sont déjà échappées, puis vous les échappez à nouveau. C’est un bug classique que vous voyez dans les applications Web des blogues des débutants:

  

Lorsque quelqu'un écrit une apostrophe, il continue d'ajouter des barres obliques qui détruisent les pages du blog.

La valeur d'une variable n'est pas dangereuse en soi: c'est seulement lorsque vous la mettez dans une chaîne ou quelque chose de similaire que vous commencez à vous perdre dans des eaux dangereuses.

Bien sûr, ne faites jamais confiance à tout ce qui vient du côté client.

Answer 4

Les instructions préparées et la liaison de paramètres sont toujours un bon choix.

PEAR :: MDB2 prend en charge les instructions préparées, par exemple:

$db = MDB2::factory( $dsn );

$types = array( 'integer', 'text' );
$sth = $db->prepare( "INSERT INTO table (ID,Text) (?,?)", $types );
if( PEAR::isError( $sth ) ) die( $sth->getMessage() );

$data = array( 5, 'some text' );
$result = $sth->execute( $data );
$sth->free();
if( PEAR::isError( $result ) ) die( $result->getMessage() );

Cela permettra uniquement à des données correctes et à un nombre prédéfini de variables d'entrer dans la base de données.

Vous devez bien sûr valider les données avant d'aller jusque-là, mais la préparation des déclarations est la validation finale à effectuer.

Answer 5

Vous devriez mysql_real_escape_string quoi que ce soit qui pourrait être potentiellement dangereux. Ne faites jamais confiance à tout type de saisie pouvant être modifiée par l'utilisateur.

Answer 6

Je suis d'accord avec vous. Il est possible de modifier les cookies et d’envoyer des données malveillantes.

Je pense qu'il est judicieux de filtrer les valeurs que vous obtenez des cookies avant de les utiliser. En règle générale, je filtre toute autre entrée susceptible d'être falsifiée.

Answer 7

Yegor, vous pouvez stocker le hachage quand un compte utilisateur est créé / mis à jour, puis chaque fois qu'un login est initié, vous hachez les données publiées sur le serveur et comparez-les avec ce qui était stocké dans la base de données pour ce nom d'utilisateur.

(Sur le dessus de ma tête en vrac php - traiter comme un pseudo-code):

$usernameFromPostDbsafe = LimitToAlphaNumUnderscore($usernameFromPost);
$result = Query("SELECT hash FROM userTable WHERE username='$usernameFromPostDbsafe' LIMIT 1;");
$hashFromDb = $result['hash'];
if( (sha1($usernameFromPost.$passwordFromPost.SALT)) == $hashFromDb ){
    //Auth Success
}else{
   //Auth Failure
}

Après une authentification réussie, vous pouvez stocker le hachage dans $ _SESSION ou dans une table de base de données de nom d’utilisateur / de hachage authentifié et mis en cache. Renvoyez ensuite le hachage au navigateur (dans un cookie par exemple) pour que les chargements de page suivants renvoient le hachage au serveur pour qu'il soit comparé au hachage stocké dans la mémoire de votre choix.

Answer 8

mysql_real_escape_string est donc passé & # 233; ... De nos jours, vous devriez vraiment utiliser la liaison de paramètres à la place.

Je préciserai en mentionnant que je faisais référence à Préparez les instructions et fournissez un lien vers un article qui montre que parfois, mysl_real_escape_string ne suffit pas: http://www.webappsec.org/projects/ articles / 091007.txt

Answer 9

Je recommanderais d'utiliser htmlentities ($ input, ENT_QUOTES) au lieu de mysql_real_escape_string car cela évitera également toute sortie accidentelle de code HTML réel. Bien sûr, vous pouvez utiliser mysql_real_escape_string et htmlentities, mais pourquoi voudriez-vous?