Comment démontrer une exploitation de extract($_POST)?

Je suis pas un développeur PHP mais je suis évaluation de la sécurité d'une application PHP5.

L'auteur a invoqué extract($_POST) et extract($_GET) dans certains endroits, en dehors des fonctions.

Ma suggestion est d'appeler extract($_POST, EXTR_PREFIX_ALL, 'form') et de modifier le code en conséquence, mais sa position est que toute variable est en train d'être redéfini à l'intérieur ultérieure comprend de toute façon.

Je peux facilement changer les superglobales en fournissant, par exemple, _ENV=something à l'intérieur du poste de valeurs, mais les superglobales sont des tableaux et je suis à la transformer en des chaînes, je ne suis pas sûr que ça peut avoir de mauvais effets.

Je pouvais avoir un coup d'oeil à la plusieurs isset() utilise et revenir en arrière à partir de là.. mais j'imagine qu'il y a des attaques de ce genre qui ne nécessitent pas de connaissances ou de divination de la source.

Est-il intéressant de la variable à définir/changé, peut-être dans les entrailles de PHP?

Grâce

La seule chose qui vient à l'esprit est d'écraser une superglobale de cette façon (c'est à dire la définition d'un tableau nommé _SERVER à l'intérieur de $_POST et de l'extraction que dans l'espace mondial). Est-ce possible? Il va remplacer $_SERVER? Probablement pas (je l'espère). Je vais essayer un peu de temps.
Oui, il a travaillé avec _ENV au moins. Fournir EXTR_SKIP permettrait de résoudre ce problème.
(suggestion) en Utilisant Suhosin évite d'écraser des Superglobales et contribue à atténuer les vecteurs d'attaque.

OriginalL'auteur Marco Mariani | 2010-10-01

  1. 15

    Pour l'évaluation de la "puissance", essayez ceci:

    File:htdocs/mix/extraction.php

    <?php
extract($_GET);
var_dump($_SERVER);//after extract
?>

    et de l'appeler comme ça:

    http://localhost/mix/extraction.php?_SERVER=test

    Après l'extrait sur mon Xampp le résultat ressemble à quelque chose comme ça:

    string(4) "test"

    Si quelqu'un sait quelque chose à propos de votre variable de nommage et que vous utilisez de l'extrait sur $_POST ou $_GET globals, alors vous avez un sérieux problème.
    Avec un peu de temps et de travail, il serait possible de trouver des dénominations par essai et d'erreur.

    Sans connaître votre source un intrus pourrait essayer de détourner l'échelle mondiale variabl comme $_SESSION (mais ici, il n'aura aucun effet si vous ne le session_start(); avant de l'extraire($_GET), $_COOKIE ou $_SERVER et même définir des valeurs spécifiques pour eux comme ça:

    //localhost/mix/extraction.le php?_SERVER[HTTP_USER_AGENT]=Iphone

    Si vous utilisez de l'extrait de comme ça:

    extract($var,EXTR_SKIP);

    extract($var,EXTR_PREFIX_SAME,'prefix');

    extract($var,EXTR_PREFIX_ALL,'prefix');

    ensuite, vous serez parfaitement en sécurité.

    Au début, je pensais que votre réponse était juste réaffirmation de ce que nous avons déjà dit. Puis j'ai essayé de fixer des éléments de tableau comme ça, et Oh Mon Dieu 🙂

    OriginalL'auteur ITroubs

  2. 9

    Un nom commun pour la connexion de base de données $db, mais qui aurait tout faire exploser le système, vous pouvez remplacer le $_SESSION variable.

    session_start();

$_SESSION['test'] ='test';
var_dump($_SESSION);
$vars = array("_SESSION" => 'awww');
extract($vars);
var_dump($_SESSION);

    sortie

    array(1) {
  ["test"]=>
  string(4) "test"
}
string(4) "awww"

    Remplacer les variables $idUser ou d'autres choses amusantes, veulent gâcher la iterables?
    Passer array('i' => 5) pour l'extraire, il y a toutes sortes de plaisir que vous pouvez avoir en fonction de la portée.

    Edit:

    Je viens de penser à un autre, si le formulaire est handeling les uploads de fichier, pourquoi ne pas essayer de remplacer les variables nommé $file, $fileName, $fileExtention et voir si vous pouvez l'obtenir pour lire des fichiers à l'extérieur de votre niveau d'autorisation.

    Donc, ce être fait? Oh mon Dieu
    Comme les autres superglobales, _SESSION est un tableau. Je peux changer de chaîne, mais toute utilisation de _SESSION partir de ce point, la cause juste une erreur. Maintenant, je suis à la recherche des variables spécifiques, merci.

    OriginalL'auteur Kristoffer Sall-Storgaard

  3. 1

    Je ne suis pas au courant de tout universel d'exploitabilité.

    De toute façon, c'est terriblement mauvaise pratique.

    Ce que le script de l'auteur est en train de dire, c'est que le script de sécurité s'appuie sur lui de ne pas oublier quelque chose dans la suite de la comprend, qui est horrible.

    De solides arguments généraux contre le extract()ing, voir Ce qui est si mal à extraire()?

    Malheureusement, je n'ai pas le pouvoir de simplement dire "c'est mauvais", ou je n'aurais pas demandé 🙁
    le plus vous devriez vous poser et , si vous dans le genre de pouvoir de simplement dire "c'est mauvais".

    OriginalL'auteur Pekka 웃