Je dirais qu'une excellente façon d'apprendre est pour elle de casser les applications qu'elle a déjà écrites.

En supposant qu'elle est en train d'écrire des applications Web, dirigez-la vers le haut de l'OWASP 10. Faites-lui voir si elle peut trouver l'une de ces failles dans son propre code. Il n'y a pas de meilleur moyen d'apprendre les concepts de sécurité que de le voir se produire sur votre propre code.

Une fois qu'une faille a été trouvée, demandez-lui de réécrire l'application pour corriger la faille. Cela lui permettra d'apprécier l'effet de choses comme l'assainissement et la validation des entrées des utilisateurs et des requêtes paramétrées.

Procédez par étapes. Je ne me lancerais pas directement dans la conception d'une nouvelle application avec la sécurité à l'esprit avant de vraiment comprendre quel type de code entraîne des failles de sécurité.

Je vais prendre la position qui peut me faire flambé ...

Le problème que je vois, c'est que la programmation sécurisée est enseignée comme un add-on. Les meilleures pratiques doivent être enseignées dès le début (y compris la sécurité). Le mensonge qu'on apprend, c'est que la pratique fait préfet. La vérité est que la pratique rend permanente. Donc, si vous le faites mal, vous devez désapprendre ce que vous avez appris. C'est une approche bassackwards.

Je dirais que les pratiques de codage sécurisé devraient être enseignées dès le premier jour. Il n'y a aucune raison d'apprendre à le faire, puis à le faire en toute sécurité. C'est une perte de temps et d'argent ...

Mes 2 bits, 1 et zéro de plus à dire ...

Bien que je sois d'accord en principe avec Everett, il y a un autre point de vue. Le but d'une leçon est d'apprendre un concept, qui peut ensuite être développé. Cela réduit la pente de la courbe d'apprentissage. Enseigner trop trop vite est accablant; face à un assaut d'informations, la plupart des cerveaux «fuient».

C'est formidable de dire «Les pratiques de codage sécurisé devraient être enseignées dès le premier jour», et très difficile de démontrer comment ce jour-là «Hello World «programme peut être vulnérable, en particulier lorsque« qu'est-ce qu'un programme informatique »est un nouveau concept pour la classe. Un projet de site Web touchant des magasins de données partagés (que je n'ai pas vraiment vu avant au moins la moitié de l'université) est plus facile à montrer des faiblesses, mais ces faiblesses sont souvent inhérentes à la mise en place d'un environnement Web de base de preuve de concept avec le " paramètres par défaut. Il est très facile de prouver qu'une application comporte des vulnérabilités, lorsque les vulnérabilités sont connues. Il est plus difficile (impossible, vraiment) de prouver qu'il n'y en a pas.

Je pense de la même manière que l'OP; à un moment donné dans le développement d'un programmeur, l'idée de «comment quelqu'un pourrait-il utiliser ce code pour faire des choses que vous ne voulez pas qu'il fasse, et comment pouvez-vous l'empêcher» peut être fusionnée dans ce que vous faites. Ce point de départ est probablement quelque part où commencer à apprendre soit sur la communication externe ou la persistance (lecture / écriture de données sur un disque dur ou une base de données, ou leur envoi à travers un canal réseau), soit sur les principes orientés objet (héritage, surcharge / dépassement, etc), selon la première éventualité. C'est là qu'un codeur peut commencer à écrire des programmes qui ont le pouvoir de faire des dégâts entre de mauvaises mains, et il faut donc veiller à ce que les mauvaises mains ne puissent pas abuser du programme.

Certains concepts sont faciles à comprendre; «Mon programme fonctionne avec des données qui sont un secret de ses utilisateurs; on me fait confiance et je dois m'assurer que seuls ceux qui devraient voir les données sont autorisés à le faire». Certains sont plus difficiles; J'ai vu des gens vraiment choqués de découvrir que les binaires de programme peuvent être décompilés et lus pour découvrir des informations d'identification ou des clés codées en dur (et que certains environnements comme .NET mettent suffisamment de métadonnées dans les binaires pour produire presque exactement le même code source utilisé pour construire them), ou que leur binaire assemblé peut être utilisé sous sa forme compilée par un attaquant qui se connecte à l'aide de classes ou de membres publics non scellés, puis a accès à tous les secrets avec lesquels ces classes travaillent. Ce sont les pièges de base qui doivent être illustrés, puis les solutions doivent être illustrées, et comment et pourquoi ils fonctionnent expliqués.

Tout comme d'autres aspects d'une véritable éducation (peut-être que cela devrait être plus sur Parenting.SE ...), je pense que cela revient à la pensée critique .

