Mahmoud BARRY ( Docteur JS👨‍💻)

Developpeur Web | #JavaScript | #python #django #django_rest_framework #backend | cyber securié | Soninké | #SenMov #Phantom #MMA_SENEGAL #SAMADO 😇

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

des projets javascript à me proposer pour les 28 jours?
#100DaysOfJs #100DaysOfCode #javascript #JS221 #javascript221 #programming #DocteurJS

[Ousseynou DIOP @xarala221]

@Sultane221 félicitations 🎊
Continue comme ça.
Il était parmi les #CoronaCoders

#xarala #kebetu #diangueDev #diangueDesign #100DaysOfCode

CC : @eliaswalyba @ibrahima92_

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

@Rahmatulah01 mom rek ladone deglou temps boy ba sama benen Tourondo bi niew😂 Mahmoud Khalil Hussary

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #17 of #100DaysOfCyber : Les pièges du stockage des uploads en local
Quand on développe une application, le réflexe le plus simple est de créer un dossier /uploads public à la racine de son projet et d'y enregistrer les fichiers des utilisateurs tels quels.
Sans une architecture stricte, c'est une bombe à retardement pour votre infrastructure.
Les 3 vrais risques du stockage local non sécurisé
- La Remote Code Execution (RCE) :
Si votre dossier est public et que votre environnement exécute les scripts à la volée (le cas des serveurs configurés pour le PHP), un attaquant qui y dépose un webshell peut l'exécuter directement en tapant son URL et prendre le contrôle du serveur.
- L'écrasement de fichiers (Path Traversal en écriture) :
Si vous conservez le nom d'origine fourni par l'utilisateur sans le nettoyer, un attaquant peut manipuler le chemin (ex: ../../config.js) pour forcer votre code à écraser des fichiers critiques de votre propre application lors de l'enregistrement.
- Le déni de service (DoS par saturation) :
Sans restriction stricte, un utilisateur peut uploader des fichiers massifs en boucle pour saturer l'espace disque de votre machine. Résultat : le système d'exploitation et la base de données plantent, rendant votre service totalement indisponible.
Les bonnes pratiques pour coder proprement
Le problème n'est pas le stockage local en soi, mais la manière dont il est pensé. Pour sécuriser vos uploads :
- Modifiez le nom : Générez systématiquement un UUID unique à l'arrivée du fichier.
- Isolez le dossier : Placez-le en dehors du répertoire racine de l'application (Web Root) et désactivez-y strictement toute exécution de scripts.
- Limitez les ressources : Mettez en place un rate-limiting et une validation stricte de la taille maximale des fichiers.
Déléguer le stockage à un cloud externe (comme AWS S3 ou Supabase...) reste une excellente option pour scaler.
#Un dev qu comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u
#Cybersecurity #WebSecurity #DevSecOps #Backend #FullStack

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #16 of #100DaysOfCyber | Concept du jour : Contourner la validation du Content-Type
Hier, on a vu le cas où un serveur n'avait aucune sécurité. Dans la vraie vie, les développeurs mettent des protections.
Aujourd'hui, on voit comment contourner un filtre basé sur le Content-Type.
Comment fonctionne ce filtre ?
Quand tu uploades une image, ton navigateur envoie une requête HTTP contenant une ligne appelée Content-Type. Par exemple : Content-Type: image/jpeg.
L'erreur classique en dev, c'est de lire cette ligne côté Backend et de lui faire aveuglément confiance. Si le serveur voit image/jpeg, il valide l'upload sans vérifier le contenu réel.
Comme cette ligne est générée par le navigateur, un attaquant peut la modifier en deux secondes.
L'attaquant envoie son script exploit.php. Le navigateur génère automatiquement : Content-Type: application/x-php.
Le serveur bloque la requête.
L'attaquant intercepte la requête avec Burp Suite et remplace manuellement la ligne par : Content-Type: image/jpeg.
Le Backend est trompé : il croit recevoir une photo et accepte le fichier. Le script PHP est enregistré sur le serveur.
Le Content-Type est une donnée utilisateur modifiable. On ne doit jamais lui faire confiance pour valider la sécurité d'un fichier. La seule vraie solution reste l'analyse des fichiers côté Backend.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.

