SQL injections : Injection de règle de validation en Laravel

Qu'est-ce qu'une injection de règle de validation Laravel ? Eh bien, regardons d'abord le code vulnérable suivant

public function update(Request $request) {

 $id = $request->route('id');

 $rules = [

   'username' => 'required|unique:users,username,' . $id,

 ];


 $validator = Validator::make($request->post(), $rules);

 if ($validator->fails()) {

   return response()->json($validator->errors(), 422);

 }


 $user = User::findOrFail($id);

 $user->fill($validator->validated());

 $user->save();

 return response()->json(['user' => $user]);

}

Si votre œil a attrapé la vulnérabilité dans

'required|unique:users,username,' . $id

bon travail!

Donc, ce que la règle "unique" fait ici, c'est de s'assurer que le nom d'utilisateur est unique dans la table des utilisateurs et qu'elle ignorera également la ligne avec l'ID donné lors de la vérification. Mais le problème ici est que nous avons obtenu le $id de la demande et sans le valider, nous l'avons utilisé pour créer une règle de validation basée sur l'entrée de l'utilisateur. Ainsi, en utilisant cela, nous pouvons personnaliser la règle de validation et créer des vecteurs d'attaque, examinons les exemples suivants.

1. Rendre la règle de validation facultative

La chose la plus simple que nous puissions faire ici est d'envoyer une demande avec ID = 10|sometimes, ce qui modifiera la règle de validation required|unique:users,username,10|sometimes et nous permettra de ne pas ignorer le nom d'utilisateur dans les données de la demande, en fonction de la logique métier de votre application, un contournement comme celui-ci pourrait créer un problème de sécurité.

2. DDOS le serveur en créant une règle de validation REGEX maléfique

Un autre vecteur d'attaque ici pourrait être de créer une validation Regex maléfique, vulnérable aux attaques ReDoS et DDOS de l'application.

Par exemple, la requête suivante consommerait beaucoup de CPU et si plusieurs requêtes envoyées simultanément peuvent provoquer un gros pic de CPU sur le serveur.

PUT /api/users/1,id,name,444|regex:%23(.*a){100}%23
{
    "username": "aaaaa__ALOT_OF_REPETED_As_aaaaaaaaaa"
}

3. Injection SQL

L'injection SQL la plus simple ici serait d'ajouter simplement une règle de validation supplémentaire qui interroge la base de données, par exemple

PUT /api/users/1,id,name,444|unique:users,secret_col_name_here
{

    "username":  "secret_value_to_check"

}

Mais il est important de mentionner, car en utilisant unique, nous sommes en mesure de fournir à la fois un nom de colonne personnalisé et des valeurs (les valeurs ne passent pas par la liaison de paramètres PDO), les possibilités d'injection SQL ici ne pourraient pas être limitées à un simple vecteur d'attaque mentionné ci-dessus. Pour plus de détails, consultez le post de Laravel Blog.

En savoir plus sur les injections SQL en laravel ici.

Conseils de prévention :

• La meilleure prévention ici est de ne pas utiliser les données fournies par l'utilisateur pour créer une règle de validation
• Si vous devez créer votre règle de validation en fonction des données fournies (ID dans notre exemple), assurez-vous de convertir ou de valider la valeur fournie avant de la mettre dans la règle de validation.

J'espère que vous avez trouvé cet article vraiment utile, partager avec les autres via les liens ci-dessous.