INJECTION ISSUES

VALIDATION ET SANITATION DES ENTRÉES

Objectif : Empêcher les attaques par injection (comme XSS ou SQLi).

String email = request . getParameter ( " email " ) ;
if ( email == null || ! email . matches ( " ^[\ w . -]+ @ [\ w. -]+\\.[ A - Za - z ]{2 ,6} $ " ) ) {
[Link]( HttpServletResponse.SC_BAD_REQUEST , " Email invalide " ) ;
return ;
}

// Une méthode pour traiter les caractères spéciaux

public static String escapeHtml ( String input ) {
if ( input == null ) return " " ;
return input . replaceAll ( " & " , " & amp ; " )
<c:out value = "${ user }" / > :
. replaceAll ( " <" , " & lt ; " )
<c:out value = "${ message }" / >
. replaceAll ( " >" , " & gt ; " )
. replaceAll ( " \" " , " & quot ; " )
. replaceAll ( " ’" , " &# x27 ; " );
}
 SÉPARATION DES RESPONSABILITÉS

Objectif : Implémenter la logique d’accès aux données dans une classe dédiée (DAO ou Service).

public class MessageDAO {

public List<Message> getAllMessg(Connection conn) throws SQLException {
List<Message> messages = new ArrayList<>();
String sql = "SELECT * FROM messages";
try (PreparedStatement ps = [Link](sql);
ResultSet rs = [Link]()) {
while ([Link]()) {
[Link]( new Message([Link]("username"), [Link]("message")) );
}
}
return messages;
}
}
 UTILISATION DES PREPAREDSTATEMENT

Objectif : Neutralise les risques d’injection SQL en utilisant les requêtes paramétrées.

String sql="SELECT * FROM messages WHERE username = ? ";

PreparedStatement ps = [Link](sql);
[Link](1, usernameInput);
ResultSet rs = [Link]();
 SÉCURISATION DE LA CONNEXION À LA BD

Objectif : Ne jamais exposer les passwords/identifiants de connexion dans le code source.

# [Link]
[Link]=jdbc:mysql://localhost:3306/testdb
[Link]=root
[Link]=secret

Properties props = new Properties();

[Link](new FileInputStream("[Link]"));
String url = [Link]("[Link]");
//…
 GESTION DES ERREURS

Objectif : Ne jamais afficher les détails des exceptions aux utilisateurs finaux.

try {
// Traitement classique
} catch (Exception e) {
// Log pour serveur
[Link](getClass().getName()).log([Link], null, e);
// Message generique pour l'utilisateur
[Link]("error", "Une erreur s'est produite.");
}
 GESTION SÉCURISÉE DES SESSIONS/COOKIES

Objectif : Protéger les données de session (authentification, autorisation) contre le vol ou

l’usurpation en configurant correctement les cookies de session.

// création d’un cookie avec l’identifiant de session

Cookie jsessionCookie = new Cookie("JSESSIONID", [Link]());
// empêche l’accès au cookie depuis le JavaScript
[Link](true);
// force l’envoi du cookie uniquement via HTTPS
[Link](true);
// ajout du cookie à la réponse HTTP
[Link](jsessionCookie);
 AUTHENTIFICATION ET AUTORISATION

Objectif : Restreindre l’accès aux pages protégées de l’application aux utilisateurs authentifiés.

if([Link]("user") == null) { [Link]("[Link]"); return; }

Il faudrait implémenter un contrôle d’authentification et d’autorisation pour limiter l'accès à la page

aux utilisateurs légitimes.

public class AuthFilter implements Filter {

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException {
HttpSession s = [Link](false);
if (s == null||[Link]("user")==null){ [Link]("[Link]"); }
else { [Link](req, res); }
}
}
 PROTECTION AVANCÉE : MFA ET JWT

Objectif : Renforcer l'authentification et l'autorisation en combinant plusieurs facteurs de sécurité

et des jetons robustes.

MFA (Multi-Factor Authentication) : Implique la vérification de l'identité par au moins deux

méthodes (mot de passe + code reçu par SMS/email, par exemple), ce qui complexifie fortement
les attaques par vol de crédenciales.

JWT (JSON Web Token) : Permet d'authentifier et d'autoriser l’accès aux ressources à l’aide de
jetons signés, envoyés au client.

String jwt = [Link]()

.withClaim("user", username)
.sign(algorithm);
 RÈGLES DE CODAGE SÉCURISÉ API

Objectif : Protéger les APIs contre les abus, valider systématiquement les données reçues, et gérer
correctement les erreurs.

if( [Link](ip) > 100) {

[Link](429, "Trop de requêtes");
return;
}

Rate limiting : Empêche un utilisateur ou un bot d’effectuer trop de requêtes en peu de temps, ce
qui évite les abus ou la saturation du serveur.
 DEVSECOPS ET PIPELINE CI/CD

Objectif : Intégrer la sécurité dans l’automatisation du développement et du déploiement, afin de

détecter les vulnérabilités au plus tôt.

Un pipeline CI/CD (Intégration Continue / Déploiement Continu) automatise la construction,