@PamIbrahimaBaba @_makh0u @MDLD_

#Cybersecurity #WebSecurity #FileUpload #Bypass #BurpSuite #Backend #FullStack

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

@Rahmatulah01 toukhoul niew si deukeu bou nekh bi

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #15 of #100DaysOfCyber | Lab : Exécution de code à distance via upload de Web Shell
Après la théorie, place à la pratique.
L'objectif était clair : exploiter une fonctionnalité d'upload d'avatar vulnérable pour uploader un fichier PHP malveillant et lire un fichier secret sur le serveur (/home/carlos/secret).
Le déroulement de l'attaque
- Création du Web Shell : J'ai codé un script PHP minimaliste nommé exploit.php contenant une seule ligne pour exécuter une fonction système et lire le fichier ciblé : <?php echo file_get_contents('/home/carlos/secret'); ?>.
- L'upload sans restriction : L'application ne réalisant aucune vérification sur la nature ou l'extension du fichier côté backend, le script a été accepté et stocké directement dans le dossier public des avatars.
L'exécution de code (RCE) : En interceptant la requête avec Burp Suite et en appelant directement l'URL de mon script (/files/avatars/exploit.php), le serveur web Apache a interprété le code PHP.
- Résultat : Le serveur m'a renvoyé directement le contenu du fichier secret dans la réponse HTTP.
Ce qu'il faut retenir
C'est le cas d'école parfait qui montre pourquoi un backend ne doit jamais stocker un fichier utilisateur sous son nom d'origine dans un répertoire où l'exécution de scripts est autorisée. Sans isolation ou modification des droits du dossier, c'est la prise de contrôle immédiate du serveur.
Les devs, vous avez déjà audité vos dossiers d'upload pour vérifier si l'exécution de scripts y est bien désactivée ?
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u @guissehMaabo

#Cybersecurity #WebSecurity #PortSwigger #FileUpload #RCE #BurpSuite #PHP #Backend

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #14 of #100DaysOfCyber | SAKR : #Smart Recon
J'ai travaillé sur la v1 du module Smart Recon.
Avant, je perdais beaucoup de temps pour réussir à regrouper toutes ces informations. Avec SAKR, j'ai tout centralisé en un seul clic autour de 3 étapes simples :
- Trouver : L'application récupère les sous-domaines de manière passive, sans toucher à la cible, en passant par des outils existants comme https://t.co/d6wAo6ExfM.
- Vérifier : Elle teste si les serveurs répondent, identifie le cloud provider et récupère les codes status de chaque page.
- Trier : Plus besoin de chercher, on obtient le résultat directement dans un tableau propre et on sait exactement par où commencer .
En quelques secondes, la cartographie est prête.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.

@PamIbrahimaBaba @_makh0u

#Cybersecurity #WebSecurity #SAKR #Reconnaissance #SmartRecon

[bamba bathily @2b_622_b]

Les pirates adorent quand vous :

1️⃣ utilisez le même mot de passe partout
2️⃣ cliquez sur des liens d’e-mails sans vérifier
3️⃣ ignorez les mises à jour de vos appareils
4️⃣ vous connectez à un Wi-Fi gratuit sans protection

Évitez ces erreurs, protégez vos données 🔐

