CISSP · Réussir du premier coup

Chapitre 23
Sécurité applicative
et code sécurisé

Domaine 8, dernière partie : évaluer le logiciel acquis, coder en sécurité (OWASP), et les fondamentaux des bases de données.

Domaine
8 — Software Development Security · 10 %
Objectifs couverts
8.3 · 8.4 · 8.5 + BDD
Entraînement
25 questions + corrigé raisonné
L'essentiel en 60 secondes
  • Logiciel acquis (COTS, open source, SaaS) : due diligence, licences, dépendances, escrow de code source.
  • Injection SQL → requêtes paramétrées / procédures stockées + validation d'entrée (allow-list).
  • XSS → output encoding + CSP ; CSRF → tokens anti-CSRF.
  • Buffer overflow → langages memory-safe, canaries, ASLR/DEP (chapitre 6).
  • TOCTOU = race condition entre la vérification et l'usage.
  • Canaux cachés : timing (temps) vs storage (stockage).
  • Validation d'entrée en allow-list (ce qui est permis), pas deny-list ; encoder les sorties.
  • BDD : ACID (Atomicity, Consistency, Isolation, Durability) par cœur.
  • Cardinality = nombre de lignes ; degree = nombre de colonnes.
  • Inference/aggregation/polyinstantiation (rappel chapitre 7) ; les views contrôlent l'accès.

Objectifs 8.3–8.4Efficacité et logiciel acquis

Évaluer l'efficacité de la sécurité logicielle (8.3) : auditer et journaliser les changements, analyser et mitiger les risques, appliquer la logique certification/accreditation au logiciel (chapitre 6).

Logiciel acquis (8.4) — on ne développe pas tout, et l'externe apporte ses risques :

