Sie möchten sicher, dass Ihr Code von einem möglichst erfahrenen Entwickler geschrieben wird, aber das reicht nicht aus. Selbst die kompetentesten Entwickler machen Fehler (obwohl weniger kompetente offensichtlich dazu neigen, mehr Fehler zu machen).

Um relativ fehlerfreien Code und Algorithmen zu erhalten, möchten Sie mit dem saubersten Code beginnen, der möglich ist. Dies ist jedoch nur die Hälfte des Prozesses. Der beste Weg, um Fehler zu beseitigen, besteht darin, so viele erfahrene Entwickler wie möglich den Code durchsuchen zu lassen, der nach ihnen sucht. Dies gilt für Code ebenso wie für Algorithmen. Ihre Lösung muss von den erfahrensten Personen umfassend überprüft werden.

Wo Sie anfangen - das Können des ursprünglichen Entwicklers - ist nur der Ausgangspunkt. Nach einer ausreichenden Überprüfung spielt es keine Rolle, wie gut der ursprüngliche Entwickler war.

Hier ist also der Schlüssel: Der Sicherheitswert in jedem Code hängt davon ab, wie gut er überprüft wurde . Ob es von Ihnen, einem renommierten Kryptographen, einem großen Unternehmen oder insbesondere von niemandem geschrieben wurde, es kommt nur darauf an, wie viele qualifizierte Augen den Code überprüft haben.

Eine solche Regel wird tendenziell bevorzugt etablierte Frameworks für hausgemachte Lösungen. Etabliert ist jedoch nicht unbedingt dasselbe wie überprüft , weshalb viele Sicherheitsexperten Open-Source-Lösungen bevorzugen: Es ist schwierig für Open- Quellprojekt, um populär zu werden, ohne dass es einer gewissen Kontrolle unterzogen wird.

Für ein Homebrew-Framework reicht ein kompetenter Programmierer nicht aus. Sie benötigen einen kompetenten Programmierer, der Zeit hat, sich sowohl der Implementierung als auch der anschließenden Wartung zu widmen, und der dies in zehn Jahren noch tun wird. Dies ist möglich, jedoch nicht wirklich in einem Universitätskontext, in dem Studenten kommen und gehen.

Wenn Sie sich an ein etabliertes Framework halten, profitieren Sie von den Sicherheitsupdates und der allgemeinen Arbeit des Framework-Wartungsteams Dies erleichtert Ihnen die Arbeit.

Der einzige zu beachtende Punkt ist, dass ein Homebrew-Framework selbst keine Sicherheit bietet. Es gibt nur ein Gefühl der Sicherheit. Die Argumentation lautet normalerweise: "Da wir ein Homebrew-Framework haben, leiden wir nicht unter den bekannten Fehlern und Schwächen eines etablierten Frameworks, und der Angreifer wird niemals erraten, wo sich unsere eigenen Fehler befinden." Diese Argumentation ist fehlerhaft: Der Angreifer kennt Ihren Code bereits, möglicherweise besser als Sie. Besonders an einer Universität, an der per Definition viele technologisch versierte Menschen mit einer abenteuerlichen Einstellung, einer flexiblen Moral und in der Regel viel mehr Freizeit und verfügbarer Rechenleistung leben, als als gesund angesehen werden kann. P. >

Sie sollten also ein etabliertes Framework verwenden.

Sie haben zwei Bedenken:

1. "Drive-by-Hacker", die Ihre Daten löschen, verhindern, dass Ihr Webserver funktioniert, indem Sie Tausende Websites gleichzeitig ausnutzen.
2. " Zielgruppe sind Hacker, die speziell auf Ihren Webserver zugreifen möchten, um "höhere Gewinne" zu erzielen.
ol>

Erstens ist dies kein Problem, solange Sie über eine solide Sicherung, Aktualisierung und Wiederherstellung verfügen Pläne vorhanden. Es wird die Kosten für das Schreiben eines Frameworks übertreffen, es sei denn, Sie werden jeden zweiten Tag gehackt.

Das zweite spielt keine Rolle, selbst wenn Sie KEIN Framework verwenden. Denn wenn der Anreiz hoch genug ist, ist alles möglich, einschließlich Social Hacking, Kauf von Zero-Day-Exploits vom Schwarzmarkt usw. Was Sie tun müssen, ist, den Anreiz zu senken. Isolieren Sie wertvolle Daten vom Webserver, und die Schwachstellen Ihres Frameworks sind nicht mehr wichtig.

Das größte Problem mit einem Homebrew-Framework: Zu wenige Experten in der Codebasis.

