Guide Pentest — ITYLOS

⚙

Outils à installer

⚠

Tous ces tests doivent être effectués depuis un environnement que tu contrôles. N'utilise jamais le réseau du client pour lancer des scans sur ses propres serveurs.

curl

apt install curl

Requêtes HTTP manuelles, headers, cookies

nmap

apt install nmap

Scan de ports et services

nikto

apt install nikto

Scanner de vulnérabilités web

sslyze

pip install sslyze

Audit TLS/SSL complet

ffuf

apt install ffuf

Fuzzing de routes et paramètres

wfuzz

pip install wfuzz

Fuzzing avancé (params, headers)

OWASP ZAP

snap install zaproxy

Proxy d'interception + scanner auto

testssl.sh

git clone testssl.sh

Test TLS en ligne de commande

01

Reconnaissance passive Passif

Collecte d'informations sans interagir directement avec le serveur. Aucun risque de détection.

1

DNS — Enumération des sous-domaines

Découvrir des services cachés ou des environnements de staging exposés

# Enregistrements DNS complets dig itylos.com ANY +noall +answer dig www.itylos.com A dig itylos.com MX dig itylos.com TXT # Recherche de sous-domaines via certificats SSL publics curl -s "https://crt.sh/?q=%.itylos.com&output=json" | \ python3 -c "import json,sys; [print(x['name_value']) for x in json.load(sys.stdin)]" | \ sort -u

✓

Cherche : des sous-domaines comme dev., staging., api., admin. qui pourraient être moins sécurisés.

2

WHOIS & ASN

Identifier l'hébergeur, la localisation, d'autres domaines du même propriétaire

whois itylos.com whois 91.167.111.24 # Remplacer par l'IP réelle de itylos.com

3

Wayback Machine — Historique du site

Retrouver d'anciens fichiers, routes supprimées, infos exposées dans le passé

# Lister toutes les URLs archivées curl -s "https://web.archive.org/cdx/search/cdx?url=itylos.com/*&output=text&fl=original&collapse=urlkey" | sort -u | head -50

💡

Cherche des fichiers comme .env, backup.zip, config.json, ou des routes /admin, /debug dans les résultats.

02

Audit TLS & Headers HTTP Passif

1

Audit TLS complet avec testssl.sh

Protocoles supportés, suites de chiffrement faibles, certificat, BEAST/POODLE/ROBOT...

# Installation git clone --depth 1 https://github.com/drwetter/testssl.sh.git cd testssl.sh # Audit complet — exporter en HTML pour la vidéo ./testssl.sh --htmlfile testssl-itylos.html itylos.com

✓

Cherche : protocoles SSLv3/TLS 1.0/1.1 activés, suites RC4/3DES, certificat auto-signé ou expiré, HSTS absent.

2

Analyse des headers de sécurité

Vérifier tous les headers de protection contre XSS, clickjacking, MIME sniffing...

# Headers complets avec suivi de redirections curl -sI -L https://itylos.com # Tester aussi les sous-pages sensibles curl -sI https://itylos.com/api/ curl -sI https://itylos.com/en/

⚠

Points à vérifier : présence de Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy. Absence = signalement.

03

Découverte de routes & fichiers Actif

Fuzzing des chemins pour découvrir des endpoints non documentés, pages d'admin, fichiers de config.

1

Fuzzing avec ffuf

Bruteforce de répertoires avec une wordlist standard

# Télécharger une wordlist commune wget https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/common.txt # Lancer le fuzzing (limiter le rate pour ne pas surcharger) ffuf -w common.txt -u https://itylos.com/FUZZ \ -rate 50 \ -fc 404 \ -o ffuf-itylos.html -of html

💡

Codes HTTP intéressants : 200 = accessible · 301/302 = redirection vers autre chose · 403 = existe mais protégé · 500 = erreur serveur révélatrice

2

Fichiers sensibles courants

Vérifier manuellement les fichiers souvent oubliés

# Liste des fichiers à tester manuellement for path in .env .git/config robots.txt sitemap.xml \ backup.zip backup.sql admin/ login/ api/v1/ \ package.json composer.json .htaccess wp-admin/; do code=$(curl -s -o /dev/null -w "%{http_code}" https://itylos.com/$path) echo "$code https://itylos.com/$path" done

04

