Warum ist Java Secure Coding wichtig?

Question

Ich habe Probleme zu verstehen, warum Java Secure Coding wichtig ist. Warum ist es beispielsweise wichtig, Variablen als privat zu deklarieren? Ich meine, dass es unmöglich ist, auf diese Variablen von außerhalb der Klasse zuzugreifen, aber ich könnte die Klasse einfach dekompilieren, um den Wert zu erhalten. Wenn Sie eine Klasse als final definieren, ist es ebenfalls unmöglich, diese Klasse unterzuklassen. Wann wäre die Unterklassenbildung für die Sicherheit gefährlich? Wenn nötig, könnte ich die ursprüngliche Klasse erneut dekompilieren und sie mit beliebigem bösartigen Code neu implementieren. Kommt das Problem, wenn Anwendungen vom Benutzer "vertrauenswürdig" sind? Und die Leute könnten dieses Vertrauen irgendwie missbrauchen? Grundsätzlich, was ich suche, ist ein gutes Beispiel dafür, warum sichere Kodierungsrichtlinien befolgt werden sollten.

Answer 1

Die Programmierung ist schwierig.

Wenn Sie strikte APIs definieren, die keine Variablen offen legen, die nicht offen gelegt werden sollen (wir nennen das encapsulation), helfen Sie den Benutzern Ihrer APIs und erleichtern so die Programmierung. Dies wird als eine gute Sache angesehen.

Die Gründe dafür sind nicht in erster Linie „Sicherheit“, wie es in geheime Dinge geheim, so viel wie Klarheit, Einfachheit und Verständlichkeit zu halten.

Als Bonus ist es viel einfacher, die Dinge richtig funktionieren, wenn Sie, dass der Benutzer der API können nicht wissen, „Ihre“ Variablen hinter dem Rücken, natürlich verändert.

Answer 2

Es ist "sicher", was bedeutet, dass eine klasseninterne Arbeit für jeden Benutzer verborgen ist.

Der Begriff secure wird nicht verwendet, da bei der "Sicherung eines Servers" die Tatsache gemeint ist, dass ein Benutzer einer Klasse sich nicht darum kümmern muss, wie die Klasse die Aufgabe ausführt, die er wünscht.

Taking Ihr Beispiel:

Variablen einer Klasse freilegen würde den Benutzer Ihrer Klasse Know ihrer Existenz lassen, die etwas, das Sie nicht, zum Beispiel wollen: Sie nur eine Taste drücken, um die Schaltfläche Licht, du brauchst jetzt nicht, dass es Kupfer oder Wasser gibt, das es braucht, um die Aufgabe zu erfüllen.

Answer 3

Nur um hinzuzufügen, was andere haben bereits gesagt: Einige dieser Funktionen auch einfach als eine Möglichkeit angesehen werden wollen angeben. Wenn ich ein Mitglied mache private mache ich es "unmöglich" für andere auf es zuzugreifen (es ist möglich, aber das ist neben dem Punkt hier), aber noch wichtiger, ich sage den Benutzern, dass dies ein Implementierungsdetail ist, auf das sie sich nicht verlassen sollten .

Answer 4

Es gibt zwei Probleme hier.

Die ersten, wenn Variablen als geschützt oder privat deklariert werden, werden sie nicht Teil Ihrer öffentlichen API. Andere Klassen können in Zukunft von Ihrer Klasse abhängen, und es ist wichtig, dass Sie so viel wie möglich ändern können, wenn Sie neue Funktionen hinzufügen, die Leistung verbessern usw. Wenn alle Ihre Werte öffentlich sind als alle Ihre internen Werte und Mechanismen sind öffentlich. Wenn du sie änderst, kann das andere Klassen beeinträchtigen, die von dir abhängen.

Die zweite ist, dass beim Aussetzen von Variablen andere Klassen Ihre Werte ändern können. Wenn sie Ihre internen Werte ändern, kann dies Ihr Programm beschädigen und seltsames unerwartetes Verhalten verursachen. Wenn Sie ein System erstellen, das auf der genauen Leistung einer Ihrer Klassen beruht und die internen Werte geändert werden, können Sie sich nicht mehr auf dieses System verlassen. Subclassing macht das komplizierter. Ihr System kann sich auf eine Klasse eines bestimmten Typs verlassen, um die erwarteten Aktionen auszuführen.Durch Unterklassenbildung ist es möglich, eine neue Klasse zu erstellen, die den gleichen Typ zu haben scheint, aber nicht die erwarteten Aktionen ausführt.

Wenn Sie zum Beispiel ein Klassenquadrat mit einer geschützten Funktion getArea() haben, erwarten Sie, dass Sie die Fläche eines Quadrats zurückgeben. Es kann jedoch eine neue Klasse gebildet werden, die quadratisch erweitert, etwa Klassenrechteck, Quadrat ausdehnt. Jetzt kann rectange getArea() überschreiben, aber es ist immer noch vom Typ Quadrat, was etwas brechen kann, was von dieser Funktionalität des Quadrats abhängt. Indem Sie Ihre Klasse endgültig machen, behaupten Sie, dass dies in Ihrem System niemals vorkommen kann.

Diese Art der "sicheren Kodierung" wird nicht verhindern, dass jemand Ihren Quellcode sieht, aber es hilft, Ihren Code in Zukunft zuverlässiger und brauchbarer zu machen.

Answer 5

Java ist eine object-oriented programming Sprache, und eines der Schlüsselkonzepte in der objektorientierten Programmierung ist encapsulation.