Ma fille suit également des cours de CS au collège et je l'aide à les suivre. Cependant, je ne lui donne pas les informations à la cuillère, elle doit y travailler.
Dans de nombreux cas, je lui explique quelque chose qui ne va pas, et je m'attends à ce qu'elle m'appelle. (Elle le fait généralement). Parfois, ce n'est que subtilement faux, puis c'est plus difficile pour elle de le remarquer. Parfois, elle ne le remarque pas tout de suite et commence à construire quelque chose sur la base d'une hypothèse erronée - puis elle doit travailler à rebours pour trouver le problème. (Elle s'améliore aussi.)

De cette façon, je la force à s'habituer à remettre en question les hypothèses.
Elle n'est certes pas enthousiasmée par mes méthodes.

De la même manière, je lui demande de repérer de toute façon que son code pourrait être utilisé à mauvais escient, que ce soit accidentellement ou malicieusement. Je lui ai expliqué que Elle possède son code et est responsable de ce que fait son code , pas de place pour la passivité ici. Une partie de cela est une bonne gestion des exceptions, ce que ses instructeurs s'attendent à ce qu'ils fassent de toute façon, même sans vraiment y entrer avant des cours beaucoup plus tardifs.

Maintenant, bien sûr, je m'oppose à toute forme d'enseignement de la "programmation culte du fret" - sauf si cela est explicitement noté comme tel , pour permettre l'enseignement des concepts de base, avec le avertissez que ce n'est pas toute l'histoire et nous y reviendrons plus tard. (Tels que la gestion des exceptions ci-dessus).

Mon point de tout ceci est que la "programmation sécurisée" n'est pas différente de la "programmation" .
Cependant, tout comme le livre entier de programmation ne peut pas être enseigné en une seule séance, mais les concepts sont introduits progressivement - les aspects «sécurité» des concepts de programmation pourraient attendre, tandis que le concept de base est enseigné et compris, avec le notez que "nous n'avons pas encore fini ici". On s’attend également à ce qu’au moins les meilleurs élèves découvrent certains des aspects non sécurisés.

TL; DR :

1. Un nouveau concept de programmation doit être appris progressivement, certains aspects (y compris la sécurité) peuvent être enseignés plus tard que d'autres ;
2. Ledit concept de programmation n'est pas complet tant que tous les aspects ne sont pas appris et compris, y compris les aspects de sécurité (et doit être noté jusque-là);
3. Les programmeurs ont un contrôle complet sur leur code, et pour être un programmeur, il faut savoir comment son code peut être mal utilisé;
4. Les étudiants qui pratiquent la pensée critique devraient trouver cela par eux-mêmes dès le début (pas nécessairement tout de sécurité, mais le contexte manquant et une bonne partie de l'utilisation abusive du code);
5. Les élèves qui ne pratiquent pas la pensée critique ne devraient pas vraiment apprendre la programmation ...

Je pense qu'en fin de compte, il s'agit d'essayer de déterminer à quel point l'éducation à la sécurité n'obscurcit pas le but de la leçon. Les devoirs de cours sont généralement des problèmes simplifiés conçus pour exposer un problème particulier et montrer comment résoudre ce problème particulier.

Je pense que la façon la plus idéale de l'aborder est de commencer par lui demander de faire quelque chose comme hackthissite.org pour savoir combien d'attaques fonctionnent et quels sont les dangers. Avoir une bonne compréhension de la façon dont le code peut être subverti est un excellent moyen d'aider quelqu'un à comprendre l'importance des pratiques de codage sécurisées. Le faire en parallèle signifie que cela n'obscurcira pas les sujets que ses instructeurs essaient de traiter tout en montrant les problèmes de sécurité.

De mon point de vue, en tant qu'analyste de systèmes, il y a un moyen - vous devriez enseigner aux élèves de première année un concept de standardisation, de classification et d'appariement de modèles. Les questions suivantes sont faciles et pourraient être posées au tout début ...

• Pensez à «toutes les entrées de données possibles», que l'utilisateur peut saisir, et créez-en une liste stricte.
• Apprendre / enseigner les expressions régulières. Cet outil peut être utilisé pour la mise en correspondance et le nettoyage.
• Principe des "valeurs par défaut", si les données d'entrée sont manquantes ou non valides.
• Utilisez des fichiers journaux. En cas de doute ou d'incohérence dans l'entrée, le logiciel doit utiliser une sorte de journalisation, pour «noter cela». Les fichiers journaux sont l'un des meilleurs moyens de déboguer et de découvrir les failles de sécurité que quelqu'un pourrait utiliser ou utilise déjà.
• Utilisez des messages d'erreur et des cas d'erreur. Pensez aux cas où le système pourrait échouer et pensez au numéro d'erreur approprié et au message détaillé. Certaines erreurs peuvent conduire à deux messages d'erreur détaillés différents - un pour l'utilisateur, clair et simple, un pour le propriétaire du système - à des fins de débogage ou de sécurité.

L'utilisateur est toujours un "méchant", l'utilisateur veut toujours casser votre logiciel - ne donnez jamais à l'utilisateur plus d'informations qu'il n'en demande, et s'il vous le demande, vérifiez toujours s'il a le privilège de recevoir ne serait-ce qu'une réponse simple "Vous n'avez pas d'accès" - les messages d'erreur peuvent aider hacker pour comprendre l'état du système, il essaie de casser.

On pourrait penser à plus, mais cela peut et doit être appréhendé dès le début.