2009-02-06 14 views
7

Ich bin ein Webentwickler, der sich sehr um Sicherheit bemüht und versucht, meine Webanwendungen so sicher wie möglich zu machen.Eigene Anwendung hacken

Wie auch immer ich angefangen habe, meine eigenen Windows-Anwendungen in C# zu schreiben, und wenn es darum geht, die Sicherheit meiner C# -Anwendung zu testen, bin ich wirklich nur ein Neuling.

Ich frage mich nur, ob jemand gute Tutorials/Readme's hat, wie man seine eigene Windows-Anwendung hackt und sicheren Code schreibt.

+1

Ich denke du meinst ** knacken **, ** hacken ** ist, was du machst, wenn du an deiner Anwendung arbeitest. –

Antwort

4

Die Bücher von Michael Howard sind ein guter Ausgangspunkt; Bedrohung

Es gibt viele Links und interessanten Artikel von Michael Howard Blog here

Es ist eine interessante Powerpoint-Präsentation von Microsoft über Bewertung, Risiken und ASP here.

2

Abgesehen von all den offensichtlichen Antworten zu Pufferüberläufen, Code-Injektion, Sitzung Highjacking und zu verhindern. al. Sie sollten jemanden anderen finden, der Ihren Code/Ihre Software überprüft, da Sie nur über Möglichkeiten nachdenken können, wie Sie Ihre Software hacken können, von der Sie wissen, wie sie sie verhindern kann. Nur weil Sie keine Möglichkeit finden, Ihre eigene Software zu hacken, bedeutet das nicht, dass niemand anderes es kann.

0

Um Ihre Win-Form-Anwendung zu sichern, öffnen Sie sie und versuchen Sie alles, was Lambda-Benutzer nicht tun sollten! Ich werde erklären:

Wenn Sie sagen "yes oder no eingeben", versuchen Sie mit A-Z, 0-9, weil das ist, was einige Benutzer versuchen, einige Stack-Trace zu finden, die interessant sein könnte. Stellen Sie also Validatoren überall hin.

Vorsicht Verbindung zu Datenbanken, aber wenn Sie von Web-Dev kommen, sollten Sie mehr bewusst sein als ich :).

Der schwierigste Teil ist, auf Speicherlecks oder solche Sachen zu achten, aber das ist in großen großen Apps oder in nicht gut entwickelten Apps.

2

Dies ist etwas, was sehr schwierig für Sie ist, und ich denke, dass Sie das Problem aus dem falschen Blickwinkel nähern. Wenn Sie eine Anwendung beliebiger Größe schreiben, ist es fast unmöglich, sich am Ende mit der Sicherheit zu befassen, indem Sie nach bestimmten Möglichkeiten suchen, Ihre eigene Software zu zerschlagen.

Dies ist aus einer Reihe von Gründen. Sie denken bereits in gewisser Weise an Ihre Software. Du denkst an spezifische Wege, mit ihr zu interagieren, und du weißt, wie du das Beste daraus bekommst. Sie denken nicht darüber nach, wie Sie es ausnutzen können, und das ist schwer mit Software zu tun, mit der Sie vertraut sind.

Ein weiteres Problem ist, dass die Aufgabe von diesem Punkt zu groß ist, um damit umzugehen. Alle Probleme, die Sie finden, können eine Reihe anderer Probleme aufwerfen. Ein systemweiter Sicherheitscheck ist bei weitem nicht granular genug.

Was Sie tun sollten, ist über Sicherheit nachzudenken, während Sie die Software schreiben. Lernen Sie die Best Practices kennen und betrachten Sie jede Methode und Klasse, die Sie aus Sicherheitsgründen schreiben.Dies geht Hand in Hand mit Unit Testing, versuchen Sie zu überlegen, welche Eingaben diesen speziellen Teil meines Programms brechen könnten. und dann auf dieser Ebene mit ihnen umgehen.

Danach denke ich, es ist eine Frage der Beantwortung von Sicherheitsfragen, auf die Sie aufmerksam gemacht werden.

1

Sie könnten viel schlechter als das Lesen von Ross Anderson Security Engineering Buch tun. Die erste Ausgabe kann als PDF heruntergeladen werden und liest sich gut. Ich habe die zweite Ausgabe nicht gelesen, aber ich vermute, dass es besser ist und mehr Leckereien darin hat.

Beachten Sie, dass es ein Buch ist, das erklärt, wie man Sicherheit von Anfang an baut, nicht wie man die Sicherheit bricht, aber die Ausstellung von verschiedenen Sicherheitsfehlern sollte Ihnen eine gute Idee geben, wo Sie anfangen sollten.

1

Kleine Dinge, auf die ich durch meine eigene Erfahrung gestoßen bin.

  • Verwenden Sie nicht dynamisches SQL, Sie sind dann anfällig für SQL-Injektion. Verwenden Sie lieber SQL-Abfragen mit Parametern.
  • Keine inkrementieren IDs wie user_id = 1, 2, 3 etc etc und dann verwenden Sie das in einer URL, something.aspx? User_id = 1, kann ich dann die nächste ID und Session hoffen. Gleiches gilt für Accounts und was sonst noch sensibel ist.
  • Achten Sie auf XSS, (Cross Site Scripting). Wenn Sie Benutzereingaben akzeptieren und sie direkt speichern, vergewissern Sie sich, dass sie keinen Alert() für ihren Namen oder etwas einfügen können.

Dies ist keineswegs eine vollständige Liste. Genau das Zeug, auf das ich kürzlich gestoßen bin.