Dies ist eine schamlose Informationsbeschaffung für mein eigenes Buch.
Einer der Vorträge, die ich in der Community halte, ist eine Einführung in die Schwachstellen von Websites. Normalerweise kann ich während des Gesprächs sehen, dass mindestens zwei Mitglieder des Publikums sehr blass werden; und das ist grundlegende Sachen, Cross Site Scripting, SQL Injection, Informationsleckage, Cross Site Form Anfragen und so weiter.
Also, wenn Sie daran denken können, eins zu sein, als ein beginnender Webentwickler (sei es ASP.NET oder nicht), was wären Ihrer Meinung nach nützliche Informationen über Websicherheit und wie entwickelt man sich sicher? Ich werde bereits die OWASP Top Ten
behandeln(Ja, das bedeutet, Stackoverflow wird in der Bestätigungsliste sein, wenn jemand etwas erfindet, an das ich noch nicht gedacht habe!)
Es ist jetzt alles getan und veröffentlicht, danke euch allen für eure Antworten
Zunächst möchte ich auf die Unsicherheiten des Internets aufmerksam machen, die Menschen zugänglich machen, für die die Entwicklung von Sicherheit (leider) ein neues Konzept sein kann. Zeigen Sie ihnen beispielsweise, wie sie einen HTTP-Header abfangen und einen XSS-Angriff implementieren. Der Grund, warum Sie ihnen die Angriffe zeigen wollen, ist, dass sie selbst eine bessere Vorstellung davon haben, wogegen sie sich verteidigen. Darüber hinaus ist es großartig, über Sicherheit zu sprechen, aber ohne die Art des Angriffs zu verstehen, den sie vereiteln sollten, wird es für sie schwierig sein, ihre Systeme aus Sicherheitsgründen genau zu "testen". Sobald sie die Sicherheit testen können, indem sie versuchen, Nachrichten abzufangen, Header zu fälschen usw., wissen sie zumindest, ob die Sicherheit, die sie implementieren wollen, funktioniert oder nicht. Sie können ihnen die Methoden beibringen, die Sie für die Implementierung dieser Sicherheit benötigen, und wissen, ob sie es falsch verstehen. Sie werden es wirklich wissen, weil es die Sicherheitstests nicht besteht, die Sie ihnen gezeigt haben.
Defensives Programmieren als ein archetypisches Thema, das alle bestimmten Angriffe abdeckt, da die meisten, wenn nicht alle, dadurch verursacht werden, dass sie nicht defensiv genug denken.
Machen Sie dieses Thema zur zentralen Spalte des Buches. Was mir damals gut getan hatte, war, über Techniken Bescheid zu wissen, denen man niemals traute, nicht nur einen Stopp, wie "erlaube keine SQL-Kommentare oder spezielle Zeichen in deiner Eingabe".
Eine andere interessante Sache, die ich gerne früher gelernt hätte, ist, wie man sie tatsächlich testen kann.
Ich denke, alle Schwachstellen basieren auf Programmierern, die nicht denken, weder auf momentanen Fehleinschätzungen noch auf etwas, an das sie nicht gedacht haben. Eine große Sicherheitslücke in einer Anwendung, die ich reparieren sollte, war die Tatsache, dass sie 0 (Null) von der Authentifizierungsmethode zurückgaben, als der Benutzer, der sich anmeldete, ein Administrator war. Wegen der Tatsache, dass die Variable ursprünglich als 0 initialisiert wurde, wenn irgendwelche Probleme auftraten, wie zum Beispiel das Herunterfahren der Datenbank, wodurch eine Ausnahme ausgelöst wurde. Die Variable würde niemals auf den richtigen "Sicherheitscode" gesetzt werden und der Benutzer hätte dann Administratorzugriff auf die Site. Absolut schrecklicher Gedanke ging in diesen Prozess ein. Das bringt mich zu einem wichtigen Sicherheitskonzept. Setzen Sie niemals den Anfangswert einer Variablen, die eine "Sicherheitsstufe" oder etwas Ähnliches darstellt, auf etwas, das die totale Kontrolle über die Site repräsentiert. Besser noch, nutzen Sie vorhandene Bibliotheken, die durch das Feuer der Verwendung in großen Mengen von Produktionsumgebungen für eine lange Zeitperiode gegangen sind.
Ich würde gerne sehen, wie sich die ASP.NET-Sicherheit von der ASP Classic-Sicherheit unterscheidet.
Gut zu hören, dass Sie die OWASP Top Ten haben werden. Warum nicht auch die Berichterstattung über die SANS / CWE Top 25 Programmierfehler mit einbeziehen.
Ich versuche immer, das Worst-Case-Szenario für Dinge aufzuzeigen, die schief gehen könnten. Zum Beispiel, wie eine Cross-Site-Skript-Injection als Black-Box-Angriff funktionieren kann, die sogar auf Seiten in der Anwendung funktioniert, auf die ein Hacker nicht selbst zugreifen kann oder wie eine SQL-Injection als Blackbox und Wie ein Hacker Ihre vertraulichen Geschäftsdaten stehlen kann , auch wenn Ihre Website mit Ihrer normalen Datenbank verbunden ist nicht privilegiertes Login-Konto.