et sortants de l'application. ‣ Le code qui protège ces chemins. ‣ Toutes les données sensibles utilisées dans l'application. ‣ Le code qui protège ces données. ‣ Réduire la surface d'attaque.
et simplifier le code. ‣ Réusiner le legacy. ‣ Supprimer le code mort. ‣ Formulaires moins nombreux, plus simples. ‣ Beaucoup de code = grande surface d'attaque.
‣ Garder les données non fiables séparées des commandes et des requêtes. ‣ Validation par liste blanche. ‣ Utiliser ORM ou ODM. ‣ Requêtes paramétrées (where user_id = ?) ‣ Filtrer les données fournies par l'utilisateur.
jeton donne **** **** **** 0123. ‣ Imprimer partiel sur les reçus. ‣ Afficher partiel aux directeurs de compte. ‣ Même les développeurs ne peuvent pas obtenir le nombre complet.
certificats auto-signés. ‣ Mobile: forcer la vérification de la chaîne SSL. ‣ Éviter les données sensibles sur les canaux non sécurisés (e-mail, SMS, etc.) ‣ Données hautement sensibles: chiffrer même si elles sont envoyées via SSL (Heartbleed).
filtres “raw”. ‣ Ne pas transmettre de données utilisateur directement à JS (ou assainir avant). ‣ Filtrer en fonction du contexte (LDAP, XPATH, etc.) ‣ Utiliser le Content Security Policy.
jetons peut ne pas suffire (jeton plus longs ou combinaisons). ‣ Authentifier les utilisateurs et filtrer les données / actions. ‣ Vérifier les rôles et les privilèges. ‣ Revue de code. ‣ Penser au ACL. ‣ Ajouter à la suite de tests automatisés.
Régénérez l'ID de session lors de la connexion. ‣ Expiration pour le ID de session. ‣ Tout via SSL. ‣ La gestion de session intégrée au framework. ‣ Éviter de stocker des données dans les cookies. ‣ Vérifier le changement / récupération du mot de passe.
monde. ‣ Les victimes n'ont pas mis à jour leurs logiciels. ‣ Les victimes n'ont pas désactivé un protocole de partage de fichiers obsolète SMBv1 (30 ans).
à temps. ‣ Désactive le mode débogage. ‣ Changer les mots de passe par défaut. ‣ Régler les paramètres de sécurité. ‣ Vérification automatique de la configuration. ‣ Architecture sécurisée. ‣ Processus de durcissement continu.
processus. ‣ Zip bomb / zip de la mort: • Zipper un fichier de 1.3 Go contenant que des zéros. • Faire 10 copies, zipper. • Répéter 10 fois. • Zip final de seulement 45.1 Ko. • Décompresse en 1.3 exaoctets (giga > tera > peta > exa). • Brise les scanneurs de virus quand ils l'ouvrent récursivement.
quelle propriété. • Téléverser un root kit. • Envoyer des données ou des fichiers silencieusement à un serveur tiers. • Injecter en permanence des keyloggers dans les vues. • Etc. ‣ Modifier les données sérialisées pour augmenter les privilèges (exemple: cookie utilisateur).
bases de données, en-têtes, etc.). ‣ Autoriser uniquement les types primitifs. ‣ Utiliser des sommes de contrôle (checksum). ‣ Exécuter la désérialisation en utilisant des privilèges faibles. ‣ Restreindre les requêtes réseau (domaines de la liste blanche). ‣ Journaliser les erreurs de désérialisation. ‣ Surveiller pour des désérialisations répétées par un seul utilisateur.
sondage, souvent avec des échecs. ‣ Surveiller pour détecter le sondage: • Devinez ce que l'attaque essayait de réaliser. • Découvrez vos vulnérabilités avant les autres. ‣ Journaliser: • Comprendre l'attaque pour trouver les vulnérabilités qui ont été exploitées. • Peut-être même trouver l'attaquant.
données échouent. ‣ Aucune détection d'attaque par force brute. ‣ Pas de détection de DDoS. ‣ Aucune détection de scan d'URL. ‣ Aucune alerte en cas de pics de processeur. ‣ Aucune alerte en cas d'erreur d'application. ‣ Pas de gestion centralisée des journaux. Exemples
en rotation. ‣ Erreurs ACL: l’utilisateur A a tenté d’accéder à la transaction de l’utilisateur B. ‣ Erreurs 404 et 500: analyses d'URL ou recherche de vulnérabilités d'applications. ‣ Erreurs de validation d'entrée: téléverser un fichier malveillant ou sauvegarder une injection SQL. ‣ Journaliser avec le contexte et conserver pendant une longue période, pour la forensique. ‣ Faites un test pour voir si vos journaux fournissent suffisamment de données sur une attaque.
aggrégateur (exemple: Datadog). ‣ Ajouter des règles pour détecter les activités suspectes et alerter. ‣ Peut être utilisé pour détecter d'autres menaces, telles que les pics de processeur et les requêtes lentes.
‣ Tests de pénétration. ‣ Suivre les actualités sur la sécurité, les listes de diffusion, experts sécurité sur Twitter, etc. ‣ Modélisation des menaces.
en cas de fuite des mots de passe: • Déconnecter tous les utilisateurs. • Marquer comme compromis (is_dirty = 1). • Forcer l'authentification à 2 facteurs (ex.: Google Authenticator). • Forcer le changement de mot de passe. • Marquer comme non compromis.
• Malveillantes (attaque DDoS) • Accessoire (échec d'un périphérique de stockage) ‣ Chaque décision technique introduit une menace potentielle. ‣ Ne pas perdre de temps sur des choses improbables ou ayant un impact minimal.
possibles ‣ Internes: personnel, fournisseurs, etc. ‣ Externes: compétiteurs, criminels, activistes, etc. ‣ Réalisent des attaques malveillantes ou des erreurs par inadvertance. ‣ Autres agents: incendies, tremblements de terre, malware, etc.
à jour du système d'exploitation. ‣ Dispositif: appareils pare-feu, systèmes de détection d'intrusion. ‣ Procédure: réviser le code, supprimer les clés SSH inutilisées. ‣ Technique: validation des entrées, cryptage des données.
afilina
kazatohiei
javiergs
blueswen
m_seki
chiroruxx
j5ik2o
chobishiba
mackee
ivargrimstad
tanakahisateru
taiyow
myohei
deanohume
philnash
destraynor
pedronauck
yeseniaperezcruz
bcantrill
michaelherold
sonatard
notwaldorf
keathley
aki_iinuma
chrislema