#Cyber221

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #13 of #100DaysOfCyber | Concept du jour : Les failles d'upload de fichiers
On parle d'une fonctionnalité classique : permettre à un utilisateur d'uploader un fichier (photo de profil, CV, facture...). C'est super pratique, mais si c'est mal sécurisé, un attaquant peut prendre le contrôle total de ton serveur.
Comment elle apparaît ?La faille arrive quand le serveur fait aveuglément confiance à l'extension du fichier (.jpg, .png) ou au type envoyé par le navigateur, sans vérifier son contenu réel. L'erreur classique en dev, c'est de se dire : "C'est bon, sur mon Front j'ai mis accept=".jpg,.png", le user ne peut envoyer que des images." Le problème est là : le backend valide l'emballage, mais jamais le produit.
Le piègeLe Front-End ne sécurise rien. Un attaquant intercepte la requête avec Burp Suite et remplace son fichier avatar.jpg par un script malveillant shell.php. Si le backend valide uniquement l'extension déclarée par le navigateur sans analyser le contenu réel du fichier, l'attaquant peut uploader un fichier exécutable.
Il appelle ensuite l'URL du fichier directement dans son navigateur.
Le serveur va exécuter le script. C'est la RCE (Remote Code Execution) : l'attaquant a maintenant un accès direct à ta machine et à ta base de données.

@PamIbrahimaBaba @_makh0u @guissehMaabo
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
#Cybersecurity #WebSecurity #FileUpload #Backend #FullStack

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #12 of #100DaysOfCyber | SAKR se dote d'un Port Scanner.
Après le module d’analyse de JS Bundles, je vous présente une brique fondamentale de la phase de reconnaissance : le Port Scanner.

Le but ? Cartographier une cible en un clic pour identifier tous ses services réseaux exposés, directement depuis mon interface graphique, sans avoir à taper de commandes complexes.

Les fonctionnalités que j'ai implémentées :
-Sélection intelligente des ports : Possibilité de scanner le Top 100 des ports les plus courants pour aller très vite, ou une plage customisée.

- Flexibilité des protocoles : Support du scan TCP, UDP, ou des deux simultanément.

- Option Banner Grabbing : En activant ce switch, l'outil ne se contente pas de dire si un port est ouvert. Il va interroger le port pour récupérer identifier la version précise du service qui tourne (ex: la version exacte d'Apache).
En tant que pentester, c'est cette colonne "Version" qui est cruciale : c'est elle qui me permet de chercher s'il existe des #CVE (vulnérabilités connues) ou des exploits publics sur les versions détectées. Et bien sûr, le bouton "Analyser avec l'IA" est toujours là pour interpréter directement les risques de ces services !

On continue de build, de nouveaux modules arrivent très vite.

#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.

@PamIbrahimaBaba @_makh0u
#Cybersecurity #WebSecurity #SAKR #PortScanner #Reconnaissance #FullStack #Nmap #Infra

[bamba bathily @2b_622_b]

Honoré de faire partie de ce classement mondial des créateurs dans le domaine de la cybersécurité aux côtés de tant de professionnels exceptionnels.
Classement par #favikon
#Cyber221

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #11 of #100DaysOfCyber | Exploitation d'un #SSRF
Avant hier, on a vu la théorie derrière le SSRF (Server-Side Request Forgery). Aujourd'hui, place au lab pratique de PortSwigger pour voir comment ça se passe concrètement dans Burp Suite.
Le scénario : L'application propose une fonctionnalité pour vérifier le stock d'un produit. Pour ce faire, le backend prend un paramètre nommé stockApi contenant une URL, effectue la requête HTTP lui-même, puis renvoie le résultat au client.
C'est le paradis pour un attaquant si l'entrée n'est pas nettoyée.
L'exploitation en 2 étapes :
- Reconnaissance interne (localhost) : En interceptant la requête avec Burp, on modifie la valeur de stockApi pour cibler l'interface locale du serveur : http://localhost/admin.
Le serveur s'exécute, interroge sa propre interface d'administration (normalement inaccessible depuis Internet) et nous renvoie gentiment le code HTML.
On découvre les routes d'administration, notamment celle permettant de supprimer des utilisateurs.
L'attaque (Suppression de compte) : Maintenant qu'on connaît la structure de la route sensible, on pousse le serveur à exécuter l'action destructrice à notre place. Il suffit d'envoyer : stockApi=http://localhost/admin/delete?username=carlos. Le serveur traite la demande en local avec ses propres privilèges d'admin, et le compte de Carlos est supprimé. Lab validé.
#Le serveur fait aveuglément confiance aux requêtes qui viennent de 127.0.0.1 ou localhost, pensant qu'elles viennent forcément d'un admin légitime connecté en interne.
C'est pour ça qu'interdire explicitement les IP privées et valider les URL via une liste blanche stricte côté backend est non négociable.