SourceRisquesContrôles
COTS (commercial)Boîte noire, dépendance éditeurDue diligence, patching, code escrow (récupérer le source si l'éditeur disparaît)
Open sourceLicences, dépendances vulnérables (Log4j)Revue de licence, SCA, SBOM (chapitre 3)
Third-party / managed (SaaS)Contrôle limité, données chez le tiersContrats, SLA, SOC 2 Type II (chapitre 17), responsabilité partagée (chapitre 6)

Objectif 8.5OWASP et les faiblesses du code

L'OWASP Top 10 recense les risques web les plus critiques ; le CWE Top 25 les faiblesses logicielles. Les grandes familles à maîtriser :

FaiblesseMécanismeContre-mesure
Injection (SQLi)Injecter du code dans une requête (union, blind, inference)Requêtes paramétrées / procédures stockées, validation d'entrée, échappement
XSSInjecter du script exécuté chez la victime (reflected, stored, DOM)Output encoding, CSP, validation
CSRFForcer une action à l'insu de l'utilisateur authentifiéTokens anti-CSRF, SameSite cookies
Buffer overflowDéborder un tampon pour exécuter du code (stack/heap)Langages memory-safe, canaries, ASLR/DEP (chapitre 6)
Directory traversalRemonter l'arborescence (../) pour lire des fichiersValidation des chemins, canonicalisation
TOCTOU / race conditionExploiter l'écart entre la vérification (check) et l'usage (use)Verrous atomiques, opérations transactionnelles
Insecure deserializationObjets sérialisés malveillantsÉviter la désérialisation de données non fiables, signatures
SSRFForcer le serveur à requêter une ressource interneAllow-list des destinations, segmentation
Backdoors / maintenance hooksAccès cachés laissés par les développeursRevue de code, retrait avant production

Canaux cachés (covert channels) : communication illégitime via un moyen non prévu — timing channel (moduler le temps pour transmettre) vs storage channel (utiliser un emplacement de stockage partagé). À distinguer précisément. Attention aussi aux citizen developers et plateformes low-code/no-code : elles démocratisent le développement mais échappent souvent aux contrôles de sécurité.

🧠 Mnémonique — injections

« SQLi → paramètre ; XSS → encode ; CSRF → token. » Trois failles web, trois parades canoniques. Et pour TOCTOU : « Time Of Check ≠ Time Of Use » — la fenêtre entre vérifier et agir.

Objectif 8.5Pratiques de codage sécurisé

Bases de donnéesFondamentaux

Savoir testable à la frontière des domaines 3 et 8 :

🧠 Mnémonique — ACID et cardinality/degree

ACID : Atomicity, Consistency, Isolation, Durability — les quatre garanties d'une transaction fiable. Et : Cardinality = Comptage des lignes · Degree = colonnes (« degree comme le nombre de Domaines/attributs »).

⚠️ Pièges d'examen
  • SQLi → requêtes paramétrées/procédures stockées (pas seulement « filtrer les guillemets »).
  • XSS → output encoding + CSP ; CSRF → tokens. Ne pas confondre XSS (script chez la victime) et CSRF (action forcée).
  • TOCTOU = race condition entre check et use (Time Of Check ≠ Time Of Use).
  • Canal caché : timing (temps) vs storage (stockage) — distinction précise.
  • Input validation en allow-list > deny-list ; error handling sans fuite d'information.
  • Cardinality = lignes ; degree = colonnes. Inversion classique.
  • ACID : les quatre par cœur ; l'Isolation gère la concurrence.
  • Une view est un contrôle d'accès (restreint ce qui est visible).
  • Code escrow protège contre la disparition de l'éditeur COTS.
  • Maintenance hooks / backdoors : à retirer avant la production.
Scénario fil rouge — Awa

Awa boucle la sécurité applicative. Un test révèle une injection SQL dans un vieux module de Berlin : correction par requêtes paramétrées et validation d'entrée en allow-list. Le portail client, vulnérable au XSS stocké, reçoit un output encoding systématique et une CSP ; les formulaires sensibles gagnent des tokens anti-CSRF. Un audit de code déniche un maintenance hook laissé par un développeur — retiré avant la mise en production. Pour la base de paiement, Awa impose des views qui masquent les colonnes sensibles selon le rôle (content-dependent, chapitre 14) et vérifie que les transactions respectent l'ACID. Le progiciel de comptabilité COTS est couvert par un code escrow au cas où l'éditeur disparaîtrait. Enfin, elle encadre les citizen developers du marketing, qui bâtissaient des automatisations low-code hors de tout contrôle — désormais soumises à revue. Le programme de sécurité de la fintech est complet, du risque au code.


Quiz25 questions

Conditions réelles : 30 minutes, une seule passe, réponses notées avant de consulter le corrigé.

Question 1

Which is the MOST effective defense against SQL injection?

  1. Hiding the database version
  2. Parameterized queries (prepared statements) and input validation
  3. Renaming tables
  4. Disabling the firewall
Voir la réponse Réponse : B

Les requêtes paramétrées séparent code et données : l'injection devient impossible. Cacher la version (A) est de la sécurité par l'obscurité.

Question 2

Which defense BEST mitigates cross-site scripting (XSS)?

  1. Output encoding and a Content Security Policy
  2. Longer passwords
  3. Disabling cookies entirely
  4. Degaussing
Voir la réponse Réponse : A

Output encoding + CSP neutralisent le script injecté. Les autres options n'ont aucun effet sur le XSS.

Question 3

Which attack forces an authenticated user's browser to perform an unwanted action?

  1. SQL injection
  2. Cross-site request forgery (CSRF)
  3. Buffer overflow
  4. Phishing
Voir la réponse Réponse : B

Le CSRF force le navigateur authentifié à exécuter une action non voulue. Le XSS injecterait du script — attaque distincte.

Question 4

Which control specifically mitigates CSRF?

  1. Anti-CSRF tokens and SameSite cookies
  2. Output encoding
  3. Parameterized queries
  4. ASLR
Voir la réponse Réponse : A

Tokens anti-CSRF et cookies SameSite empêchent la requête forgée. L'output encoding (B) vise le XSS.

Question 5

Which vulnerability class is prevented by memory-safe languages, canaries, ASLR, and DEP?

  1. SQL injection
  2. Buffer overflow
  3. CSRF
  4. Directory traversal
Voir la réponse Réponse : B

Memory-safe, canaries, ASLR, DEP protègent contre les débordements de tampon (chapitre 6). Sans rapport avec SQLi ou CSRF.

Question 6

A TOCTOU vulnerability exploits what?

  1. A weak password
  2. The gap between the time a resource is checked and the time it is used (a race condition)
  3. An unencrypted disk
  4. A missing firewall rule
Voir la réponse Réponse : B

TOCTOU exploite l'écart entre la vérification et l'usage : une race condition. « Time Of Check ≠ Time Of Use. »

Question 7

Which covert channel transmits information by modulating timing?

  1. Storage channel
  2. Timing channel
  3. Overt channel
  4. Side channel only
Voir la réponse Réponse : B

Le timing channel module le temps pour transmettre ; le storage channel (A) utilise un emplacement partagé.

Question 8

Which input validation strategy is more secure?

  1. Deny-listing known bad input
  2. Allow-listing only expected, well-formed input
  3. Accepting all input
  4. Validating only the length
Voir la réponse Réponse : B

L'allow-list n'accepte que le connu-bon : plus sûr que la deny-list, qui tente d'énumérer l'infini du mauvais.

Question 9

Why should error messages shown to users be generic?

  1. To save bandwidth
  2. Detailed errors can reveal internal structure to attackers; details belong in logs
  3. Users prefer short messages
  4. It is required by ACID
Voir la réponse Réponse : B

Un message d'erreur bavard révèle la structure interne à l'attaquant : détails dans les logs, message générique à l'utilisateur (fail securely, chapitre 6).

Question 10

What protects an organization if a COTS vendor goes out of business?

  1. A source code escrow agreement
  2. A firewall
  3. A honeypot
  4. A VPN
Voir la réponse Réponse : A

Le code escrow confie le source à un tiers, récupérable si l'éditeur disparaît. Les autres options ne protègent pas de ce risque.

Question 11

Which risk is MOST associated with open-source dependencies?

  1. Physical theft
  2. Inherited vulnerabilities and license obligations
  3. Excessive electricity use
  4. Slow compilation
Voir la réponse Réponse : B

L'open source hérite ses vulnérabilités (Log4j) et impose des obligations de licence → SCA + revue de licence.

Question 12

A hidden access method left in code by a developer is called what?

  1. A backdoor / maintenance hook
  2. A primary key
  3. A canary
  4. A view
Voir la réponse Réponse : A

Un accès caché laissé dans le code = backdoor / maintenance hook, à retirer avant la production.

Question 13

In relational database terms, what is cardinality?

  1. The number of columns
  2. The number of rows (tuples)
  3. The number of tables
  4. The number of primary keys
Voir la réponse Réponse : B

Cardinality = nombre de lignes (tuples). Le nombre de colonnes (A) est le degree — inversion classique.

Question 14

What is the degree of a relation?

  1. The number of rows
  2. The number of columns (attributes)
  3. The number of foreign keys
  4. The number of transactions
Voir la réponse Réponse : B

Le degree = nombre de colonnes (attributs). Les lignes (A) donnent la cardinality.

Question 15

What do the letters ACID stand for?

  1. Access, Control, Integrity, Defense
  2. Atomicity, Consistency, Isolation, Durability
  3. Availability, Confidentiality, Integrity, Data
  4. Authentication, Config, Identity, Directory
Voir la réponse Réponse : B

ACID = Atomicity, Consistency, Isolation, Durability — les garanties d'une transaction fiable.

Question 16

Which ACID property ensures a transaction is all-or-nothing?

  1. Consistency
  2. Atomicity
  3. Isolation
  4. Durability
Voir la réponse Réponse : B

L'atomicity garantit le tout ou rien. La durability (D) assure la persistance après validation.

Question 17

Which ACID property ensures concurrent transactions do not interfere?

  1. Atomicity
  2. Isolation
  3. Durability
  4. Consistency
Voir la réponse Réponse : B

L'isolation empêche les transactions concurrentes d'interférer (via les verrous). L'atomicity (A) gère le tout ou rien.

Question 18

How can a database view improve security?

  1. By encrypting the whole disk
  2. By restricting which columns and rows a user can see
  3. By speeding up queries only
  4. By deleting old records
Voir la réponse Réponse : B

Une view restreint colonnes et lignes visibles : un contrôle d'accès content-dependent (chapitre 14). Elle ne chiffre pas le disque (A).

Question 19

Which key enforces referential integrity by referencing another table's primary key?

  1. Foreign key
  2. Candidate key
  3. Composite index
  4. Surrogate token
Voir la réponse Réponse : A

La foreign key référence la primary key d'une autre table, assurant l'intégrité référentielle. La candidate key (B) est candidate à être primaire.

Question 20

An attacker manipulates input like "../../etc/passwd" to read files outside the intended directory. Which attack is this?

  1. Directory traversal
  2. SQL injection
  3. CSRF
  4. Buffer overflow
Voir la réponse Réponse : A

Remonter l'arborescence avec « ../ » = directory traversal. Parade : validation et canonicalisation des chemins.

Question 21

Which attack forces a server to make requests to internal resources on the attacker's behalf?

  1. Server-side request forgery (SSRF)
  2. Cross-site scripting
  3. Aggregation
  4. Phishing
Voir la réponse Réponse : A

Le SSRF force le serveur à requêter des ressources internes. Le XSS (B) vise le navigateur de la victime.

Question 22

What is a PRIMARY security concern with citizen developers using low-code/no-code platforms?

  1. They write too much documentation
  2. Applications may bypass standard security controls and review
  3. They compile too slowly
  4. They cannot access data
Voir la réponse Réponse : B

Le low-code démocratise le développement mais échappe souvent aux contrôles et à la revue de sécurité — d'où le besoin de gouvernance.

Question 23

Where should secrets such as API keys be stored?

  1. Hard-coded in the source
  2. In a secure vault or protected variables, never in code
  3. In a public repository
  4. In error messages
Voir la réponse Réponse : B

Les secrets vont dans un coffre ou des variables protégées, jamais en dur (secrets scanning, chapitre 22). Les coder (A) ou les exposer (C) est une faute.

Question 24

Which system uses a knowledge base and an inference engine to emulate expert decision-making?

  1. An expert system
  2. A load balancer
  3. A honeypot
  4. A view
Voir la réponse Réponse : A

Un expert system combine base de connaissances et moteur d'inférence pour imiter la décision d'un expert. Les autres options n'ont rien d'inférentiel.

Question 25

Deducing restricted information from authorized queries is which database attack?

  1. Aggregation
  2. Inference
  3. Injection
  4. Traversal
Voir la réponse Réponse : B

Déduire l'interdit à partir de requêtes autorisées = inference (chapitre 7). L'aggregation (A) additionne des faits anodins.

Auto-diagnostic

≥ 20/25 : félicitations, vous avez terminé les 8 domaines ! Place à la révision transverse (chapitre 24) et aux examens blancs. Entre 15 et 19 : récitez OWASP et ACID. < 15 : relisez le chapitre avant d'attaquer les blancs.

FicheFiche de révision

À savoir par cœur avant le chapitre 24
  1. Logiciel acquis : COTS (code escrow), open source (SCA, licences), SaaS (SOC 2 Type II, responsabilité partagée).
  2. SQLi → requêtes paramétrées/procédures stockées + validation ; XSS → output encoding + CSP ; CSRF → tokens.
  3. Buffer overflow → memory-safe, canaries, ASLR/DEP ; directory traversal → validation des chemins.
  4. TOCTOU = race condition (check ≠ use) ; insecure deserialization ; SSRF → allow-list des destinations.
  5. Backdoors/maintenance hooks → retirer avant production ; canaux cachés : timing vs storage.
  6. Codage sûr : input validation allow-list, output encoding, error handling sans fuite, secrets au coffre.
  7. Citizen developers/low-code → gouvernance et revue.
  8. BDD : cardinality = lignes, degree = colonnes ; primary/foreign/candidate keys.
  9. ACID : Atomicity (tout ou rien) · Consistency · Isolation (concurrence) · Durability (persistance).
  10. Views = contrôle d'accès ; ODBC/NoSQL ; data warehouse/mining ; inference/aggregation/polyinstantiation ; expert systems (base + moteur d'inférence).