Scan automatique de vulnérabilités Actif

1

Nikto — Scanner web généraliste

Détecte des milliers de problèmes connus : fichiers dangereux, versions vulnérables, mauvaises configs

# Scan complet avec export HTML nikto -h https://itylos.com \ -o nikto-itylos.html \ -Format htm \ -maxtime 300

2

OWASP ZAP — Scan actif complet

Proxy d'interception + spider automatique + détection XSS/injection/etc.

# Mode daemon headless (idéal pour vidéo en CLI) zaproxy -daemon -port 8090 -config api.disablekey=true & # Spider — exploration automatique du site curl "http://localhost:8090/JSON/spider/action/scan/?url=https://itylos.com" # Attendre la fin du spider curl "http://localhost:8090/JSON/spider/view/status/" # Lancer le scan actif curl "http://localhost:8090/JSON/ascan/action/scan/?url=https://itylos.com" # Générer le rapport HTML curl "http://localhost:8090/OTHER/core/other/htmlreport/" > zap-itylos.html

🛠

Pour la vidéo : ZAP a aussi une interface graphique. Lance zaproxy sans -daemon pour avoir l'UI complète à l'écran.

3

Nmap — Scan de ports & services

Vérifier quels ports sont ouverts et quels services tournent

# Scan des ports les plus communs avec détection de version nmap -sV -sC --open -p 80,443,8080,8443,3000,22,21,25 itylos.com # Scan complet (plus lent) nmap -sV -A -p- itylos.com

⚠

Cherche : des ports ouverts inattendus (3000, 8080, 27017 MongoDB, 6379 Redis). Chaque port ouvert est une surface d'attaque potentielle.

05

XSS & Injection Actif

Tester tous les champs de saisie, paramètres URL et headers acceptant des données utilisateur.

1

XSS — Cross-Site Scripting

Injecter du JavaScript dans les champs pour tester le filtrage

# Payloads de base à tester dans tous les champs <script>alert(1)</script> <img src=x onerror=alert(1)> "><script>alert(document.domain)</script> javascript:alert(1) <svg onload=alert(1)> # Via curl — tester les paramètres GET curl -s "https://itylos.com/?q=<script>alert(1)</script>" | grep -i "script"

💡

Utilise les DevTools du navigateur (F12 → Console) pendant les tests manuels. Si alert(1) s'exécute = XSS confirmé.

2

Injection dans les paramètres API

Identifier les endpoints API et tester les entrées

# Repérer les appels API via les DevTools (onglet Network) # Puis reproduire avec curl en modifiant les paramètres # Exemple — tester une injection dans un champ JSON curl -X POST https://itylos.com/api/secret \ -H "Content-Type: application/json" \ -d '{"content": "<script>alert(1)</script>", "ttl": 3600}' # Tester les limites — TTL négatif, chaîne vide, valeur null curl -X POST https://itylos.com/api/secret \ -H "Content-Type: application/json" \ -d '{"content": "test", "ttl": -1}'

06

CSRF & Logique métier Actif

1

CSRF — Cross-Site Request Forgery

Vérifier que les actions sensibles sont protégées par un token CSRF

# 1. Capturer une requête POST légitime via les DevTools # 2. La reproduire depuis un autre origine sans le token curl -X POST https://itylos.com/api/secret \ -H "Origin: https://evil.com" \ -H "Content-Type: application/json" \ -d '{"content": "test csrf", "ttl": 60}' # Si la requête réussit sans token CSRF = vulnérabilité

✓

Pour ITYLOS, le chiffrement côté client réduit l'impact du CSRF, mais une création de secrets depuis un site tiers reste un problème si les cookies de session existent.

2

Logique — Lecture multiple d'un secret

Un secret ITYLOS doit être détruit après lecture. Tester si c'est vraiment le cas.

# 1. Créer un secret sur itylos.com, noter l'URL # 2. Ouvrir l'URL une première fois → secret affiché # 3. Ouvrir l'URL une deuxième fois → doit retourner une erreur # Test via curl — extraire l'ID du secret depuis l'URL SECRET_URL="https://itylos.com/s/VOTRE_ID#VOTRE_CLE" # Première lecture curl -s "$SECRET_URL" # Deuxième lecture — doit échouer ou retourner "expiré" curl -s "$SECRET_URL"

⚠