Die Idee hinter der Kapselung besteht darin, die Implementierungsdetails wie interne Variablen, die den Zustand des Objekts und die internen Abläufe wie Algorithmen enthalten, zu verstecken und nur eine Schnittstelle bereitzustellen, die andere Objekte zur Ausführung verwenden können funktioniert mit dem Objekt.

Mit diesem Konzept möchte man interne Zustände verbergen, indem man private Variablen verwendet, um zu verhindern, dass andere Objekte die internen Zustände direkt beeinflussen. In Java ist es üblich, Getter und Setter (z. B. getColor und setColor) zu sehen, um mit Objekten zu arbeiten.

Auch die Kapselung kann die Robustheit des Codes erhöhen.

Zum Beispiel durch die Beschränkung des Zugriffs auf die internen Zustände, wäre es möglich, vor dem Ändern eines Objekts einige Plausibilitätsprüfungen durchzuführen.

Als festes Beispiel sagen, dass es ein Score Objekt war, das einen percent Wert zwischen 0 und 100 haben war. Durch Bereitstellen einer setPercent(int)-Methode, die bestätigt, dass der angegebene Wert innerhalb des zulässigen Bereichs lag, würde verhindert, dass das Objekt in einen inakzeptablen Zustand versetzt wird.

Also, versuchen direkt den internen Zustand zu manipulieren, indem er eine Anweisung wie score.percent = 150 schreiben könnte verhindert werden, wenn die setPercent Verfahren verursacht einen Fehler oder wirft einen Exception wenn der angegebene Wert nicht akzeptabel ist.

Answer 6

stell dir vor, wenn dein Objekt eine interne Eigenschaft hat, die nicht privat (versteckt) ist und dein Code auf diese Eigenschaft in Multithreading-Umgebung läuft, so würden N Threads gleichzeitig darauf zugreifen, 5 Threads möchten das ändern Eigentum, 4 zu lesen. Es gibt keine Möglichkeit, sicherzustellen, dass die Dinge sauber laufen, keiner der beiden Threads weiß, welche Daten im Moment gespeichert sind und ob die Eigenschaft dieses Objekts erfolgreich geändert wurde.

Sie müssen spezielle Stück Code programmieren, der für synchronen Zugriff verantwortlich sein wird, und trotzdem wird es nicht garantiert, dass Ihr Code richtig funktioniert, da Sie noch den Rest von 680 Klassen in Ihrem Programm auf diese Eigenschaft überprüfen müssen um direkt darauf zugreifen zu können.

Kurz gesagt, sind Sie in einem großen Problem, und das Debuggen ist ein Alptraum, da Sie nicht wissen, wann die Daten chagned wurde, die Gewinde das täte, von wo es passiert usw.

Nur ein Szenario von dem, was passiert, wenn Sie nicht kapseln ...

Gute Sache, Ihr Code läuft 1% schneller, es gibt weniger Last auf Stack, Sie haben wahrscheinlich vernachlässigbare Leistungssteigerungen erreicht, die Sie mit regelmäßigen Abstürzen des Systems und geringen Chancen für erfolgreiches Debugging bezahlen werden.

Answer 7

Der Begriff "sichere Codierung" bezieht sich auf die Konstruktion von Software, die eindeutig versucht, Sicherheitslücken zu vermeiden, sei es in C, Java, Ruby, Assembler oder irgendetwas anderem. Der vielleicht wichtigste Teil davon ist, nach der Auswahl eines sicheren Sprachsystems, gute Programmierpraktiken beizubehalten. Wenn ein Programm unklar ist, haben Sie wenig Chancen, dass es vertrauenswürdig ist.

Für Java gibt es zwei bemerkenswerte Führer:

• Secure Coding Guidelines for the Java Programming Language, version 2.0. vor zwei Jahren aktualisiert, und in der letzten Woche über.
• The CERT Sun Microsystems Secure Coding Standard for Java. Ein neues Wiki, das sowohl von CERT als auch von Sun unterstützt wird und mit dem aktualisiert werden kann, was immer wichtig ist. Dies ist viel breiter als die Sun-Richtlinien. Zum Beispiel sind die Sun-Richtlinien nicht wirklich mit Integer-Überlauf beschäftigt, weil alle Array-Grenzen überprüft werden, aber das Wiki tut, weil es immer noch Programmfehler verursachen kann.

In Java gibt es zwei verschiedene Modi der sicheren Codierung.

In einem Fall handelt es sich um Code, der möglicherweise nicht über alle Berechtigungen verfügt, die Ihr Code bietet. Wenn Sie beispielsweise eine Bibliothek schreiben oder Code signieren, müssen Sie dies tun. Es sollte ausgeschlossen sein, dass bösartiger Code Ihre Berechtigungen in unbeabsichtigter Weise ausnutzt. Das ist schwierig!

Häufiger handelt es sich um Programme, die nur mit nicht vertrauenswürdigen Daten arbeiten. Zum Beispiel, Web-Server (denken XSS und SQL-Injektion) und Desktop-Anwendungsprogramme Umgang mit nicht vertrauenswürdigen Dateien (in der Regel ist das Problem mit C-Code mit Pufferüberläufen - echtes C++ ist besser). In einigen Situationen kann ein Denial-of-Service (DoS) ein schwerwiegendes Problem sein.

Es gibt Überschneidungen. Zum Beispiel laufen Dolmetscher mit den Berechtigungen des Interpreter-Codes und sind möglicherweise ziemlich "mächtig".