#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u @guissehMaabo @sudo_su_ @LebzoDev
#Cybersecurity #WebSecurity #SSRF #PortSwigger #Pentest #BurpSuite #Backend #FullStack

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

@_makh0u Tout le résultat est analysé par l'IA sans filtre

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #10 of #100DaysOfCyber | Pas de #lab aujourd'hui, on build #SAKR 🦅
Aujourd'hui, pas de lab, je me suis posé pour améliorer mon propre projet : #SAKR.
C'est un outil All-in-One de pénétration testing et d'automatisation que je développe avec FastAPI et React.
Même s'il existe déjà des outils similaires (souvent payants), je préfère centraliser et coder mes propres workflows selon ma propre méthodologie, sans aucune limite.
L'idée est de regrouper tous les outils que j'utilise (Nmap, Subfinder...) au sein d'une seule interface graphique propre.
Le focus du jour : Le module "#Reconnaissance" J'ai amélioré la fonctionnalité #JS #Bundle #Analysis.
Le principe ? Tu lui donnes simplement l'URL d'un site, et le script va analyser les fichiers JavaScript du Front-End pour en extraire un maximum d'informations :
- Des secrets ou clés d'API mis en hard (hardcoded tokens).
- Des endpoints d'API absolus ou des routes de navigation privées.
En tant que dev, je sais ce que mes pairs ont l'habitude d'oublier ou de laisser traîner dans le code Front. J'adapte donc mes scripts et mes regex au fur et à mesure de mes labs pour ne rien louper.
#L'intégration #IA : J'ai ajouté un bouton permettant d'envoyer instantanément ces résultats bruts à une API connectée à un LLM.
#En un clic, l'IA prend le relais pour analyser les découvertes, évaluer le niveau de risque (ex: Risque 6/10), expliquer comment un attaquant pourrait exploiter ces endpoints cachés et générer les actions recommandées pour s'en protéger.
#Pourquoi créer mes propres outils ?
J'ai toujours voulu developper mes propres outils de sécurité. Pour moi, la condition requise était claire : je devais maîtriser à la fois le réseau et la programmation.
À l'époque, je m'étais même lancé le défi de suivre deux formations en même temps : une école pour le réseau et Bakeli pour la programmation. Finalement, l'ecole de réseau ne m'a pas plu, j'ai arrêté pour me focus à 100% sur le code chez #Bakeli, où j'ai passé des années à franchir différents caps. C'est ce background de dev qui me permet aujourd'hui de construire #SAKR.
Ce n'est que le début, d'autres modules arrivent et je vous partagerai l'évolution ici.
Les passionnés de séc ou devs, vous êtes plutôt team "outils existants clés en main" ou vous aimez aussi scripter vos propres outils maison pour vos besoins spécifiques ?
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u @Mister__iks @sibyog13 @nuuh_404 @sall_99sn @Elkha_D @BirameCMR

#Cybersecurity #WebSecurity #SAKR #FullStack #FastAPI #React #Recon #Bakeli

[AhmadouRassoul @Elkha_D]

Sécurité des applications partie 2

Après avoir mis en place un patch management efficace et des outils de management, comment intégrer des tests sécurité avant déploiement afin de détecter tôt les nouvelles/anciennes vulnérabilités ?

Il y’a 3 piliers dans les tests de sécurité:

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

@promptcraft_26 Yalna aay kom yaw

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Côté Code : Mettre en place une liste blanche (whitelist) stricte des domaines autorisés et interdire explicitement les IP privées (127.0.0.1...)
Côté Infra : @jules_youm Coach pourra faire des posts sur ça 😂
Les devs Vous utilisez quoi pour sécuriser vos webhooks ?

