Awesome Application Security Checklist

Awesome-Application-Security-Checklist

Si vous concevez, créez, testez votre application Web / mobile avec la sécurité à l'esprit, cette liste de contrôle des contre-mesures peut être un bon point de départ

Systèmes d'authentification (réinitialisation de l'inscription / Signin / 2 facteur / mot de passe)

• Utilisez HTTPS partout.
• Stockez les hachages de mot de passe à l'aide Bcrypt (aucun sel nécessaire - Bcrypt le fait pour vous).
• Détruisez l'identifiant de session après logout .
• Détruisez toutes les sessions actives sur le mot de passe de réinitialisation (ou offrez-vous).
• Doit avoir le paramètre state dans OAuth2.
• Aucune redirection ouverte après une connexion réussie ou dans tout autre redirection intermédiaire.
• Lors de l'entrée d'inscription / connexion d'analyse, désinfectez pour javascript: //, données: //, caractères CRLF.
• Définissez des cookies sécurisés et httponly.
• Dans la vérification mobile basée sur OTP mobile, ne renvoyez pas l'OTP dans la réponse lors de generate OTP ou Resend OTP est appelée.
• Limiter les tentatives pour Login , Verify OTP , Resend OTP et generate OTP pour un utilisateur particulier. Ayez un ensemble de backoff exponentiel ou / et quelque chose comme un défi basé sur Captcha.
• Vérifiez l'aléatoire du jeton de mot de passe de réinitialisation dans le lien envoyé par e-mail ou les SMS.
• Définissez une expiration sur le jeton de mot de passe de réinitialisation pendant une période raisonnable.
• Expirez le jeton de réinitialisation après avoir été utilisé avec succès.

Données et autorisations utilisateur

• Tout accès aux ressources comme, my cart , my history devrait vérifier la propriété de la ressource par l'utilisateur en utilisant l'ID de session.
• L'ID de ressource en série itérable doit être évité. Utiliser /me/orders au lieu de /user/37153/orders . Cela agit comme une vérification de la santé mentale au cas où vous avez oublié de vérifier le jeton d'autorisation.
• La fonction Edit email/phone number doit être accompagnée d'un e-mail de vérification au propriétaire du compte.
• Toute fonction de téléchargement doit désinfecter le nom de fichier fourni par l'utilisateur. De plus, pour des raisons généralement en dehors de la sécurité, téléchargez quelque chose comme S3 (et post-processus à l'aide de Lambda) et non votre propre serveur capable d'exécuter du code.
• La fonction Profile photo upload doit désinfecter toutes les balises EXIF ​​également si elle n'est pas requise.
• Pour les ID utilisateur et autres ID, utilisez UUID conforme à RFC au lieu des entiers. Vous pouvez trouver une implémentation pour cela pour votre langue sur GitHub.
• JWT est génial. Utilisez-les si nécessaire pour votre application / API à une seule page.

Base de données

• Utilisez le cryptage pour les données identifiant les utilisateurs et les données sensibles comme les jetons d'accès, les adresses e-mail ou les détails de facturation.
• Si votre base de données prend en charge le cryptage à faible coût au repos (comme AWS Aurora), activez cela pour sécuriser les données sur le disque. Assurez-vous que toutes les sauvegardes sont également stockées.
• Utilisez un privilège minimal pour le compte d'utilisateur d'accès à la base de données. N'utilisez pas le compte racine de la base de données.
• Stockez et distribuez des secrets à l'aide d'un magasin clé conçu à cet effet. Ne code pas dur dans vos applications.
• Empêcher complètement l'injection SQL en utilisant uniquement des instructions préparées à SQL. Par exemple: si vous utilisez NPM, n'utilisez pas NPM-MySQL, utilisez NPM-MySQL2 qui prend en charge les instructions préparées.

Application Android / iOS

