Top Tweets for #100Daysofcyber
Jour #46 de #100DaysOfCyber | Lab : 2FA broken authentication
Aujourd'hui, j'ai résolu le lab PortSwigger 2FA broken authentication en exploitant un défaut de logique dans le flux de connexion et une absence de rate limiting sur la validation du code OTP.
Voici les étapes techniques de la résolution :
➖ 1. Analyse du fonctionnement du 2FA En me connectant avec mon compte de test (wiener), j'ai analysé les requêtes générées.
Dans la requête POST /login2, l'application s'appuie sur un paramètre nommé verify pour définir quel compte utilisateur est en cours de validation pour le second facteur.
➖ 2. Génération du code de la victime Après déconnexion de mon compte, j'ai renvoyé la requête GET /login2 dans Burp Repeater en remplaçant la valeur du paramètre verify par carlos.
L'envoi de cette requête a déclenché la génération d'un code 2FA temporaire pour Carlos côté serveur.
➖ 3. Brute-force du code OTP Je suis revenu sur la page de connexion, j'ai soumis mes identifiants valides et j'ai entré un faux code 2FA pour intercepter la requête de vérification.
J'ai envoyé ce POST /login2 dans Burp Intruder avec la configuration suivante :
Le paramètre verify positionné sur carlos.
Un marqueur de payload sur le paramètre mfa-code. Le code de validation étant composé de seulement 4 chiffres et le backend ne limitant pas le nombre de requêtes, j'ai lancé le test de toutes les combinaisons.
➖ 4. Accès au compte L'Intruder a identifié la bonne combinaison grâce à une réponse ayant un code de statut HTTP 302 Found (redirection). J'ai chargé cette réponse spécifique dans le navigateur pour être redirigé directement sur l'espace personnel de Carlos et valider le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #Authentication #MFA #2FA #PortSwigger #BurpSuite #Intruder #BruteForce
@_makh0u
Day 2 of #100daysofCyber
Had to restart my streak yesterday...
Currently doing the CyberSecurity 101 pathway [35% complete].
Will be taking the exam for the CyberSecurity 101 (SEC1) professional certification once ready.
![rickyhewitt_dev's tweet photo. Day 2 of #100daysofCyber
Had to restart my streak yesterday...
Currently doing the CyberSecurity 101 pathway [35% complete].
Will be taking the exam for the CyberSecurity 101 (SEC1) professional certification once ready. https://t.co/fLecndAbrj](https://pbs.twimg.com/media/HMURvhQXMAAjJtw.jpg)
Jour #45 de #100DaysOfCyber | Brute-force 2FA, failles logiques et cookies devinables
Aujourd'hui, je continue sur les faiblesses de l'authentification avec 3 concepts du parcours PortSwigger.
➖ 1. Brute-forcer les codes 2FA Un code MFA, c'est souvent juste 4 à 6 chiffres.
Ça fait très peu de combinaisons possibles.
Sans vrai blocage, une machine les teste toutes en un rien de temps.
➖2. Les mécanismes d'authentification "secondaires" La page /login est souvent bien surveillée.
Mais tout ce qui tourne autour changer son mot de passe, la procédure "mot de passe oublié" l'est beaucoup moins.
➖3. Le "Rester connecté" (Remember me) Cette option repose sur un token stocké dans un cookie par exemple.
Ce cookie sert de passe-droit pour zapper toute la connexion donc sa valeur doit être impossible à deviner.
Le problème : beaucoup d'implémentations le fabriquent avec des infos faciles à prévoir.
Un attaquant qui a un compte regarde comment son propre cookie est construit, comprend la recette, et forge ensuite les cookies des autres pour usurper leur identité.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #MFA #2FA #PortSwigger #LogicFlaws #BruteForce #RememberMe
Day #44 of #100DaysOfCyber | Sécurité Dev : Comprendre les failles du MFA
Le MFA (Multi-Factor Authentication) ajoute une couche de sécurité réelle. Mais toutes les implémentations ne se valent pas, et c'est intéressant de comprendre pourquoi.
Voici les 3 points clés à retenir :
➖ 1. La fausse promesse du 2FA par e-mail
La vraie force du MFA vient de la diversité des facteurs : vérifier « ce que tu sais » (mot de passe) et « ce que tu as » (téléphone, token). C'est beaucoup plus robuste que de vérifier deux fois le même type de facteur.
Un exemple concret : le 2FA par e-mail. Si le code de vérification arrive sur ta boîte mail et que celle-ci est accessible avec les mêmes identifiants ou compromise via la même session, on ne fait que valider deux fois le facteur de connaissance.
C'est un second facteur seulement en apparence.
➖ 2. SMS vs Applications dédiées (Le canal de transmission)
Tous les canaux liés à la possession d'un objet ne se valent pas.
Un token dédié (RSA, Google Authenticator) génère le code localement sur l'appareil, de manière isolée.
Le SMS, lui, transite par le réseau de l'opérateur télécom.
Cela ouvre deux angles d'attaque majeurs :
l'interception pure du message et le SIM Swapping (où l'attaquant transfère frauduleusement ta ligne téléphonique sur sa propre carte SIM pour intercepter tes codes de validation).
➖ 3. La faille de logique : Le flow applicatif
La façon dont le flux d'authentification est construit compte autant que le facteur choisi.
Si la validation du mot de passe met déjà l'utilisateur dans un état "connecté" en tâche de fond côté serveur avant même la saisie du code 2FA, il arrive que certaines pages privées restent accessibles si le développeur a oublié de restreindre les droits d'accès.
Ce n'est pas une faille du MFA en tant que concept, c'est une pure faille d'implémentation logique dans le code.
Le MFA reste une excellente pratique.
Mais comme tout mécanisme de sécurité, sa valeur dépend entièrement de la rigueur de sa mise en œuvre côté développement.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #MFA #2FA #PortSwigger #LogicFlaws
Day #43 of #100DaysOfCyber | Lab Pratique :
Exploitation d'une Timing Attack avec #wfuzz
Aujourd'hui, j'ai validé le lab PortSwigger Username enumeration via response timing.
L'occasion parfaite pour prendre en main wfuzz et tester sa réactivité.
Le processus :
➖ Le problème logique : Contrairement au lab précédent, le backend renvoie ici un message d'erreur générique.
Impossible de savoir si un utilisateur existe en se basant sur le texte de la réponse.
La seule faille réside dans le temps de traitement du serveur.
➖ Énumération des utilisateurs au timing : J'ai configuré wfuzz pour envoyer une liste de usernames avec un mot de passe fixe.
En analysant la colonne temps de réponse, une requête a mis beaucoup plus de temps à revenir que toutes les autres,ce qui a attiré mon attention pour tester ce username.
➖ Brute-force du mot de passe : Une fois le bon utilisateur isolé, j'ai relancé wfuzz avec cet identifiant unique et une liste de mots de passe.
Dès que le serveur a renvoyé un code HTTP 302, le mot de passe était validé.
Il ne restait plus qu'à entrer les identifiants sur le navigateur pour terminer le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #PortSwigger #wfuzz #TimingAttack
Day #42 of #100DaysOfCyber | Module de brute-force sur #SAKR.
Au lieu d'utiliser une extension tierce pour ajouter du code comme la dernière fois, j'ai directement implémenté un module de brute-force , inspiré de Burp Intruder, directement dans SAKR.
Le processus technique :
➖ Analyse de la cible : Je me suis connecté sur l'interface web du lab (Username enumeration via subtly different responses).
Depuis l'onglet Network de mon navigateur, j'ai inspecté la structure exacte de la requête HTTP brute pour récupérer l'URL et les paramètres de connexion.
➖ Configuration dans SAKR : J'ai injecté une liste de noms d'utilisateurs et une liste de mots de passe
Le script a été configuré pour tester méthodiquement chaque utilisateur avec la liste de mots de passe associée, sans aucune restriction de débit.
➖ Le verdict du backend : En analysant les résultats générés par SAKR, une ligne s'est immédiatement détachée du lot avec un code de statut HTTP 302 Found (redirection). J'ai tout de suite compris que l'authentification avait fonctionné pour ce compte.
Il ne restait plus qu'à prendre ces identifiants valides, revenir sur le site du lab pour me connecter manuellement et valider le challenge.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #PortSwigger #SAKR #BruteForce #Fuzzer #Automation #ToolsDev
I need to be honest with you all and myself
I’m taking a 2 week break from #100DaysOfCyber.
School and work are demanding my full attention right now and I’d rather pause intentionally than show up halfway.
I’ll be back July 12. Stronger. 💪
Day #41 de #100DaysOfCyber | L'énumération d'utilisateurs (Username Enumeration)
On attaque les failles d'authentification.
Et avant même de parler de mots de passe, il faut comprendre comment un attaquant devine quels comptes existent vraiment.
L'idée ? Avant d'essayer un mot de passe, il cherche d'abord à savoir si un email ou un login est bien présent dans la base.
Et souvent, c'est le serveur lui-même qui le trahit de trois façons.
➖ 1. Les messages d'erreur trop bavards
Tu tentes de te connecter et le serveur répond "Invalid username" si le login n'existe pas, mais "Incorrect password" s'il existe.
Cette petite nuance suffit : l'attaquant teste une liste entière et repère tous les comptes réels.
➖ 2. Le code HTTP ou la structure de la réponse
Parfois le message à l'écran est identique, mais les coulisses changent.
Un compte inexistant renvoie un 401, un compte valide (avec mauvais mot de passe) renvoie un autre avec l'erreur planquée dans le JSON.
Même rendu à l'écran, info différente derrière.
➖ 3. Le temps de réponse
Même si tout est masqué, l'attaquant mesure le temps de réponse.
Compte inexistant : le serveur rejette direct (~10ms). Compte existant : il prend le temps de vérifier le hash du mot de passe (bcrypt, argon2...), donc plus de ms.
Ce décalage suffit à confirmer que le compte existe.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #Authentication #UsernameEnumeration #OWASP
@_makh0u
Day 18 of #100DaysOfCyber 🔐
Random facts from my notes;
The Access Layer is where your device first touches the network.
It’s the first line of defence.
Everything starts here your laptop, your phone, your smart TV.
If this layer is compromised, everything above it is at risk.
Day 83 of #100DaysOfCyber 🚀
Today I studied Networking at a Glance .
🌐 Connects devices
📡 Enables communication
🔐 Secures data transmission
🛡️ Supports reliable networks
Networking is the backbone of cybersecurity.
#PHCyberGiants #100DaysOfCyber #ReverbPointHub #Certified
Day #40 of #100DaysOfCyber | Sécurité Dev : Pourquoi l'authentification casse en prod ?
Pourquoi les failles d'authentification arrivent, et pourquoi elles font si mal.
Quand on code, on se croit protégé parce qu'on a du chiffrement et des protocoles standards.
Mais l'authentification casse presque toujours pour deux raisons.
➖ La première, c'est le brute-force.
Sans rate-limiting, sans blocage, sans CAPTCHA, un attaquant peut tester des millions de mots de passe sans jamais être arrêté.
➖ La deuxième, c'est une faille dans la logique du code.
L'attaquant ne casse pas la serrure : il trouve le moyen de passer à côté.
Une étape de vérification mal codée, et il entre sans mot de passe valide.
#Impact :
Un login franchi donne déjà accès à toutes les données et tous les droits de l'utilisateur si le compte est admin, c'est toute l'app qui tombe : les fonctions d'admin (upload, accès base, commandes) deviennent de nouvelles portes à exploiter.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #BrokenAuthentication #PortSwigger
Day #39 of #100DaysOfCyber | Sécurité Dev : Nouveau chapitre - #Authentication Vulnerabilities
Après avoir bouclé le parcours sur les vulnérabilités côté serveur (Server-side vulnerabilities), on enchaîne aujourd'hui sur un gros pilier de la sécurité web : les failles d'authentification (Authentication vulnerabilities).
Pour attaquer ce volet proprement, il faut d'abord poser les bases théoriques et ne plus confondre les concepts fondamentaux.
#1. La différence cruciale : #Authentification vs #Autorisation
➖ L'Authentification (Qui es-tu ?) : C'est le processus qui consiste à vérifier l'identité d'un utilisateur.
Le serveur s'assure que tu es bien la personne que tu prétends être (ex: entrer son login et son mot de passe).
➖ L'Autorisation (Qu'as-tu le droit de faire ?) : Une fois que ton identité est validée, l'autorisation détermine à quelles ressources ou actions tu as accès (ex: un utilisateur classique n'est pas autorisé à voir la page /admin).
#2. Les 3 types de facteurs d'authentification
Pour prouver son identité à un système, on s'appuie généralement sur trois catégories de facteurs :
#Ce que vous savez (Something you know) : Un élément mémorisé par l'utilisateur. C'est le mécanisme le plus classique mais aussi le plus ciblé (ex: un mot de passe, un code PIN, la réponse à une question secrète).
#Ce que vous avez (Something you have) : Un objet physique ou numérique en possession de l'utilisateur (ex: un token de sécurité, une clé USB YubiKey, une carte SIM pour recevoir un SMS de validation, ou une application d'authentification comme Google Authenticator).
#Ce que vous êtes (Something you are) : Une caractéristique physique propre à l'utilisateur, liée à la biométrie (ex: une empreinte digitale, la reconnaissance faciale, ou le scan de la rétine).
#Un dev qui comprend la sécurité. #Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #Authentication #OWASP #MFA #SecurityDev #Pentest
Day #38 of #100DaysOfCyber | Lab Pratique : Exploitation d'une Server-side Parameter Pollution
Après pas mal de va-et-vient, le lab PortSwigger sur la pollution de paramètres côté serveur (SSPP) est validé.
Le scénario : intercepter une demande de réinitialisation de mot de passe pour forcer l'extraction d'un token admin généré par une API interne.
#Détection de la coupure de logique : En interceptant la requête POST /forgot-password de l'administrateur, on tente d'injecter un délimiteur URL-encodé (%26 pour &) dans le paramètre username : username=administrator%26x=y.
#Le serveur renvoie "Parameter is not supported". C'est le signal clé : l'API interne n'encode pas notre entrée et l'interprète comme un nouveau paramètre.
#Rétro-ingénierie de la requête interne : Pour isoler notre injection, on tente de tronquer le reste de la requête backend invisible en injectant un caractère de commentaire URL-encodé (%23 pour #) : username=administrator%23. Le serveur répond "Field not specified". On vient de deviner que la requête interne attend obligatoirement un second paramètre nommé field.
#Brute-force du paramètre caché : On injecte ce paramètre avec une valeur bidon suivie du commentaire pour nettoyer la fin de la ligne : username=administrator%26field=x%23. Le serveur répond "Invalid field". On passe la requête dans l'Intruder pour brute-forcer la valeur de field avec la liste par défaut de Burp (Server-side variable names). Deux valeurs renvoient un code 200 : username et email.
Extraction du token via le JS : En fouillant dans le fichier JavaScript de l'application (forgotPassword.js), on repère que l'application utilise une variable nommée reset_token.
On tente le tout pour le tout dans le Repeater en passant ce paramètre exact dans notre champ pollué :
username=administrator%26field=reset_token%23 Gagné.
Le serveur interne traite la demande, s'aligne sur le champ demandé et nous recrache directement le token de réinitialisation de l'administrateur dans la réponse HTTP.
#Compromission et validation : Il ne reste plus qu'à utiliser ce token directement dans l'URL de réinitialisation (/forgot-password?reset_token=[TOKEN]), changer le mot de passe de l'administrateur, se connecter à son compte, et supprimer l'utilisateur carlos depuis le panneau d'administration pour résoudre le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #SSPP #Intruder #BurpSuite
@_makh0u
![Sultane221's tweet photo. Day #38 of #100DaysOfCyber | Lab Pratique : Exploitation d'une Server-side Parameter Pollution
Après pas mal de va-et-vient, le lab PortSwigger sur la pollution de paramètres côté serveur (SSPP) est validé.
Le scénario : intercepter une demande de réinitialisation de mot de passe pour forcer l'extraction d'un token admin généré par une API interne.
#Détection de la coupure de logique : En interceptant la requête POST /forgot-password de l'administrateur, on tente d'injecter un délimiteur URL-encodé (%26 pour &) dans le paramètre username : username=administrator%26x=y.
#Le serveur renvoie "Parameter is not supported". C'est le signal clé : l'API interne n'encode pas notre entrée et l'interprète comme un nouveau paramètre.
#Rétro-ingénierie de la requête interne : Pour isoler notre injection, on tente de tronquer le reste de la requête backend invisible en injectant un caractère de commentaire URL-encodé (%23 pour #) : username=administrator%23. Le serveur répond "Field not specified". On vient de deviner que la requête interne attend obligatoirement un second paramètre nommé field.
#Brute-force du paramètre caché : On injecte ce paramètre avec une valeur bidon suivie du commentaire pour nettoyer la fin de la ligne : username=administrator%26field=x%23. Le serveur répond "Invalid field". On passe la requête dans l'Intruder pour brute-forcer la valeur de field avec la liste par défaut de Burp (Server-side variable names). Deux valeurs renvoient un code 200 : username et email.
Extraction du token via le JS : En fouillant dans le fichier JavaScript de l'application (forgotPassword.js), on repère que l'application utilise une variable nommée reset_token.
On tente le tout pour le tout dans le Repeater en passant ce paramètre exact dans notre champ pollué :
username=administrator%26field=reset_token%23 Gagné.
Le serveur interne traite la demande, s'aligne sur le champ demandé et nous recrache directement le token de réinitialisation de l'administrateur dans la réponse HTTP.
#Compromission et validation : Il ne reste plus qu'à utiliser ce token directement dans l'URL de réinitialisation (/forgot-password?reset_token=[TOKEN]), changer le mot de passe de l'administrateur, se connecter à son compte, et supprimer l'utilisateur carlos depuis le panneau d'administration pour résoudre le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #SSPP #Intruder #BurpSuite
@_makh0u](https://pbs.twimg.com/media/HLnd8pzXMAAAhu7.jpg)
![Sultane221's tweet photo. Day #38 of #100DaysOfCyber | Lab Pratique : Exploitation d'une Server-side Parameter Pollution
Après pas mal de va-et-vient, le lab PortSwigger sur la pollution de paramètres côté serveur (SSPP) est validé.
Le scénario : intercepter une demande de réinitialisation de mot de passe pour forcer l'extraction d'un token admin généré par une API interne.
#Détection de la coupure de logique : En interceptant la requête POST /forgot-password de l'administrateur, on tente d'injecter un délimiteur URL-encodé (%26 pour &) dans le paramètre username : username=administrator%26x=y.
#Le serveur renvoie "Parameter is not supported". C'est le signal clé : l'API interne n'encode pas notre entrée et l'interprète comme un nouveau paramètre.
#Rétro-ingénierie de la requête interne : Pour isoler notre injection, on tente de tronquer le reste de la requête backend invisible en injectant un caractère de commentaire URL-encodé (%23 pour #) : username=administrator%23. Le serveur répond "Field not specified". On vient de deviner que la requête interne attend obligatoirement un second paramètre nommé field.
#Brute-force du paramètre caché : On injecte ce paramètre avec une valeur bidon suivie du commentaire pour nettoyer la fin de la ligne : username=administrator%26field=x%23. Le serveur répond "Invalid field". On passe la requête dans l'Intruder pour brute-forcer la valeur de field avec la liste par défaut de Burp (Server-side variable names). Deux valeurs renvoient un code 200 : username et email.
Extraction du token via le JS : En fouillant dans le fichier JavaScript de l'application (forgotPassword.js), on repère que l'application utilise une variable nommée reset_token.
On tente le tout pour le tout dans le Repeater en passant ce paramètre exact dans notre champ pollué :
username=administrator%26field=reset_token%23 Gagné.
Le serveur interne traite la demande, s'aligne sur le champ demandé et nous recrache directement le token de réinitialisation de l'administrateur dans la réponse HTTP.
#Compromission et validation : Il ne reste plus qu'à utiliser ce token directement dans l'URL de réinitialisation (/forgot-password?reset_token=[TOKEN]), changer le mot de passe de l'administrateur, se connecter à son compte, et supprimer l'utilisateur carlos depuis le panneau d'administration pour résoudre le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #SSPP #Intruder #BurpSuite
@_makh0u](https://pbs.twimg.com/media/HLnd8lSWYAASifr.jpg)
![Sultane221's tweet photo. Day #38 of #100DaysOfCyber | Lab Pratique : Exploitation d'une Server-side Parameter Pollution
Après pas mal de va-et-vient, le lab PortSwigger sur la pollution de paramètres côté serveur (SSPP) est validé.
Le scénario : intercepter une demande de réinitialisation de mot de passe pour forcer l'extraction d'un token admin généré par une API interne.
#Détection de la coupure de logique : En interceptant la requête POST /forgot-password de l'administrateur, on tente d'injecter un délimiteur URL-encodé (%26 pour &) dans le paramètre username : username=administrator%26x=y.
#Le serveur renvoie "Parameter is not supported". C'est le signal clé : l'API interne n'encode pas notre entrée et l'interprète comme un nouveau paramètre.
#Rétro-ingénierie de la requête interne : Pour isoler notre injection, on tente de tronquer le reste de la requête backend invisible en injectant un caractère de commentaire URL-encodé (%23 pour #) : username=administrator%23. Le serveur répond "Field not specified". On vient de deviner que la requête interne attend obligatoirement un second paramètre nommé field.
#Brute-force du paramètre caché : On injecte ce paramètre avec une valeur bidon suivie du commentaire pour nettoyer la fin de la ligne : username=administrator%26field=x%23. Le serveur répond "Invalid field". On passe la requête dans l'Intruder pour brute-forcer la valeur de field avec la liste par défaut de Burp (Server-side variable names). Deux valeurs renvoient un code 200 : username et email.
Extraction du token via le JS : En fouillant dans le fichier JavaScript de l'application (forgotPassword.js), on repère que l'application utilise une variable nommée reset_token.
On tente le tout pour le tout dans le Repeater en passant ce paramètre exact dans notre champ pollué :
username=administrator%26field=reset_token%23 Gagné.
Le serveur interne traite la demande, s'aligne sur le champ demandé et nous recrache directement le token de réinitialisation de l'administrateur dans la réponse HTTP.
#Compromission et validation : Il ne reste plus qu'à utiliser ce token directement dans l'URL de réinitialisation (/forgot-password?reset_token=[TOKEN]), changer le mot de passe de l'administrateur, se connecter à son compte, et supprimer l'utilisateur carlos depuis le panneau d'administration pour résoudre le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #SSPP #Intruder #BurpSuite
@_makh0u](https://pbs.twimg.com/media/HLnd8lRXAAAWmGc.jpg)
![Sultane221's tweet photo. Day #38 of #100DaysOfCyber | Lab Pratique : Exploitation d'une Server-side Parameter Pollution
Après pas mal de va-et-vient, le lab PortSwigger sur la pollution de paramètres côté serveur (SSPP) est validé.
Le scénario : intercepter une demande de réinitialisation de mot de passe pour forcer l'extraction d'un token admin généré par une API interne.
#Détection de la coupure de logique : En interceptant la requête POST /forgot-password de l'administrateur, on tente d'injecter un délimiteur URL-encodé (%26 pour &) dans le paramètre username : username=administrator%26x=y.
#Le serveur renvoie "Parameter is not supported". C'est le signal clé : l'API interne n'encode pas notre entrée et l'interprète comme un nouveau paramètre.
#Rétro-ingénierie de la requête interne : Pour isoler notre injection, on tente de tronquer le reste de la requête backend invisible en injectant un caractère de commentaire URL-encodé (%23 pour #) : username=administrator%23. Le serveur répond "Field not specified". On vient de deviner que la requête interne attend obligatoirement un second paramètre nommé field.
#Brute-force du paramètre caché : On injecte ce paramètre avec une valeur bidon suivie du commentaire pour nettoyer la fin de la ligne : username=administrator%26field=x%23. Le serveur répond "Invalid field". On passe la requête dans l'Intruder pour brute-forcer la valeur de field avec la liste par défaut de Burp (Server-side variable names). Deux valeurs renvoient un code 200 : username et email.
Extraction du token via le JS : En fouillant dans le fichier JavaScript de l'application (forgotPassword.js), on repère que l'application utilise une variable nommée reset_token.
On tente le tout pour le tout dans le Repeater en passant ce paramètre exact dans notre champ pollué :
username=administrator%26field=reset_token%23 Gagné.
Le serveur interne traite la demande, s'aligne sur le champ demandé et nous recrache directement le token de réinitialisation de l'administrateur dans la réponse HTTP.
#Compromission et validation : Il ne reste plus qu'à utiliser ce token directement dans l'URL de réinitialisation (/forgot-password?reset_token=[TOKEN]), changer le mot de passe de l'administrateur, se connecter à son compte, et supprimer l'utilisateur carlos depuis le panneau d'administration pour résoudre le lab.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #SSPP #Intruder #BurpSuite
@_makh0u](https://pbs.twimg.com/media/HLnd8lPW4AAQUcA.jpg)
Day #37 of #100DaysOfCyber | Parcours Pre-Security terminé 🎓🛡️
L'objectif initial était de terminer le lab PortSwigger sur la pollution de paramètres (SSPP).
Mais la journée en a décidé autrement.
D'un côté, une grosse journée de dev passée à traquer et corriger des bugs complexes.
De l'autre, une session sur @tryhackme où j'ai passé beaucoup plus de temps que prévu.
Je n'ai pas pu terminer le lab applicatif ce soir, donc on y retourne demain avec les idées claires.
Sinon, je vous recommande vraiment le parcours #Pre-Security sur TryHackMe #surtout les #Devs.
Le repos fait aussi partie du challenge 😅 a demain pour la pratique
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #TryHackMe #DeveloperLife
Day 14 of #100DaysOfCyber 🔐
I said I’d finish learning networking in 1 month😭😭😂
It’s so difficult to learn a new skill while still in school and also have other extracurricular activities
2 months later and I’m still a newbie 1.0😂
Day #35 of #100DaysOfCyber | Lab Pratique : #Exploitation d'un Mass Assignment
Hier, on a vu la théorie. Aujourd'hui, on passe à la pratique avec un lab PortSwigger sur le Mass Assignment.
Le but est d'acheter un article à 1337 $ alors que le crédit de notre compte est à 0.00$ .
Quand on clique sur "Place order", le serveur bloque logiquement la validation et affiche l'erreur "Not enough store credit for this purchase".
#Le processus technique étape par étape :
#Analyse de la structure de l'API : En analysant l'historique HTTP sur Burp Suite , on trouve une requête GET /api/checkout.
Le serveur renvoie un payload JSON qui décrit toute la structure de la commande.
On y voit un objet "chosen_discount" avec un "percentage" initialisé à 0.
#Test d'écriture (Mass Assignment) : On bascule la requête de validation du panier dans le Repeater, on injecte manuellement le bloc de la réduction directement dans notre payload en changeant la valeur à 100 :
"chosen_discount":{ "percentage":100 },
#Résultat de l'envoi : Le serveur traite la requête, accepte le champ injecté sans vérifier si notre rôle utilisateur a le droit de s'octroyer une réduction.
#L'API valide la commande pour 0 $ et renvoie un statut 201 Created avec la redirection de confirmation .
#Ce qu'il faut retenir côté Dev :
L'application a fait un auto-binding brut du JSON utilisateur directement dans l'objet de commande interne.
Pour corriger ça, il ne faut jamais traiter les requêtes entrantes sans filtre. La solution est d'utiliser un schéma de validation strict (DTO) qui définit uniquement les champs modifiables par le client (comme product_id et quantity) et ignore ou rejette automatiquement tout le reste .
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #APISecurity #PortSwigger #MassAssignment #Pentest
@_makh0u
Day 13 of #100DaysOfCyber 🔐
Every message you send passes through 7 layers before it reaches anyone.
Most people in tech can’t name them.
Can you? 🧵
Day #34 of #100DaysOfCyber | Sécurité Dev : API6:2019 - Mass Assignment
Pour faire simple et rester cohérent avec ce qu'on a vu :
#Côté Lecture de données, on avait parlé d'#Excessive Data Exposure (le backend renvoie trop d'infos).
#Côté Écriture, on parle de #Mass Assignment (le backend accepte trop d'infos).
Cette faille vient directement de la flexibilité des frameworks modernes, qui lient automatiquement les entrées JSON du client aux objets de la base de données.
#1. Le problème en Écriture
Une API expose par nature la structure de tes données et le nom de tes attributs. Si un dev fait une mise à jour globale sans filtrer, un attaquant peut intercepter la requête et simplement rajouter un champ sensible dans son payload JSON (ex: "is_admin": true ou "role": "admin").
Si le framework prend le payload et écrase l'objet en base de données sans broncher, c'est l'élévation de privilèges immédiate.
#2. Comment bloquer ça côté Dev ?
➖ Bannir l'auto-binding brut : Ne jamais passer un dictionnaire de requête utilisateur directement à ton ORM.
➖ White-listing strict : Utiliser des schémas de validation (comme les Serializers en Django) pour définir explicitement et uniquement les champs que l'utilisateur a le droit de modifier en écriture.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #APISecurity #OWASP #MassAssignment #Backend #FullStack
Day 12 of #100DaysOfCyber 🔐
Quick question….
What’s the difference between your router and your modem?
90% of people living with both of them can’t answer this. 👇
Last Seen Hashtags on Sotwe
贞操锁
Seen from United States
prankojol
Seen from Indonesia
MomSon filter:native_video
Seen from Singapore
NoLimit
Seen from United States
ทาสถุงเท้า
Seen from Thailand
PublicSex
Seen from India
nOLimit()filter:native_video
Seen from Algeria
TeamOM
Seen from France
alphamaster
Seen from United States
兵哥哥
Seen from United States
Trends for you
Most Popular Users
Elon Musk 
@elonmusk
240.7M followers
Barack Obama
@barackobama
119.2M followers
Donald J. Trump
@realdonaldtrump
111.7M followers
Cristiano Ronaldo
@cristiano
110.7M followers
Narendra Modi
@narendramodi
107M followers
Rihanna
@rihanna
97.7M followers
NASA
@nasa
92.2M followers
Justin Bieber
@justinbieber
90.9M followers
KATY PERRY
@katyperry
87.7M followers
Taylor Swift
@taylorswift13
81.6M followers
Lady Gaga
@ladygaga
73.1M followers
Virat Kohli
@imvkohli
70M followers
Kim Kardashian
@kimkardashian
69.8M followers
YouTube
@youtube
68.7M followers
Bill Gates
@billgates
63.9M followers
Neymar Jr
@neymarjr
62.8M followers
The Ellen Show
@theellenshow
62.4M followers
CNN
@cnn
61.9M followers
X
@x
60.8M followers
Selena Gomez
@selenagomez
60.8M followers