Das Schreiben eines eigenen Frameworks macht Spaß (nun, es ist für die Art von Codierer, die solche Dinge mag). Aber wenn der Besitz des Codes nicht weit verbreitet ist, ist dies ein gefährlicher Weg.

Ich habe an mehreren Stellen gearbeitet, an denen sie ihre eigenen Framework-Bibliotheken geschrieben hatten. Normalerweise wurde das Framework selbst fast ausschließlich von einem oder zwei Entwicklern geschrieben. Die Chefs sind überzeugt, dass der Framework-Code ein wertvolles Gut war, und die führenden Entwickler, die den Code genau kennen, sind praktisch unersetzlich.

Das Problem ist, dass der Code in jedem Fall, den ich gesehen habe, voll ist von Fehlern, Sicherheitslücken und schlechten Praktiken. Wenn der Hauptentwickler schließlich geht, müssen seine Nachfolger die Stücke abholen. Manchmal kämpfen sie einfach weiter mit dem vorhandenen Code. manchmal führen sie ein umfangreiches Re-Engineering-Projekt durch; Manchmal wechseln sie zu einem Framework eines Drittanbieters.

Das andere Problem, das normalerweise auftritt, ist, dass die Technologie- und Benutzeranforderungen weitergehen. Wenn Sie Ihr eigenes Framework geschrieben haben, müssen Sie ständig daran arbeiten, um es auf dem neuesten Stand zu halten. Dies ist in Ordnung, wenn das Framework Ihr Hauptprojekt ist, aber wenn es nur Ihr Back-End-Code ist, wird es Ihre Zeit verschlingen, die Sie besser für die Arbeit an Ihrem eigentlichen Projekt verwenden sollten.

Endlich Sicherheit. Das ist wirklich der Große. Viele, viele kompetente Entwickler haben Code geschrieben, der unsicher ist. In der Tat, wenn wir ehrlich sind, haben wir alle. Java wurde nicht von Inkompetenten geschrieben, und dennoch musste Oracle diese Woche einen Patch für fünfzig Sicherheitslücken herausgeben. Jede andere Software, die Sie nennen könnten, hat ebenfalls Löcher und wahrscheinlich immer noch Löcher. Wenn Sie Ihr eigenes Framework schreiben, schreiben Sie kategorisch nicht etwas Sichereres als eines der bekannten Frameworks von Drittanbietern. Tatsächlich ist es wahrscheinlich erheblich schlimmer, und Sie haben nicht die Ressourcen, um nach Sicherheitslücken zu suchen. Sie haben "Sicherheit durch Dunkelheit", weil niemand Ihren Code gesehen hat, aber Sie müssen nur diesen Satz googeln, um zu sehen, was die Sicherheitswelt darüber denkt.

Zusammenfassend würde ich das tun Nein sagen; Ein selbstgebrautes Framework ist keine gute Idee.

Schreiben Sie trotzdem eines - es ist eine großartige Lernübung - aber erwarten Sie nicht, dass es so gut ist wie die Frameworks, die es bereits gibt . Wenn es so einfach wäre, wären die vorhandenen Bibliotheken nicht erforderlich.

Wie von anderen beschrieben, ist das unterstützte, überprüfte und gewartete Framework fast immer besser als eine "Homebrew" -Lösung. Dies gilt insbesondere im universitären Kontext, wo die Arbeit häufig zunächst als Projekt geleistet wird und dann jahrelang mit unzureichender Finanzierung und Unterstützung verweilt. Vorausgesetzt, Sicherheitspaches werden auf das Framework angewendet, können Sie zumindest ein gewisses Maß an Vertrauen aufrechterhalten. Das Gleiche gilt nicht für ein Homebrew-System. Angesichts der Tatsache, dass Sicherheit ein sich entwickelndes und bewegendes Fest ist, brauchen Sie dies.

Die einzige Warnung, die ich in Bezug auf etablierte Frameworks erhalten würde, ist sicherzustellen, dass Sie das richtige Framework für die Aufgabe auswählen. Einige Frameworks sind riesig, äußerst komplex und erfordern spezielle Kenntnisse und Erfahrungen, um richtig verwendet zu werden. Ein sicheres und gut gestaltetes Framework ist nicht von Vorteil, wenn es von unerfahrenen Entwicklern implementiert oder verwendet wird. Berücksichtigen Sie neben den Sicherheitsaspekten Ihres Frameworks auch die Fähigkeiten Ihrer Entwickler und suchen Sie nach einem Framework, das genau die gewünschte Funktionalität bietet und nicht viele zusätzliche Funktionen, die Sie nicht benötigen und wahrscheinlich nicht richtig konfigurieren .