# security-tools

Suite d'outils de **tests d'intrusion** (pentest) pour l'environnement
de **préproduction Yavsc** (`pschneider.fr`). Outils en **Bash + curl**,
modulaires (un outil par sous-dossier).

> ⚠️ **Autorisation uniquement sur la preprod Yavsc, propriété de
> Paul Schneider.** Aucun outil de ce dépôt ne doit être exécuté
> contre un tiers. Voir [`docs/scope.md`](docs/scope.md).

## Périmètre

La preprod Yavsc est multi-hôtes :

| Hôte        | Domaine                          | Rôle                         |
|-------------|----------------------------------|------------------------------|
| `Yavsc.Org` | `preprod-yavsc.pschneider.fr`     | MVC + IdentityServer (auth)  |
| `Yavsc.Api` | `preprod-api.pschneider.fr`      | API business (JSON)          |
| `Yavsc.Blogs` | `preprod-blogs.pschneider.fr`  | Blogs + stockage perso       |

Les outils restreignent leurs requêtes à ce périmètre via
`assert_in_scope` (`lib/common.sh`) ; toute dérive vers un autre hôte
est refusée.

## Structure

```
security-tools/
├── README.md                # ce fichier
├── targets.example.env      # modèle de configuration (à copier)
├── targets.env              # VOTRE config (ignoré par git, à créer)
├── .gitignore
├── lib/
│   └── common.sh            # bibliothèque partagée (scope, http, logs)
├── docs/
│   └── scope.md             # périmètre & autorisation
├── wordlists/               # vos wordlists (ignoré par git)
├── output/                  # journaux & résultats (ignoré par git)
└── tools/
    ├── brute-login/         # bruteforce auth (password spray / énumération)
    ├── api-fuzzer/          # cartographie d'endpoints & verbes
    ├── config-scan/         # fichiers de config exposés
    └── rate-limit-probe/    # mesure du rate-limiting / lockout
```

## Préparation

1. `cp targets.example.env targets.env`
2. Renseignez dans `targets.env` :
   - `TARGET_SCOPE_ACK="yes"` (confirmation d'autorisation) ;
   - `TARGET_BASE_URL` et `TARGET_ALLOWED_HOSTS` (pré-remplis pour la
     preprod Yavsc) ;
   - pour brute-login : `LOGIN_PATH`, `LOGIN_USERNAME`,
     `LOGIN_WORDLIST`, `LOGIN_CONTENT_TYPE` ;
   - placez votre wordlist dans `wordlists/passwords.txt`.
3. `chmod +x tools/*/*.sh`

## Outils

### brute-login
Teste la robustesse de l'authentification par énumération de mots de
passe sur un utilisateur connu. Supporte JSON (API) et form-urlencoded
(OAuth2 `/connect/token` d'IdentityServer). Voir
[`tools/brute-login/README.md`](tools/brute-login/README.md).

### api-fuzzer
Cartographie les endpoints et verbes autorisés sur les trois hôtes.
Voir [`tools/api-fuzzer/README.md`](tools/api-fuzzer/README.md).

### config-scan
Détecte les fichiers de configuration / surfaces sensibles exposés
(`.git`, `.env`, `appsettings.json`, `swagger`…). Voir
[`tools/config-scan/README.md`](tools/config-scan/README.md).

### rate-limit-probe
Mesure la présence et le seuil d'un rate-limiting / lockout sur
l'endpoint d'auth. Voir
[`tools/rate-limit-probe/README.md`](tools/rate-limit-probe/README.md).

## Précautions

- **Pacing** : `REQUEST_DELAY` (défaut 0.2 s) espace les requêtes. Un
  bruteforce n'a pas besoin d'être un déni de service.
- **Secrets** : `targets.env`, `wordlists/`, `output/` ne sont jamais
  committés (`.gitignore`).
- **Verdict** : ces outils révèlent des faiblesses réelles — corrigez
  ce qu'ils trouvent sur la preprod avant la mise en production.

## Ajouter un outil

1. Créez `tools/<nom>/` avec un script `.sh` + un `README.md`.
2. Sourcez `lib/common.sh` puis appelez `load_target`.
3. Utilisez `http_probe` (qui appelle `assert_in_scope`) pour toute
   requête — jamais de `curl` direct hors périmètre.
4. Conservez le nommage des scripts/chemins en **anglais**, la
   documentation en **français**.