• salt des passerelles de paiement ne doit pas être codé en dur.
• Le jeton secret / auth token des SDK tiers ne devrait pas être codé en dur.
• Les appels API destinés à être effectués server to server ne doivent pas être effectués à partir de l'application.
• Dans Android, toutes les autorisations accordées doivent être soigneusement évaluées.
• Sur iOS, stockez des informations sensibles (jetons d'authentification, touches API, etc.) dans le trousseau du système. Ne stockez pas ce type d'informations dans les défaillances de l'utilisateur.
• L'épinglage du certificat est fortement recommandé.

En-têtes de sécurité et configurations

• Add un en-tête CSP pour atténuer les XS et les attaques d'injection de données. C'est important.
• Add l'en-tête CSRF pour empêcher le contrefaçon de demande de site croisé. Ajoutez également les attributs sonores sur les cookies.
• Add un en-tête HSTS pour prévenir l'attaque de décapage SSL.
• Add votre domaine à la liste de précharge HSTS
• Add des options X-Frame pour protéger contre le jacking de clics.
• Add l'en-tête X-XSS-Protection pour atténuer les attaques XSS.
• Mettez à jour les enregistrements DNS pour ajouter un enregistrement SPF pour atténuer les attaques de spam et de phishing.
• Ajouter une intégrité de sous-resource vérifie si le chargement de vos bibliothèques JavaScript à partir d'un CDN tiers. Pour plus de sécurité, ajoutez le requis-SRI-pour CSP-Directive afin de ne pas charger de ressources qui n'ont pas de SRI SAT.
• Utilisez des jetons CSRF aléatoires et exposez les API de logique métier en tant que requêtes HTTP Post. N'exposez pas les jetons CSRF sur HTTP par exemple dans une phase de mise à niveau de demande initiale.
• N'utilisez pas de données critiques ou de jetons dans les paramètres de demande de GET. L'exposition des journaux de serveurs ou une machine / pile les traitements exposerait à son tour les données utilisateur.

Désinfection de l'entrée

• Sanitize toutes les entrées utilisateur ou tout paramètre d'entrée exposé à l'utilisateur pour empêcher les XS.
• Utilisez toujours des requêtes paramétrées pour empêcher l'injection de SQL.
• Désinfecter la saisie de l'utilisateur si l'utilisation directement pour les fonctionnalités comme l'importation de CSV.
• Sanitize la saisie de l'utilisateur pour des cas spéciaux comme Robots.txt comme noms de profil au cas où vous utilisez un modèle d'URL comme coolcorp.io/username.
• Ne remettez pas de code et ne construisez jamais JSON par la concaténation des chaînes, quelle que soit la taille de l'objet. Utilisez vos bibliothèques ou cadre définis par la langue.
• Désinfecter les entrées qui prennent une sorte d'URL pour empêcher le SSRF.
• Désinfecter les sorties avant de s'afficher aux utilisateurs.

Protection du déni de service

• Assurez-vous que les attaques DOS sur vos API ne paralyseront pas votre site. Au minimum, ayez des limites de taux sur vos chemins d'API plus lents comme la connexion et les routines de génération de jetons. Envisagez CAPTCHA sur les API frontaux pour protéger les services back-end contre DOS.
• Appliquer les limites de santé mentale sur la taille et la structure des données et demandes soumises par les utilisateurs.
• Utiliser l'atténuation du déni de service distribué (DDOS) via un service de proxy de mise en cache global comme CloudFlare. Cela peut être activé si vous souffrez d'une attaque DDOS et que vous fonctionnez autrement comme votre recherche DNS.

Opérations

• Si vous êtes petit et inexpérimenté, évaluez à l'aide d'AWS ElasticBeanstalk ou d'un PaaS pour exécuter votre code.
• Utilisez un script d'approvisionnement décent pour créer des machines virtuelles dans le cloud.
• Vérifiez les machines avec open ports publiquement indésirables.
• Vérifiez les mots de passe non / par défaut pour databases , en particulier MongoDB & Redis.
• Utilisez SSH pour accéder à vos machines; Ne configurez pas de mot de passe, utilisez plutôt une authentification basée sur les clés SSH.
• Installez les mises à jour en temps opportun pour agir sur des vulnérabilités de jour zéro comme le coeur, ShellShock.
• Modifiez la configuration du serveur pour utiliser TLS 1.2 pour HTTPS et désactivez tous les autres schémas. (Le compromis est bon.)
• Ne laissez pas le mode de débogage. Dans certains frameworks, le mode de débogage peut donner un accès à des réponses ou des shells à part entière ou exposer les données critiques dans les messages d'erreur Stacktraces.
• Soyez prêt pour les mauvais acteurs et DDOS - Utilisez un service d'hébergement qui a une atténuation DDOS.
• Configurez la surveillance de vos systèmes et enregistrez des trucs (utilisez une nouvelle relique ou quelque chose comme ça).
• Si vous développez des clients d'entreprise, adhèrez-vous aux exigences de conformité. Si AWS S3, envisagez d'utiliser la fonctionnalité pour chiffrer les données. Si vous utilisez AWS EC2, envisagez d'utiliser la fonctionnalité pour utiliser des volumes cryptés (même les volumes de démarrage peuvent être cryptés maintenant).

Configuration du cloud

• Assurez-vous que tous les services ont des ports minimum ouverts. Bien que la sécurité par l'obscurité ne soit pas une protection, l'utilisation de ports non standard rendra un peu plus difficile pour les attaquants.
• Hôte Backend Database and Services sur des VPC privés qui ne sont visibles sur aucun réseau public. Soyez très prudent lors de la configuration des groupes de sécurité AWS et des VPC qui peuvent regarder par inadvertance les services visibles au public.
• Isoler les services logiques dans des VPC distincts et des VPC par les pairs pour fournir une communication interservice.
• Assurez-vous que tous les services acceptent uniquement les données d'un ensemble minimal d'adresses IP.
• Restreindre le trafic IP et portuaire sortant pour minimiser les APT et la «botification».
• Utilisez toujours des rôles AWS IAM et non des informations d'identification.
• Utilisez un privilège d'accès minimal pour tous les employés OPS et développeurs.
• Tournez régulièrement les mots de passe et les clés d'accès selon un calendrier.

CI & CD Audit votre conception et implémentation avec la couverture des tests unit / intégration. Utilisez un processus d'examen de code et ne tiennent pas compte de l'auto-approbation. Assurez-vous que tous les composants de vos services sont analysés statiquement par le logiciel AV avant de passer à la production, y compris les bibliothèques des fournisseurs et d'autres dépendances. Concevez une solution en arrière pour les déploiements.

PERSONNES

• Configurez un e-mail (par exemple [email protected]) et une page pour que les chercheurs en sécurité signalent des vulnérabilités.
• Selon ce que vous faites, limitez l'accès à vos bases de données utilisateur.
• Soyez poli avec les journalistes de bug.
• Faites faire votre revue de code par un collègue développeur dans une perspective de codage sécurisée. (Plus d'yeux)
• En cas de violation de piratage ou de données, vérifiez les journaux précédents pour l'accès aux données, demandez aux gens de modifier les mots de passe. Vous pourriez avoir besoin d'un audit par des agences externes selon l'endroit où vous êtes incorporé.

Infrastructure

• Assurez-vous que vous pouvez effectuer des mises à niveau sans temps d'arrêt. Assurez-vous que vous pouvez rapidement mettre à jour les logiciels de manière entièrement automatisée.
• Créez toutes les infrastructures à l'aide d'un outil tel que Terraform, et non via la console Cloud. L'infrastructure doit être définie comme un «code» et pouvoir être recréée à la poussée d'un bouton. Ayez une tolérance zéro pour toute ressource créée dans le cloud à la main - Terraform peut ensuite auditer votre configuration.
• Utilisez la journalisation centralisée pour tous les services. Vous ne devez jamais avoir besoin de SSH pour accéder ou récupérer des journaux.
• Ne pas SSH dans les services, sauf pour le diagnostic ponctuel. L'utilisation régulière de SSH signifie généralement que vous n'avez pas automatisé une tâche importante.
• Ne gardez pas le port 22 ouvert sur des groupes de services AWS sur une base permanente. Envisagez plutôt d'autoriser uniquement les IP autorisés à SSH sur la boîte.
• Créez des hôtes immuables au lieu de serveurs à longue durée de vie que vous corrigez et mettez à niveau. (Voir les infrastructures immuables peuvent être plus sécurisées).
• Utilisez un système de détection d'intrusion comme Sensedeep ou Service pour minimiser les APT.