l'analyse, les tests et la livraison de votre application. DevSecOps ajoute à ce pipeline des contrôles
de sécurité automatisés et des vérifications à chaque étape.
 DEVSECOPS ET PIPELINE CI/CD

• Validation : une modification apportée au code.

• Job : une série d'instructions qu'un Runner doit exécuter.
• Runner : un agent ou serveur qui exécute chaque job individuellement et qui peut se mettre à
l'échelle selon les besoins.
• Étapes : un mot-clé qui définit certaines phases spécifiques d'un job, comme la phase de
compilation et de déploiement. Les jobs d'une même étape s’exécutent en parallèle.
• Les pipelines sont configurés à l'aide d'un fichier YAML nommé .[Link], soumis au
contrôle de version et situé à la racine du projet.
 FONCTIONNEMENT CI
1.Récupération du code : Vérification des nouvelles modifications depuis le dépôt Git.
[Link] et Build : Construction de l’application pour s’assurer qu’elle est fonctionnelle.
[Link]écution des tests :
1. Tests unitaires pour vérifier les fonctionnalités isolées.
2. Tests d’intégration pour s’assurer que les modules fonctionnent ensemble.
3. Tests statiques (linting, analyse de sécurité).
[Link] du code : Vérification des standards de qualité (ex: SonarQube, ESLint, …).
[Link] et feedback : Les résultats sont envoyés aux développeurs (succès ou échec).
 FONCTIONNEMENT CD

[Link] et génération d’un artefact (ex: image Docker, binaire…)

2.Déploiement en environnement de staging
[Link]écution des tests post-déploiement (test d’intégration, tests UI…)
4.Déploiement automatique en production (si tout est valide)
[Link] et rollback (en cas de problème)
 DEVSECOPS

• Analyse des risques, politiques de sécurité, architecture défensive, …

• SAST (Static Application Security Testing) :
o analyse statique du code (ex : SonarQube, Semgrep)
• DAST (Dynamic Application Security Testing) :
o tests dynamiques (ex : OWASP ZAP, Burp Suite)
• SCA (Software Composition Analysis) :
o analyse des dépendances (ex : Snyk, Trivy)
 PIPELINE CI/CD SÉCURISÉE AVEC DEVSECOPS

• GitLab CI/CD permet d’automatiser l'intégration et le déploiement continu.

• GitLab Runner est programme agent qui exécute les jobs d’un pipeline CI/CD dans GitLab
(build, test, déploiement…).
• Les instructions reçues viennent du fichier .[Link] propre au projet GitLab.
• Indispensable pour automatiser intégration, testing et déploiement continu dans un workflow
DevOps.
 INSTALLATION GITLAB RUNNER
[Link]
>sudo apt install sudo curl --output /usr/local/bin/gitlab-runner [Link]
[Link]/gitlab-runner-downloads/latest/binaries/gitlab-runner-darwin-amd64
>sudo chmod +x /usr/local/bin/gitlab-runner
>gitlab-runner install
>gitlab-runner start
>gitlab-runner status
>gitlab-runner register
 SONARQUBE (SAST)

+ Bugs et erreurs logiques

+ Code Smells (odeurs de code)
+ Vulnérabilités de sécurité (SAST)
+ Security Hotspots
+ Qualité Gate
 SONARQUBE (SAST)

docker run -d --name sonarqube -p 9000:9000 sonarqube

SONARQUBE (SAST)
SONARQUBE (SAST)
 SONARQUBE (SAST)
stages:
- build
- test
- sonarqube
build-job:
stage: build
script: "mvn compile"
test-job:
stage: test
script: "mvn test"
sonarqube-check:
stage: sonarqube
image: sonarsource/sonar-scanner-cli:latest
script:
- sonar-scanner -[Link]=$SONAR_PROJECT_KEY -[Link]=$SONAR_URL
-[Link]=$SONAR_TOKEN
SONARQUBE (SAST)
 SONARQUBE (SAST)

➢ git init
➢ git remote add origin [Link]
➢ git add .
➢ git commit -m "Initial commit"
➢ git push -u origin main
SONARQUBE (SAST)
 SONARQUBE (SAST)

+ Bugs et erreurs logiques

+ Code Smells (odeurs de code)
+ Vulnérabilités de sécurité (SAST)
+ Security Hotspots
+ Qualité Gate
 ZAP PROXY (DAST)
➢ docker pull zaproxy/zap-stable

➢ docker run --network="host"

-t --rm -v $(pwd):/zap/wrk zaproxy/zap-stable [Link]
-t [Link]
-r [Link]
 ZAP PROXY (DAST)
stages:
- build
- test
- sonarqube
- dast
# ... (jobs build, test, sonarqube comme précédemment)
dast:
stage: dast
image: owasp/zap2docker-stable
variables: TARGET_URL: "[Link]
script: # Scan baseline sur l'URL cible avec génération d'un rapport HTML
-[Link] -t $TARGET_URL -r [Link]
artifacts:
paths:
- [Link]
reports:
dast:
[Link]