Was sind gängige Java-Sicherheitslücken, die ausgenutzt werden können, um Zugang zu einem System zu erhalten? Ich habe in letzter Zeit darüber nachgedacht und konnte mir nicht viel einfallen lassen - Integer Overflow - vielleicht? Race Condition - was gibt es dir?
Ich suche nicht nach Dingen wie "sql-Injektion in einer Web-App". Ich suche nach einer Beziehung ähnlich Pufferüberlauf - c / c ++.
Irgendwelche Sicherheitsexperten da draußen, die helfen können? Danke.
Nachdem ich die meisten Antworten gelesen habe, denke ich, dass Ihre Frage indirekt beantwortet wurde. Ich wollte das nur direkt hervorheben. Java leidet nicht unter den gleichen Problemen, die Sie in C / C ++ sehen, da es den Entwickler vor diesen Arten von Speicherangriffen schützt (Pufferüberlauf, Heap-Überlauf usw.). Diese Dinge können nicht passieren. Da es diesen grundlegenden Schutz in der Sprache gibt, sind Sicherheitslücken im Stapel nach oben gerückt.
Sie treten jetzt auf einer höheren Ebene auf. SQL-Injection, XSS, DOS usw. Sie könnten herausfinden, wie Java bösartigen Code aus der Ferne laden kann. Um dies zu tun, müssten Sie jedoch eine andere Sicherheitslücke auf der Services-Ebene ausnutzen, um Code per Fernzugriff in ein Verzeichnis zu verschieben Dann triggern Sie Java, um es durch einen Klassenlader zu laden. Remote-Angriffe sind theoretisch möglich, aber mit Java ist es schwieriger zu nutzen. Und oft, wenn Sie eine andere Schwachstelle ausnutzen können, warum nicht einfach java aus der Schleife entfernen. Welt schreibbare Verzeichnisse, aus denen Java-Code geladen wird, könnten gegen Sie verwendet werden. Aber an diesem Punkt ist es wirklich Java, das ist das Problem oder Ihr Systemadministrator oder der Anbieter eines anderen Dienstes, der ausnutzbar ist?
Die einzigen Sicherheitslücken, die das Remote-Code-Potenzial auszeichnen, das ich in Java über die Jahre hinweg gesehen habe, stammen aus nativem Code, den die VM lädt. Die libzip-Schwachstelle, die gif-Dateianalyse, usw. Und das waren nur eine Handvoll Probleme. Vielleicht alle 2-3 Jahre. Und wieder ist das vuln nativer Code, der von der JVM nicht in Java-Code geladen wird.
Als Sprache ist Java sehr sicher. Selbst diese Themen, die ich theoretisch diskutieren könnte, haben Haken in der Plattform, um sie zu verhindern. Kennzeichnungscode vereitelt das meiste davon. Sehr wenige Java-Programme laufen jedoch mit installiertem Security Manager. Hauptsächlich wegen der Leistung, der Benutzerfreundlichkeit, aber vor allem, weil diese Schwachstellen bestenfalls sehr begrenzt sind. Das Laden von Remote-Code in Java ist nicht auf epidemische Level gestiegen, die Pufferüberläufe in den späten 90ern / 2000ern für C / C ++ hatten.
Java ist nicht kugelsicher als Plattform, aber es ist schwieriger auszunutzen als die anderen Früchte auf dem Baum. Und Hacker sind opportunistisch und gehen zu dieser niedrig hängenden Frucht.
Schadcode-Injektion.
Da Java (oder eine andere Sprache, die einen Interpreter zur Laufzeit verwendet) zur Laufzeit eine Verbindung herstellt, können die erwarteten JARs (das Äquivalent von DLLs und SOs) zur Laufzeit durch schädliche ersetzt werden.
Dies ist eine Schwachstelle, die seit der ersten Veröffentlichung von Java mit verschiedenen Mechanismen bekämpft wird.
Wenn Sie wissen möchten, warum all dies wichtig ist, stellen Sie sich einen JDBC-Treiber vor, der in den Klassenpfad injiziert wird und alle SQL-Anweisungen und deren Ergebnisse an einen entfernten Drittanbieter übertragen kann. Nun, ich nehme an, Sie bekommen das Bild jetzt.
Ich bin kein Sicherheitsexperte, aber es gibt einige Module in unserer Firma, die wir nicht in Java programmieren können, weil es so einfach ist, Java-Bytecode zu dekompilieren. Wir haben uns die Verschleierung angesehen, aber wenn Sie eine echte Verschleierung wünschen, kommt es nur mit einer Menge von Problemen (Performance-Hit / Verlust von Debug-Informationen) Man könnte unsere Logik stehlen, das Modul durch eine modifizierte Version ersetzen, die falsche Ergebnisse zurückgibt usw. ...
Im Vergleich zu C / C ++ denke ich, dass dies eine "Verwundbarkeit" ist, die auffällt.
Wir haben auch einen Softwarelizenz-Mechanismus in unseren Java-Modulen eingebaut, aber dieser kann auch leicht durch das Kompilieren und Ändern des Codes gehackt werden.
Das Einschließen von Klassendateien von Drittanbietern und das Aufrufen von ihnen bedeutet grundsätzlich, dass Sie unsicheren Code ausführen. Dieser Code kann alles tun, was er möchte, wenn Sie die Sicherheit nicht aktiviert haben.