Si la deuxième lecture fonctionne : la destruction après lecture n'est pas implémentée côté serveur — critique pour un service de secrets éphémères.

3

Logique — Expiration TTL côté serveur

Le TTL est-il vérifié côté serveur ou seulement côté client ?

# Créer un secret avec TTL = 60 secondes # Attendre 90 secondes # Tenter d'accéder au lien — doit retourner "expiré" # Manipuler le TTL dans l'AAD — tenter de déchiffrer avec un TTL différent # Si l'AAD est bien vérifié par AES-GCM, le déchiffrement doit échouer

07

Audit du flux cryptographique Avancé

1

Vérifier que la clé ne transite jamais au serveur

La clé est dans le fragment URL (#) — elle ne doit jamais apparaître dans les logs serveur

# Ouvrir les DevTools → onglet Network # Créer un secret et observer les requêtes # La clé (après le #) ne doit JAMAIS apparaître dans les requêtes HTTP # Vérifier aussi que le fragment n'est pas envoyé via JS (fetch/XHR) # Dans la console DevTools : console.log(window.location.hash) // doit rester local

💡

Le fragment URL (#fragment) n'est techniquement pas envoyé au serveur par le navigateur. Mais un script JS malveillant pourrait le lire et l'exfiltrer — d'où l'importance du CSP et du SRI.

2

Tester la résistance du KDF

Vérifier que le fallback PBKDF2 est bien déclenché quand Argon2 est absent

# Dans la console DevTools du navigateur : # 1. Forcer la désactivation d'Argon2 pour tester le fallback const argon2_backup = window.argon2; window.argon2 = undefined; # 2. Créer un secret avec mot de passe — PBKDF2 doit prendre le relai # 3. Vérifier dans la console le warning "Argon2id indisponible, bascule sur PBKDF2" # 4. Restaurer window.argon2 = argon2_backup;

08

Nonce CSP statique Avancé

Vulnérabilité identifiée dans l'analyse initiale. Si le nonce ne change pas entre les requêtes, la protection CSP est nulle.

1

Confirmer si le nonce est statique

Comparer le nonce sur 5 requêtes successives

# Extraire le nonce des headers sur 5 requêtes for i in 1 2 3 4 5; do curl -sI https://itylos.com | grep -i "content-security-policy" | grep -oP "nonce-[^'\"]*" sleep 1 done # Si tous les nonces sont identiques = VULNÉRABILITÉ CONFIRMÉE

⚠

Impact : Un nonce statique permet à un attaquant qui a injecté du HTML (via une autre faille) d'exécuter du JS en réutilisant le nonce connu.

09

Absence de SRI Avancé

1

Vérifier l'absence d'attributs integrity sur les scripts

Sans SRI, un script modifié côté serveur s'exécuterait sans alerte

# Vérifier si integrity= est présent sur les balises script curl -s https://itylos.com | grep -E "<script" | grep -v "integrity" # Calculer le hash SRI correct pour crypto.js (à transmettre au client) curl -s https://itylos.com/assets/js/crypto.js | \ openssl dgst -sha384 -binary | \ openssl base64 -A | \ xargs -I{} echo "sha384-{}"

✓

Recommandation pour le client : ajouter integrity="sha384-HASH" et crossorigin="anonymous" sur chaque balise <script> et <link> externe.

10

Rapport & livrables Passif

Structure recommandée pour le rapport final à remettre au client :

Résumé exécutif (1 page) — verdict global, nb de vulnérabilités par sévérité
Périmètre testé — domaines, dates, outils utilisés
Findings détaillés — description, preuve (screenshot/vidéo), impact, remédiation
Preuves visuelles — captures d'écran ou extraits vidéo pour chaque finding
Recommandations priorisées — classées par effort/impact
Annexes — sorties brutes nikto, ZAP, testssl.sh

# Génération d'un rapport HTML consolidé depuis les exports mkdir rapport-itylos cp testssl-itylos.html nikto-itylos.html zap-itylos.html ffuf-itylos.html rapport-itylos/ zip -r rapport-itylos-$(date +%Y%m%d).zip rapport-itylos/

🎬

Pour les vidéos : utilise asciinema rec pour enregistrer les tests en terminal, ou OBS Studio pour capturer l'écran avec les outils graphiques (ZAP, navigateur).