#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.

@PamIbrahimaBaba @_makh0u @alioune_kanoute @tonux_samb @MedteckThiam @Elkha_D @sibyog13

#Cybersecurity #WebSecurity #ConceptDuJour #SSRF #Backend #FullStack #DevOps

Image : @PortSwigger

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #9 of #100DaysOfCyber | Le Concept du Jour : Le #SSRF 🛡️
Hier, lors du Day 8, on a parlé de WAF et de Rate Limiting pour sécuriser notre infrastructure et nos applications. Sauf que les attaquants vont toujours chercher des techniques pour contourner ces barrières. L'une de ces techniques redoutables est le SSRF (Server-Side Request Forgery).

C'est quoi ? Le SSRF est une vulnérabilité qui permet à un attaquant de forcer le serveur de l'application à envoyer des requêtes HTTP ou d'autres protocoles vers des cibles qu'il n'aurait jamais dû atteindre. En gros, on utilise le serveur comme un "rebond" ou un proxy.

Pourquoi c'est #dangereux ? Le serveur web se trouve souvent dans une zone de confiance. Il a accès au réseau local (LAN) de l'entreprise ou à des services cloud internes qui ne sont pas exposés sur Internet. Grâce au SSRF, un attaquant peut :
- Scanner le réseau interne privé de l'infrastructure.
- Accéder à des services locaux qui tournent sur la machine (comme une base de données ou un cache Redis sur localhost).
#Le pire : Lire les clés d'accès et les credentials via les API de métadonnées.
#Comment ça arrive côté code ? Dès qu'un développeur permet à l'utilisateur de fournir une URL que le serveur va devoir aller chercher (par exemple : importer une image de profil via un lien, générer un PDF à partir d'un site, ou faire un webhook), le risque est là si l'URL n'est pas strictement vérifiée.
#L'une des #solutions : En tant que dev, il faut multiplier les couches :

[Mahmoud BARRY ( Docteur JS👨‍💻) @Sultane221]

Day #8 of #100DaysOfCyber #Concept du Jour : Le #Rate #Limiting ⏱

Après avoir testé des attaques par force brute ces derniers jours avec Turbo Intruder, il y a une protection indispensable que chaque développeur doit connaître pour bloquer ce genre d'attaque : le #Rate #Limiting.

C'est quoi ? Le Rate Limiting consiste à limiter le nombre de requêtes qu'un utilisateur (ou une adresse IP) peut effectuer sur une API ou un site web dans un intervalle de temps donné. Par exemple : maximum 5 tentatives de connexion par minute.

Pourquoi c'est vital pour la sécurité des applications ? Sans Rate Limiting, un attaquant peut envoyer des milliers de requêtes par seconde pour :

- Brute-forcer des mots de passe (comme on l'a vu).

- Énumérer des identifiants ou des données.

- Faire tomber le serveur (attaque DoS/DDoS) en surchargeant la base de données.

Comment l'implémenter ? Pour vous protéger, je vous propose deux solutions que vous pouvez dès à présent commencer à mettre en place :

Utiliser un WAF comme Cloudflare. C'est ultra-efficace pour bloquer le trafic suspect avant même qu'il ne touche vos serveurs.

Via le code : En l'implémentant directement dans votre backend . Cela vous permet d'avoir un contrôle plus fin, par exemple en limitant les requêtes par utilisateur connecté et non pas seulement par IP.

Multiplier les couches reste la meilleure approche : un premier filtre sur l'infra, et un contrôle dans le code sur les routes sensibles.
Les devs et DevOps, vous gérez le rate limiting à quel niveau d'habitude ? Plutôt Cloudflare/Nginx ou dans le code ? 👇
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u

#Cybersecurity #WebSecurity #ConceptDuJour #RateLimiting #Backend #FullStack #DevOps