Existe-t-il des bonnes pratiques pour tester la sécurité dans un magasin de développement Agile?

En ce qui concerne le développement Agile, quelles sont les meilleures pratiques pour tester la sécurité par version?

S'il s'agit d'une publication mensuelle, y a-t-il des boutiques qui font des tests de stylo tous les mois?

0

4 Réponses

Je ne suis pas un expert en développement Agile, mais j'imagine que l'intégration d'un logiciel de test de stylo automatisé de base dans votre cycle de construction serait un bon début. J'ai vu plusieurs progiciels qui effectueront des tests de base et qui sont bien adaptés à l'automatisation.

0
ajouté

Je ne suis pas un expert en sécurité, mais je pense que le fait le plus important que vous devriez connaître, avant de tester la sécurité, est ce que vous essayez de protéger. Seulement si vous savez ce que vous essayez de protéger, vous pouvez faire une analyse correcte de vos mesures de sécurité et seulement alors vous pouvez commencer à tester ces mesures mises en œuvre.

Très abstrait, je sais. Cependant, je pense que cela devrait être la première étape de chaque vérification de sécurité.

0
ajouté
+1 Bien joué, @David. Je suis un expert en sécurité, et je vois toujours des soi-disant «experts» qui n'obtiennent pas ce principe de base.
ajouté l'auteur AviD, source

Unit testing, Defense Programming and lots of logs

Tests unitaires

Assurez-vous de tester l'unité le plus tôt possible (par exemple, le mot de passe doit être crypté avant l'envoi, le tunnel SSL fonctionne, etc.). Cela empêcherait vos programmeurs d'accidentellement rendre le programme non sécurisé.

Programmation de défense

Personnellement, j'appelle cela la programmation paranoïaque mais Wikipedia n'est jamais faux ( sarcasme ). Fondamentalement, vous ajoutez des tests à vos fonctions qui vérifient toutes les entrées:

  • les cookies de l'utilisateur sont-ils valides?
  • est-il toujours connecté?
  • les paramètres de la fonction sont-ils protégés contre l'injection SQL? (même si vous savez que les entrées sont générées par vos propres fonctions, vous allez tester quand même)

Journalisation

Connectez-vous tout comme un fou. Il est plus facile d'enlever les journaux que de les ajouter. Un utilisateur s'est connecté? Connectez-le. Un utilisateur a trouvé un 404? Connectez-le. L'administrateur a édité / supprimé un message? Connectez-le. Quelqu'un a-t-il pu accéder à une page restreinte? Connectez-le.

Ne soyez pas surpris si votre fichier journal atteint 15 Mo au cours de votre phase de développement. Au cours de la version bêta, vous pouvez décider des journaux à supprimer. Si vous le souhaitez, vous pouvez ajouter un indicateur pour décider quand un certain événement est enregistré.

0
ajouté

Quel est votre domaine d'application? Ça dépend.

Puisque vous avez utilisé le mot "Agile", je suppose que c'est une application web. J'ai une bonne réponse facile pour vous.

Allez acheter une copie de Burp Suite (c'est le résultat # 1 de Google pour "burp" --- un endossement sûr!); il vous en coûtera 99EU, ou ~ $ 180USD, ou 98 Dollars d'Obama si vous attendez jusqu'à novembre.

Burp fonctionne comme un proxy web. Vous naviguez à travers votre application Web en utilisant Firefox ou IE ou autre, et il recueille tous les hits que vous générez. Ces hits sont alimentés par une fonctionnalité appelée "Intruder", qui est un fuzzer Web. Intruder déterminera tous les paramètres que vous fournissez à chacun de vos gestionnaires de requêtes. Il va ensuite essayer des valeurs folles pour chaque paramètre, y compris SQL, système de fichiers et métacaractères HTML. Sur un poste de formulaire complexe typique, cela va générer environ 1500 hits, que vous examinerez pour identifier effrayant --- ou, plus important encore dans un contexte Agile, de nouvelles réponses d'erreur ---.

Fuzzing chaque gestionnaire de requête dans votre application Web à chaque itération de version est la chose n ° 1 que vous pouvez faire pour améliorer la sécurité de l'application sans instituer un "SDLC" formel et en ajoutant des effectifs. Au-delà, passez en revue votre code pour les principaux points de sécurité de l'application Web:

  • Utilisez uniquement des instructions SQL préparées paramétrées; ne jamais simplement concaténer des chaînes et les alimenter à la base de données.

  • Filtrez toutes les entrées sur une liste blanche de bons caractères connus (alnum, ponctuation de base) et, plus important encore, publiez des données de filtre à partir des résultats de votre requête pour "neutraliser" les métacaractères HTML en entités HTML. gt, etc.).

  • Utilisez des identifiants aléatoires longs et aléatoires partout où vous utilisez actuellement des identifiants simples de lignes entières dans les paramètres de requête, et assurez-vous que l'utilisateur X ne peut pas voir les données de l'utilisateur Y en devinant ces identifiants. >

  • Testez chaque gestionnaire de requêtes de votre application pour vous assurer qu'elles fonctionnent uniquement lorsqu'un cookie de session valide et connecté est présenté.

  • Activez la protection XSRF dans votre pile Web, ce qui générera des paramètres de jeton de formulaire cachés sur tous vos formulaires rendus afin d'empêcher les pirates de créer des liens malveillants qui enverront des formulaires aux utilisateurs non avertis.

    li>
  • Utilisez bcrypt --- et rien d'autre --- pour stocker les mots de passe hachés.

0
ajouté