Im Gegensatz zu den meisten Schwachstellen in den OWASP-API-Top-Ten geht es bei der unsachgemäßen Verwaltung von Assets nicht speziell um Kodierungsfehler. Stattdessen handelt es sich bei dieser Schwachstelle eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs auch dann noch verwendet werden, wenn sie längst durch neuere, sicherere Versionen hätten ersetzt werden müssen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt werden, bevor sie vollständig gegen Bedrohungen abgesichert sind.

Diese Schwachstelle ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell in Betrieb genommen werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und nie außer Betrieb genommen werden. Wenn die älteren APIs mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.

Möchten Sie eine gamifizierte Herausforderung zu diesem Sicherheitsproblem ausprobieren? Betreten Sie unsere Arena: [Hier starten]

Wie wirken sich unsachgemäße Mängel in der Vermögensverwaltung auf APIs aus?

Der Makel des falschen Asset-Managements ist ein Produkt der modernen Zeit. Organisationen, die sich mit der Geschwindigkeit des Geschäfts bewegen, können manchmal hunderte oder tausende von Services und Microservices pro Tag aufsetzen. Dies geschieht oft schnell und ohne die Erstellung einer begleitenden Dokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie kritisch sie sind. Dies kann schnell zu einem API-Wildwuchs führen, der mit der Zeit nicht mehr zu bändigen ist, vor allem, wenn es keine pauschalen Richtlinien gibt, die festlegen, wie lange APIs existieren dürfen.

In dieser Umgebung ist es sehr gut möglich, dass einige APIs verloren gehen, in Vergessenheit geraten oder nie außer Betrieb genommen werden.

Auch Benutzer mit der Berechtigung, neue Dienste außerhalb des normalen Prozesses zu erstellen, sind manchmal schuld. Zum Beispiel könnte eine Marketinggruppe einen Dienst erstellen, um ein bevorstehendes Ereignis wie eine Produkteinführung zu unterstützen, und ihn dann nie wieder zurücknehmen, nachdem das Ereignis abgeschlossen ist. Jemand, der sich diesen Dienst und die zugehörigen APIs später ansieht, hat vielleicht keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich vielleicht nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie kritisch sie sind oder was sie tun.

Die Schwachstelle wird gefährlich, weil sich die Sicherheit von APIs in Frameworks mit der Zeit verbessert. Ein Forscher könnte eine Schwachstelle entdecken, oder es könnte zusätzliche Sicherheit hinzugefügt werden, um eine zunehmend beliebte Art von Angriffen zu stoppen. Ältere APIs können für diese Angriffe anfällig bleiben, wenn sie nicht aktualisiert werden, sodass Hacker oft nach ihnen suchen oder automatisierte Tools verwenden, um sie aufzuspüren.

In einem realen Beispiel, das von OWASP zur Verfügung gestellt wurde, aktualisierte ein Unternehmen seine APIs, die zum Durchsuchen von Benutzerdatenbanken verwendet werden, um eine kritische Schwachstelle zu beheben. Die alten APIs wurden jedoch versehentlich beibehalten.

Ein Angreifer bemerkte, dass der Speicherort der neuen API in etwa (api.criticalservice.com/v2) lautete. Durch Ersetzen der URL mit (api.criticalservice.com/v1) konnten sie stattdessen die alte API mit der bekannten Schwachstelle verwenden. Dadurch wurden letztlich die persönlichen Daten von über 100 Millionen Benutzern offengelegt.

Beseitigung von Fehlern in der Vermögensverwaltung

Die einzige Möglichkeit, den Fehler der unsachgemäßen Verwaltung von Assets in Ihrer Umgebung zu beseitigen, besteht darin, ein genaues Inventar aller APIs, ihrer Verwendung und Versionen zu führen. Dies sollte mit einer Inventarisierung der vorhandenen APIs beginnen und sich auf Faktoren konzentrieren, wie z. B. in welcher Umgebung sie eingesetzt werden sollen, wie Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben soll und natürlich ihre Version.

Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem die Dokumentation automatisch zu allen neuen APIs oder Diensten hinzugefügt wird, die erstellt werden. Dies sollte alle Aspekte der API umfassen, einschließlich der Ratenbegrenzung, der Behandlung von Anfragen und Antworten, der gemeinsamen Nutzung von Ressourcen, der Endpunkte, mit denen eine Verbindung hergestellt werden kann, sowie aller relevanten Richtlinien, die für eine spätere Prüfung erforderlich sind. Sie sollten auch vermeiden, jemals nicht produktive APIs oder solche aus der Entwicklungsumgebung in der Produktion zu verwenden. Ziehen Sie auch in Erwägung, eine zeitliche Begrenzung für APIs einzuführen, bei der ihre weitere Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.

Wann immer neue Versionen aktiver APIs verfügbar werden, führen Sie ein Risiko assessment durch, um festzustellen, ob Sie ein Upgrade durchführen sollten und wie dieser Prozess ablaufen sollte, um eine Unterbrechung der Produktionsumgebung zu vermeiden. Sobald Sie auf die neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.

Wenn Sie all das tun, können Sie verhindern, dass die unsachgemäße Verwaltung von Assets Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk Schaden zufügt. Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.

‍

In einem früheren Blog-Beitrag wurde das Java-Gotcha "Bitwise vs. Boolean Operator" beschrieben.

• Java Gotchas - Bitweiser vs. Boolescher Operator

Wir haben eine Variante davon und einige andere Java-Gotchas in ein lustiges kleines Quiz namens "Challenge The Sensei" eingebaut.

• scw.typeform.com/to/rgw7q7OE

Wenn Sie den obigen Blog-Beitrag gelesen haben, sind Sie in einer guten Position, um zumindest eine der Fragen zu beantworten.

Aber Ihre Freunde vielleicht nicht. Wenn Sie das Quiz also lustig finden, können Sie es mit ihnen teilen und sehen, ob sie genauso gut abschneiden wie Sie.

Denn wir wollen Sie nicht nur abfragen. Wir wollen versuchen, damit zu helfen, das Wissen zu vermitteln und zu kodifizieren. Deshalb haben wir ein Github-Repositorium erstellt, das lauffähige Code-Beispiele für das Problem und die Lösung enthält.

• github.com/SecureCodeWarrior/challenge-the-sensei

Dies ist eine Sensei freigegebene Repo.

Wenn Sie das Repo klonen und in IntelliJ laden, vorausgesetzt, Sie haben das Secure Code Warrior Sensei IntelliJ-Plugin installiert haben, dann wird es automatisch erkennen, dass Sie einen Ordner .sensei haben, und die Rezepte Sensei laden.

Wenn Sie den Code in der IDE durchsuchen, sollte IntelliJ Sie darauf hinweisen, dass der Fehler im Code vorhanden ist, und dies sollte es einfacher machen, den Fehler im Code zu erkennen:

• Bewegen Sie den Mauszeiger über den hervorgehobenen Code, dann wird eine Aufforderung angezeigt, die Sie über den Fehler informiert
• Verwenden Sie die Taste "Show Context Action": alt+enter (Windows) option+enter (macOS) und wir haben möglicherweise einen QuickFix verfügbar, der den Code beheben kann.

Sensei Rezepte wurden hinzugefügt für:

• Bitweise Operatoren
• IP-Adresse teilen
• Auftrag bestätigen

Wir fügen in Zukunft weitere Rezepte und erklärenden Text hinzu, um den Rest des Codes abzudecken... aber lassen Sie sich davon nicht davon abhalten, einen Blick auf den Code zu werfen und den Fehler selbst zu entdecken.

Und vergessen Sie nicht, das Quiz auszuprobieren und"die Senseiherauszufordern".

Java Gotchas - Bitweise vs. Boolesche Operatoren

> "Java Gotcha" - ein häufiges Fehlermuster, das sich leicht versehentlich implementieren lässt.

Ein recht einfaches Java-Gotcha, in das man versehentlich hineinfallen kann, ist: die Verwendung eines Bitwise-Operators anstelle eines booleschen Vergleichsoperators.

z. B. kann ein einfacher Tippfehler dazu führen, dass Sie "&" schreiben, obwohl Sie eigentlich "&&" schreiben wollten.

Eine gängige Heuristik, die wir beim Überprüfen von Code lernen, ist:

> "&" oder "|" bei Verwendung in einer bedingten Anweisung ist wahrscheinlich nicht beabsichtigt.

In diesem Blog-Beitrag werden wir die Heuristik untersuchen und Wege aufzeigen, wie wir dieses Kodierungsproblem identifizieren und beheben können.

Wo liegt das Problem? Bitweise Operationen funktionieren gut mit Booleans

Die Verwendung von Bitwise-Operatoren mit Booleschen Operatoren ist durchaus zulässig, so dass Java keinen Syntaxfehler meldet.

Wenn ich einen JUnit-Test konstruiere, um eine Wahrheitstabelle sowohl für Bitweises ODER (|) als auch Bitweises UND (&) zu untersuchen, dann werden wir sehen, dass die Ausgaben des Bitweisen Operators mit der Wahrheitstabelle übereinstimmen. Angesichts dessen könnte man meinen, dass die Verwendung von Bitwise-Operatoren kein Problem darstellt.

AND-Wahrheitstabelle

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

Der Test ist bestanden, dies ist vollkommen gültiges Java.

OR-Wahrheitstabelle

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

Auch dieser Test besteht, warum bevorzugen wir "&&'und "||'?

Wahrheitstabellenbilder wurden mit dem Wahrheitstabellen-Werkzeug von web.standfor.edu.

Problem: Kurzschlussbetrieb

Das eigentliche Problem ist der Unterschied im Verhalten zwischen bitweisen (&, |) und booleschen (&&, ||) Operatoren.

Ein boolescher Operator ist ein Kurzschlussoperator und wertet nur so viel aus, wie er muss.

z.B.

if (args != null & args.length() > 23) {
    System.out.println(args);
}

Im obigen Code werden beide booleschen Bedingungen ausgewertet, da der Bitwise-Operator verwendet wurde:

• args != null
• args.length() > 23

Das lässt meinen Code offen für eine NullPointerException, wenn args null ist, weil wir immer die Prüfung für args.length durchführen, auch wenn args null ist, weil beide booleschen Bedingungen ausgewertet werden müssen.

Boolesche Operatoren Kurzschlussauswertung

Wenn ein && verwendet wird, z. B.

if (args != null && args.length() > 23) {
    System.out.println(args);
}

Sobald wir wissen, dass args != null zu false ausgewertet wird, stoppt die Auswertung des Bedingungsausdrucks.

Die rechte Seite brauchen wir nicht auszuwerten.

Unabhängig vom Ergebnis der Bedingung auf der rechten Seite ist der Endwert des booleschen Ausdrucks falsch.

Aber das würde im Produktionscode nie passieren

Dies ist ein ziemlich leicht zu begehender Fehler, der nicht immer von statischen Analysetools erkannt wird.

Ich habe den folgenden Google Dork verwendet, um zu sehen, ob ich irgendwelche öffentlichen Beispiele für dieses Muster finden kann:

filetype:java if "!=null & "
Diese Suche brachte etwas Code von Android im RootWindowContainer
isDocument = intent != null & intent.isDocument()

Dies ist die Art von Code, die eine Codeprüfung bestehen könnte, weil wir oft Bitwise-Operatoren in Zuweisungsanweisungen verwenden, um Werte zu maskieren. Aber in diesem Fall ist das Ergebnis das gleiche wie im obigen Beispiel der if-Anweisung. Wenn intent jemals null ist, dann wird eine NullPointerException geworfen.

Sehr oft kommen wir mit diesem Konstrukt davon, weil wir oft defensiv codieren und redundanten Code schreiben. Die Prüfung auf != null mag in den meisten Anwendungsfällen durchaus redundant sein.

Dies ist ein Fehler, der von Programmierern im Produktionscode gemacht wird.

Ich weiß nicht, wie aktuell die Ergebnisse für die Suche sind, aber als ich die Suche ausgeführt habe, gab es Ergebnisse zurück mit Code von: Google, Amazon, Apache... und mir.

Eine kürzliche Pull-Anfrage in einem meiner Open-Source-Projekte sollte genau diesen Fehler beheben.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

Wie Sie das finden

Als ich meinen Beispielcode in ein paar statischen Analysatoren überprüft habe, hat keiner von ihnen diesen versteckten Selbstzerstörungscode gefunden.

Als Team auf Secure Code Warrior haben wir ein recht einfaches Sensei Rezept erstellt und überprüft, das dies auffangen kann.

Da Bitwise-Operatoren durchaus zulässig sind und häufig in Zuweisungen verwendet werden, haben wir uns auf den Anwendungsfall von if-Anweisungen und die Verwendung von Bitwise & konzentriert, um den problematischen Code zu finden.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

Hier wird ein regulärer Ausdruck verwendet, um mit " & " übereinzustimmen, wenn er als Bedingungsausdruck verwendet wird. z. B. in einer if-Anweisung.

Um das zu beheben, haben wir wieder auf reguläre Ausdrücke zurückgegriffen. Diesmal mit der sed-Funktion im QuickFix, um das & im Ausdruck global durch && zu ersetzen.

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Ende Anmerkungen

Dies deckt den häufigsten Missbrauch eines Bitwise-Operators ab, d. h. wenn eigentlich ein boolescher Operator beabsichtigt war.

Es gibt andere Situationen, in denen dies auftreten könnte, z. B. das Zuordnungsbeispiel, aber beim Schreiben von Rezepten müssen wir versuchen, eine falsch-positive Identifizierung zu vermeiden, sonst werden Rezepte ignoriert oder ausgeschaltet. Wir erstellen Rezepte, die den häufigsten Vorkommnissen entsprechen. Wenn sich Sensei weiterentwickelt, werden wir möglicherweise zusätzliche Spezifität in die Suchfunktion einbauen, um mehr passende Bedingungen abzudecken.

In seiner aktuellen Form würde dieses Rezept viele der Live-Anwendungsfälle identifizieren, und vor allem den, der in meinem Projekt berichtet wurde.

HINWEIS: Eine ganze Reihe von Code-Kriegern hat zu diesem Beispiel und der Rezeptüberprüfung beigetragen - Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. Vielen Dank für Ihre Hilfe.

---

Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.

Wir haben eine Menge Quellcode und Rezepte für diese Blog-Beiträge (einschließlich dieses Beitrags) im `sensei-blog-examples`-Repository im Secure Code Warrior GitHub-Konto.

https://github.com/securecodewarrior/sensei-blog-examples

Erfahren Sie mehr über Sensei

Was ist statische Analyse?

Statische Analyse ist die automatisierte Analyse von Quellcode, ohne dass die Anwendung ausgeführt wird.

Wenn die Analyse während der Programmausführung durchgeführt wird, spricht man von einer dynamischen Analyse.

Die statische Analyse wird häufig zur Erkennung verwendet:

• Sicherheitsschwachstellen.
• Leistungsprobleme.
• Nichteinhaltung von Normen.
• Verwendung von veralteten Programmierkonstrukten.

Wie funktioniert ein Werkzeug zur statischen Analyse?

Das Grundkonzept, das allen Werkzeugen für die statische Analyse gemeinsam ist, besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, mit denen eine Art von Warnung oder Information verbunden ist.

Dies könnte so einfach sein wie "JUnit 5-Testklassen müssen nicht 'public' sein". Oder etwas Komplexes wie "Untrusted String input being used in an SQL execution statement".

Statische Analyse-Tools unterscheiden sich darin, wie sie diese Funktionalität implementieren.

• Quellcode-Parsing-Technologie, um einen Abstract Syntax Tree (AST) zu erstellen,
• Text Regular Expression Matching,
• eine Kombination aus den oben genannten Möglichkeiten.

Der Abgleich mit regulären Ausdrücken auf Text ist sehr flexibel, es ist einfach, Regeln für den Abgleich zu schreiben, aber es kann oft zu einer Menge falsch positiver Ergebnisse führen und die Abgleichsregeln kennen den umgebenden Code-Kontext nicht.

Der AST-Abgleich behandelt den Quellcode als Programmcode und nicht nur als Dateien, die mit Text gefüllt sind. Dies ermöglicht einen spezifischeren, kontextbezogenen Abgleich und kann die Anzahl der falsch-positiven Meldungen für den Code reduzieren.

Statische Analyse in der kontinuierlichen Integration

Die statische Analyse wird häufig während des Continous Integration (CI)-Prozesses durchgeführt, um einen Bericht über Compliance-Probleme zu erstellen, der überprüft werden kann, um eine objektive Ansicht der Code-Basis im Laufe der Zeit zu erhalten.

Manche Leute verwenden die statische Analyse als objektives Maß für ihre Codequalität, indem sie das statische Analysewerkzeug so konfigurieren, dass es nur bestimmte Teile des Codes misst und nur über eine Teilmenge von Regeln berichtet.

Die Objektivität ist durch die verwendeten Regeln gegeben, da diese sich in ihrer Bewertung des Codes im Laufe der Zeit nicht verändern. Natürlich ist die Kombination der verwendeten Regeln und ihre Konfiguration eine subjektive Entscheidung und verschiedene Teams entscheiden sich dafür, zu verschiedenen Zeiten unterschiedliche Regeln zu verwenden.

Die Durchführung der statischen Analyse in CI ist nützlich, kann aber das Feedback an den Programmierer verzögern. Programmierer erhalten kein Feedback während des Codierens, sondern erst später, wenn der Code durch das Static Analysis-Tool gelaufen ist. Ein weiterer Nebeneffekt der Ausführung der statischen Analyse in CI ist, dass die Ergebnisse leichter zu ignorieren sind.

Um die Teams dazu zu bringen, den Ergebnissen der statischen Analyse mehr Aufmerksamkeit zu schenken, ist es in der Regel möglich, eine Schwellenwert-Metrik im Build-Prozess zu konfigurieren, um den Build fehlschlagen zu lassen, wenn die Metrik überschritten wird, z.B. wenn eine Anzahl von Regeln ausgelöst wird.

Statische Analyse in der IDE

Um schnelleres Feedback zu erhalten, gibt es viele IDE-Plugins, die die Regeln der statischen Analyse in der IDE bei Bedarf oder in regelmäßigen Abständen ausführen, wenn sich der Code ändert.

Die Regelverletzungen können dann in der IDE gesehen werden, während der Programmierer Code schreibt, und um die Regeln schwerer zu ignorieren, können die Verletzungen oft so konfiguriert werden, dass sie als unterstrichener Code im Editor dargestellt werden.

Ich persönlich finde dies eine nützliche Methode, um mein Coding zu verbessern, besonders wenn ich mit einer neuen Bibliothek arbeite, die vom Static Analysis Tool abgedeckt wird. Allerdings kann es "verrauscht" sein mit falsch-positiven Ergebnissen oder Regeln, an denen man nicht interessiert ist. Aber das wird gelöst, indem man den zusätzlichen Schritt unternimmt, das Static Analysis Tool so zu konfigurieren, dass bestimmte Regeln ignoriert werden.

Code auf der Grundlage von Regeln der statischen Analyse korrigieren

Bei den meisten Werkzeugen für die statische Analyse wird die Behebung der Regel dem Programmierer überlassen, d. h. er muss die Ursache der Regelverletzung verstehen und wissen, wie er sie beheben kann.

Nur sehr wenige statische Analysewerkzeuge bieten auch die Möglichkeit, die Verstöße zu beheben, weil die Behebung so oft kontextabhängig vom Team und der verwendeten Technologie sowie den vereinbarten Codierungsstilen ist.

Standardregeln

Falsches Vertrauen in die Qualität der Regeln kann entstehen, wenn die Werkzeuge für die statische Analyse mit Standardregeln geliefert werden. Es ist verlockend zu glauben, dass sie alle Probleme abdecken, die einem Programmierer begegnen könnten, und alle Umstände, unter denen die Regel gelten sollte. Manchmal können die Umstände, unter denen eine Regel angewendet werden sollte, subtil sein und sind möglicherweise nicht leicht zu erkennen.

Die Hoffnung ist, dass Programmierer durch die Verwendung eines Werkzeugs für die statische Analyse und die genauere Untersuchung der Regeln und Verstöße die Fähigkeit entwickeln, das Problem im Kontext ihrer spezifischen Domäne zu erkennen und zu vermeiden.

Wenn die Domäne kontextabhängige Regeln erfordert, verfügen die Werkzeuge für die statische Analyse möglicherweise nicht über Regeln, die zu Ihrer Domäne oder Bibliothek passen, und außerdem sind die Werkzeuge oft schwierig zu konfigurieren und zu erweitern.

Belästigungen

Keines dieser "Ärgernisse" ist unüberwindbar:

• Falschmeldungen
• fehlende Fixes
• Konfiguration zum Ignorieren von Regeln
• Hinzufügen von kontextspezifischen Regeln

Aber sie werden oft als Ausrede benutzt, um den Einsatz von Statik-Analyse-Tools überhaupt zu vermeiden, was schade ist, weil der Einsatz von Statik-Analyse enorm nützlich sein kann, als eine Möglichkeit,:

• bessere Ansätze für Junior-Entwickler aufzeigen
• schnelles Feedback zu eindeutigen Kodierverstößen erhalten
• unklare Probleme identifizieren, auf die der Programmierer noch nicht gestoßen ist
• bestätigen, dass der Programmierer einen guten Kodierungsansatz gewählt hat (wenn keine Verstöße gemeldet werden)

IDE-basierte Werkzeuge für die statische Analyse

Als einzelner Mitarbeiter an einem Projekt verwende ich gerne Tools für die statische Analyse, die innerhalb der IDE ausgeführt werden, damit ich schnelles Feedback zu meinem Code erhalte.

Dies ergänzt jeden Pull-Request-Überprüfungsprozess und die CI-Integration, die ein Projekt haben kann.

Ich versuche, Tools zu identifizieren, die mir einen Vorteil verschaffen und meinen individuellen Workflow verbessern.

Wenn Werkzeuge in der IDE laufen, kann es verlockend sein, sie als austauschbar zu betrachten, da sie in der Regel die gleiche grundlegende Benutzeroberfläche und den gleichen Konfigurationsansatz haben.

Die Tools können sich in ihrer Funktionalität oder ihren Regelsätzen überschneiden, aber um einen maximalen Vorteil zu erzielen, installiere ich mehrere Tools, um die Stärken der einzelnen Tools zu nutzen.

Die IDE-Tools für die statische Analyse, die ich beim Codieren aktiv verwende, sind unten aufgeführt:

• die eingebauten IntelliJ Inspections - häufige Codierungsmuster
• SpotBugs - häufige Fehler
• SonarLint - häufige Verwendungsmuster
• CheckStyle - allgemeine Stilmuster
• Sensei von Secure Code Warrior - Erstellung eigener Regeln

Ich verwende sie alle, weil sie gut zusammenarbeiten und sich gegenseitig ergänzen.

IntelliJ-Prüfungen

Wenn Sie IntelliJ verwenden, dann verwenden Sie bereits deren Inspektionen.

Dies sind Regeln für die statische Analyse, die in der IDE gekennzeichnet werden. Einige von ihnen haben auch QuickFix-Optionen, um den Code neu zu schreiben, um das Problem zu beheben.

Die Regeln können ein- und ausgeschaltet werden, und es kann die Fehlerstufe gewählt werden, mit der sie in der IDE hervorgehoben werden sollen.

Es gibt eine Menge guter IntelliJ Inspektionen. Ich weiß das, weil ich sie durchgelesen habe, während ich dies schrieb. Ich verwende die IntelliJ Inspections als Standard und habe sie nicht konfiguriert, aber um den vollen Nutzen aus den Inspections zu ziehen, sollten Sie sie durchlesen, diejenigen identifizieren, die für Ihren Codierungsstil relevant sind, und die Warnstufe so konfigurieren, dass Sie sie im Code bemerken.

Das Tolle an den IntelliJ Inspections ist, dass sie kostenlos mit der IDE mitgeliefert werden und helfen, das Muskelgedächtnis von:

• Warnungen und Fehler im Quelltext beim Schreiben von Code bemerken
• Bewegen Sie die Maus über markierten Code, um die Regelverletzungen zu erfahren
• mit alt+enter einen QuickFix für das Problem anwenden

SpotBugs

Das SpotBugs IntelliJ-Plugin verwendet die statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

SpotBugs kann in den IntelliJ-Voreinstellungen konfiguriert werden, um Ihren Code zu scannen, die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte "Detector".

Ich neige dazu, SpotBugs zu verwenden, nachdem ich meinen Code geschrieben und überprüft habe, dann führe ich die Funktion 'Analyze Project Files Including Test Sources' aus.

Dies hilft mir, Fehler, toten Code und offensichtliche Optimierungen zu identifizieren. Es zwingt mich auch dazu, einige der markierten Verstöße zu untersuchen, um zu entscheiden, was zu tun ist.

SpotBugs findet zwar Probleme, bietet aber keine QuickFix-Aktionen an, um zu versuchen, die Probleme zu beheben.

SpotBugs ist einfach zu konfigurieren und ich finde, dass es eine nützliche objektive zweite Meinung ist, die ich in meiner IDE zu Rate ziehen kann.

SonarLint

Das SonarLint-Plugin.

SonarLint kann in den IntelliJ-Voreinstellungen konfiguriert werden, um auszuwählen, gegen welche Regeln der Code validiert werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme für den aktuellen Code an, den Sie gerade bearbeiten.

SonarLint bietet keine schnellen Lösungen an, aber die Dokumentation, die mit den Verletzungsberichten verbunden ist, ist normalerweise klar und gut dokumentiert.

Ich habe SonarLint in der Vergangenheit als nützlich empfunden, um mich auf neue Java-Funktionen aufmerksam zu machen, die mir in den neueren Versionen von Java bekannt waren.

CheckStyle

Das CheckStyle-Plugin bietet eine Mischung aus Formatierungs- und Code-Qualitätsregeln.

Das CheckStyle-Plugin wird zusammen mit 'Sun Checks' und 'Google Checks' ausgeliefert.

Die Definitionen dieser können leicht online gefunden werden.

CheckStyle bringt den größten Mehrwert, wenn ein Projekt die Zeit damit verbracht hat, sein eigenes Ruleset zu erstellen. Dann kann das IDE-Plugin so konfiguriert werden, dass es dieses Ruleset verwendet, und die Programmierer können einen Scan durchführen, bevor sie den Code an CI übergeben.

CheckStyle wird sehr häufig als Build-Failing-Plugin für CI-Prozesse eingesetzt, wenn die Anzahl der CheckStyle-Verstöße einen Schwellenwert überschreitet.

Sensei

Sensei verwendet eine statische Analyse, die auf einem abstrakten Syntaxbaum (AST) basiert, um Code abzugleichen und QuickFixes zu erstellen; dies ermöglicht eine sehr spezifische Identifizierung von Code mit Problemen.

Der AST ermöglicht es QuickFixes, die mit einem Rezept verbunden sind, den umgebenden Code zu verstehen, z. B. wenn eine neue Klasse in den Code eingefügt wird, wird jeder Import für diese Klasse nur einmal in die Quelldatei eingefügt und nicht für jede Ersetzung.

Sensei wurde entwickelt, um die Erstellung von benutzerdefinierten Abgleichsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht existieren oder nur schwer zu konfigurieren wären. 

Anstatt eine Konfigurationsdatei zu ändern, kann die gesamte Konfiguration in der GUI vorgenommen werden. Bei der Erstellung neuer Rezepte ist in der GUI leicht zu erkennen, zu welchem Code das Rezept passt. Und bei der Definition der QuickFixes kann der Vorher- und Nachher-Zustand des Codes sofort verglichen werden. Das macht es einfacher, sehr kontextbezogene Rezepte zu erstellen, d.h. einzigartig für Teams oder Technologien und sogar für einzelne Programmierer.

Ich verwende Sensei in Kombination mit anderen Tools für die statische Analyse, z. B. finden die meisten Tools für die statische Analyse Probleme, beheben sie aber nicht. Ein häufiger Anwendungsfall für Sensei ist, die passende Suche des anderen Tools in Sensei zu replizieren und mit einem Quick Fix zu erweitern. Dies hat den Vorteil, dass die angewandte benutzerdefinierte Korrektur bereits die Codierungsstandards für Ihr Projekt erfüllt.

Ich ertappe mich regelmäßig dabei, dass ich Sensei Rezepte erstelle, die bereits im IntelliJ Intensions-Set existieren, weil der Intension-Bericht nicht ganz zu dem von mir erstellten Kontext passt oder weil der von IntelliJ bereitgestellte QuickFix nicht zu dem Codemuster passt, das ich verwenden möchte.

Ich ergänze die vorhandenen Werkzeuge, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei kann auch sehr nützlich sein, wenn Sie eine kontextabhängige Variante einer allgemeinen Regel identifizieren, z. B. wenn Sie eine SQL-Bibliothek verwenden, die vom Static Analysis-Tool nicht unterstützt wird, aber die allgemeinen SQL-Regeln in der Static Analysis-Engine trotzdem gelten, dann können Sie mit Sensei bibliotheksspezifische Varianten dieser Regeln erstellen.

Sensei kommt nicht mit vielen generischen Rezepten wie die erwähnten Static Analysis Tools, seine Stärke liegt in der einfachen Erstellung neuer Rezepte, komplett mit QuickFixes, die so konfiguriert sind, dass sie zu Ihrem spezifischen Codierungsstil und Ihren Anwendungsfällen passen.

HINWEIS: Wir arbeiten an einem öffentlichen Repository mit Rezepten, die allgemeine Anwendungsfälle abdecken. Sie können es hier finden.

Zusammenfassung

Ich neige dazu, Tools auszuwählen, die zusammenarbeiten, konfigurierbar sind und sich leicht erweitern lassen, um meinem spezifischen Kontext gerecht zu werden. Ich verwende seit Jahren Werkzeuge zur statischen Analyse in der IDE, um Probleme zu identifizieren und mehr über die verwendeten Programmiersprachen und Bibliotheken zu erfahren.

Ich verwende alle genannten Werkzeuge in Kombination:

• IntelliJ Intentions hilft, häufige Code-Probleme sofort zu erkennen, oft mit zugehörigen QuickFixes.
• SpotBugs findet einfache Bugs, die ich vielleicht übersehen habe, und macht mich auf Leistungsprobleme aufmerksam.
• SonarLint identifiziert Java-Funktionen, die ich nicht kannte, und weist mich auf zusätzliche Möglichkeiten zur Modellierung meines Codes hin.
• CheckStyle hilft mir, einen vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
• Sensei hilft mir bei der Erstellung von QuickFixes, um häufige Szenarien zu ergänzen, die von Werkzeugen für die statische Analyse gefunden werden, und um spezifische Projekt- oder Technologierezepte zu erstellen, die in einem anderen Werkzeug schwer zu konfigurieren sind.

---

Installieren Sie Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) und suchen Sie dann einfach nach "sensei secure code".

Sie finden ein Repository mit Beispielcode und Rezepten für häufige Anwendungsfälle im Secure Code Warrior GitHub-Konto, im Projekt `sensei-blog-examples`.

https://github.com/securecodewarrior/sensei-blog-examples

Erfahren Sie mehr über Sensei

Das Sensei Projekt selbst hat seine eigene Reihe von Rezepten, die sich im Laufe der Zeit aufgebaut haben. Dieser Blog-Beitrag ist ein Beispiel für eines der Szenarien, für die das Sensei -Team ein Rezept erstellt hat. Eine Fehlkonfiguration von Guice, die dazu führte, dass zur Laufzeit beim Testen eine NullPointerException gemeldet wurde.

Dies kann auf viele Dependency-Injection-Szenarien verallgemeinert werden, in denen der Code syntaktisch korrekt ist, aber aufgrund einer falschen Konfiguration der Verdrahtung ein Fehler durchschlüpft.

Das passiert oft, wenn wir die Technologie lernen, und wir machen immer wieder den einfachen Fehler, dass wir vergessen, Dinge zu verdrahten. Aber das passiert auch erfahrenen Profis, denn, nun ja... wir alle machen Fehler, und wir haben vielleicht keine Unit-Tests, die alles abdecken.

Laufzeitausnahmen durch fehlerhafte Dependency Injection-Verdrahtung

Der folgende Code schlägt zur Laufzeit mit einer NullPointerException fehl.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

Der Code ist syntaktisch korrekt, schlägt aber fehl, weil wir eine requestStaticInjection in unserer SystemOutModule-Konfiguration ausgelassen haben.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

Wenn wir versuchen, den mit dem Injector erstellten Reporter zu verwenden, wird er nicht vollständig instanziiert und wir erhalten eine NullPointerException, wenn wir reportThisMany aufrufen.

Es kann gut sein, dass wir das in unserem Code-Review übersehen haben, oder wir hatten keine Unit-Tests, die die Dependency Injection ausgelöst haben, und es ist in unserem Build herausgerutscht.

‍

Warnschilder

In diesem Fall gibt es ein Warnzeichen, der CountReporter hat ein statisches Feld, das mit @Inject annotiert ist, aber... die CountReporter-Klasse selbst ist package private.

In einer komplizierten Codebasis könnte dies ein Warnzeichen dafür sein, dass der Code nicht korrekt ist, da die Modulklasse, die die Bindungen konfiguriert, im selben Paket sein muss, damit dies funktioniert.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

Ein weiterer Fehler, der uns unterlaufen ist und den wir vielleicht bei einer Codeüberprüfung festgestellt haben, ist, dass wir vergessen haben, die Felder in der Konfigurationsmethode des SystemOutModule tatsächlich zu binden.

binder().requestStaticInjection(CountReporter.class);

Hätten wir den requestStaticInjection-Code geschrieben, dann hätte uns der Syntaxfehler, der beim Versuch, den CountReporter zu verwenden, generiert wird, auf den einfachen Fehler aufmerksam gemacht.

> 'reporters.CountReporter' ist nicht öffentlich in 'reporters'. Kann nicht von außerhalb des Pakets aufgerufen werden

‍

Traurig. Wir haben es vergessen, und es gab keine syntaktischen Warnzeichen im Code.

Wie kann Sensei helfen?

Wir würden wahrscheinlich nicht Sensei verwenden, um die fehlende requestStaticInjection zu übernehmen, da alle unsere Guice-Konfigurationsverdrahtungen diese Methode verwenden müssten, und wir können nicht garantieren, dass alle Verdrahtungen so einfach sein werden wie dieser Anwendungsfall.

Wir könnten eine Sensei Regel schreiben, um nach einigen Warnzeichen zu suchen, dass unser Code nicht den Anforderungen entspricht.

In diesem Fall würde das bedeuten:

• Suchen Sie alle Klassen mit @Inject-kommentierten Feldern
• Wo die Klassen nicht öffentlich sind.

Das oben genannte war das Warnzeichen, dass sie wahrscheinlich nicht verkabelt waren.

Indem wir ein Rezept erstellen, haben wir ein Warnzeichen in einem frühen Stadium, während der Codierung, und reduzieren die Abhängigkeit von unseren Pull-Requests oder der Lösung unserer Tech Debt, damit wir Unit Tests hinzufügen können.

Wie erstellt man ein Rezept?

Die Aufgabe, die ich erledigen möchte, ist:

• Erstellen eines Rezepts, das mit @Inject annotierte Felder abgleicht, die sich in geschützten privaten Klassen befinden

Das sollte uns hoffentlich genug Warnung geben, um alle Module zu identifizieren, die dies verwenden, und den fehlenden Verdrahtungscode hinzuzufügen.

In meiner CountReporter-Klasse werde ich mit Alt+Enter ein neues Rezept erstellen und bei Null anfangen

Ich werde dies benennen und eine Beschreibung hinzufügen:

Name: Guice: Injected Field Not Public
Beschreibung: Wenn das Injected-Feld nicht öffentlich ist, ist der Code möglicherweise nicht verdrahtet
Level: Warnung

Die Suche, die ich schreibe, sucht nach einer Klasse mit einem Feld, das als Inject annotiert ist, aber nicht als public gescoped wurde.

search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"

Fix

Der QuickFix im Rezept ändert die injizierte Klasse, indem er den Bereich ändert. Aber das ist nicht der einzige Code, den ich ändern muss.

availableFixes:

- name: "Klasse auf public ändern. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"

Wenn das Rezept ausgelöst wird, muss ich noch einen manuellen Schritt in meinem Code durchführen, indem ich die Zeile mit requestStaticInjection hinzufüge, um das Objekt vollständig zu instanziieren.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

Ich könnte möglicherweise ein weiteres Rezept schreiben, um dies aufzugreifen. Ich würde das wahrscheinlich nicht tun, es sei denn, das Vergessen, die statische Injektion hinzuzufügen, wird zu einem halbwegs regelmäßigen Fehler, den ich beim Kodieren mache.

‍

Zusammenfassung

Wenn wir jemals einen Fehler mit einem häufigen Grundmuster machen, dann kann Sensei helfen, das Wissen um die Erkennung und Behebung des Problems zu kodifizieren, und dann wird es hoffentlich nicht durch die Code-Reviews und in die Produktion rutschen.

Manchmal identifizieren die Rezepte, die wir schreiben, heuristische Muster, d. h. eine Übereinstimmung garantiert nicht, dass es ein Problem gibt, aber es ist wahrscheinlich, dass es ein Problem gibt.

Außerdem müssen die Rezepte und QuickFixes, die wir schreiben, nicht vollständig umfassend sein. Sie müssen gut genug sein, dass sie uns helfen, Probleme zu identifizieren und zu beheben, ohne dabei übermäßig kompliziert zu sein. Denn wenn sie zu kompliziert werden, werden sie schwieriger zu verstehen und schwerer zu warten.

---

Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.

Den Quellcode und die Rezepte für diesen Beitrag finden Sie im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior , im Modul "guiceexamples".

https://github.com/securecodewarrior/sensei-blog-examples

Erfahren Sie mehr über Sensei

Ändern der Sichtbarkeit von Methoden und Klassen für JUnit 5

Eine der Freuden des Programmierens ist das ständige Lernen, das erforderlich ist, um auf dem neuesten Stand zu bleiben. Eines der Probleme ist, dass wir eine Vertrautheit und Nutzungsmuster aufbauen, die sich auf die Annahme neuer Ansätze auswirken können. Sensei kann bei der Migration helfen, indem es veraltete Muster identifiziert und uns auffordert, den Fix für die Zukunft zu verwenden.

Als ich zum Beispiel von JUnit 4 auf JUnit 5 migriert bin, war ich es gewohnt, alle meine Testklassen und -methoden als öffentlich zu schreiben. Aber mit JUnit 5 können sie package private sein.

z.B. statt:

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

Ich möchte wirklich schreiben:

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

Es hat eine Weile gedauert, bis ich das Muskelgedächtnis für diesen Code aufgebaut hatte, und ich mache immer noch hin und wieder Fehler.

Verwendung von Sensei

Mit Sensei kann ich Rezepte erstellen, die die öffentlichen Methoden und Klassen finden und die Deklarationen so ändern, dass sie automatisch package private sind.

Um dies zu erreichen, habe ich ein Rezept erstellt:

Name - JUnit: JUnit 5 test methods do not need to be public
Beschreibung - JUnit 5 test methods do not need public visibility
Level - Error

Ich habe es als Fehler eingestuft, weil ich diese Codierungspraxis ausmerzen möchte und ich möchte, dass das Problem beim Schreiben von Code in der IDE besser sichtbar ist.

Ändern der Klassenerklärung

Um die Klassen zu finden, suche ich nach jeder Klasse, die eine Child-Annotation von @Test aus Junit 5 hat, d. h. org.junit.jupiter.api.Test

Und wo die Klasse den Modifikator public hat:

search:
class:
with:
child:
annotation:
type: "org.junit.jupiter.api.Test"
modifier: "public"

Dann ändert die Schnellreparatur den Modifikator, um die Sichtbarkeit zu entfernen, so dass es der Standard ist, und der Standard ist Paket privat, was ich suche.

availableFixes:
- name: "remove public visibility from JUnit 5 Test class"
actions:
- changeModifiers:
visibility: ""

Ändern der Methodendeklarationen

Das Änderungsrezept für die Methodendeklaration ist dem Klassenrezept sehr ähnlich.

Zunächst suche ich nach öffentlichen Methoden, die mit @Test aus JUnit 5 annotiert sind.

search:
method:
annotation:
type: "org.junit.jupiter.api.Test"
modifier: "public"

Und dann ändere ich den Modifikator auf die Standard-Sichtbarkeit.

availableFixes:
- name: "Remove @Test method public visibility"
actions:
- changeModifiers:
visibility: ""

Hinweis: Ändern mehrerer Methoden

Sensei hat die Möglichkeit, den QuickFix auf alle Verstöße in der aktuellen Datei anzuwenden.

Wenn ich alt+enter verwende, um den QuickFix anzuwenden.

Wenn ich das QuickFix-Namensmenü erweitere, sehe ich eine Option zum:

"Fix All: 'JUnit: JUnit 5 test methods do not need to be public' Probleme in der Datei"

Wenn ich diese Option auswähle, ändert Sensei alle Vorkommen des Problems, nicht nur das von mir ausgewählte.

Ändern der Klasse

Genauso wie eine Methode nicht öffentlich sein muss, muss auch die Klasse nicht öffentlich sein.

Ich kann ein Rezept und einen QuckFix erstellen, um die Klasse zu ändern.

Name - JUnit: Junit 5 Test classes do not need to be public
Beschreibung - Junit 5 Test classes do not need to be public
Level - Error

Wenn ich eine Klasse finde, die öffentlich ist und eine Methode mit einer @Test-Annotation hat. Dann möchte ich die Sichtbarkeit ändern.

search:
class:
modifier: "public"
anyOf:
- child:
method:
annotation:
type: "Test"

Ich kann die Änderung an der Klassendefinition wieder mit der Aktion changeModifiers vornehmen.

availableFixes:
- name: "Remove @Test class public visibility"
actions:
- changeModifiers:
visibility: ""

Zusammenfassung

Ein statisches Analysetool hat mich zunächst auf diesen empfohlenen Ansatz in JUnit aufmerksam gemacht. Aber das statische Analysewerkzeug hat mir nicht geholfen, das Muskelgedächtnis aufzubauen, um meinen Code beim Programmieren zu ändern.

Verwenden Sie den "Level", um Sie zu warnen. Wenn es sich um ein Problem handelt, das ich in meiner Kodierung auszumerzen versuche, stelle ich es zunächst auf "Fehler" und reduziere es dann, während ich mich vom Kodierungsansatz entwöhne.

Denken Sie daran, dass Sie mit Sensei alle Probleme in der aktuellen Datei gleichzeitig beheben können, indem Sie beim Anwenden des QuickFix die Option des Dropdown-Menüs verwenden.

Indem ich ein Sensei Rezept erstelle, kann ich meinen alten Kodierungsansatz in Echtzeit sehen. Und QuickFix es, um den Ansatz zu verstärken, wenn ich gelegentlich in meiner Kodierung ausrutsche.

---

Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.

Den Quellcode und die Rezepte dafür finden Sie im Repository `sensei-blog-examples` im GitHub-Konto Secure Code Warrior , im Modul `junitexamples`.

• https://github.com/securecodewarrior/sensei-blog-examples

Automatisches Hinzufügen eines privaten Konstruktors mit Sensei

In einer Utility-Klasse, wenn die Felder und Methoden statisch sind, gibt es keinen offensichtlichen Grund, warum ich sie jemals instanziieren würde.

z. B. UtilityClass utility = new UtilityClass();

Der folgende Code ist eine einfache Implementierung einer Utility-Klasse.

public class UtilityClass {
    public static final Boolean ULTIMATE_TRUTH = true;
    public static boolean getTrue(){
        return ULTIMATE_TRUTH;
    }
}

Dies ist die Art von Codierungsmustern, die Tools für die statische Analyse aufspüren können, aber sie bieten oft nicht die Möglichkeit, das Problem zu beheben.

Ich kann Sensei verwenden, um das Codierungsmuster zu identifizieren und automatisch einen privaten Konstruktor zu generieren, damit ich die Klasse nicht instanziieren kann.

Suche nach der Klasse

Ich werde ein neues Rezept mit dem Namen "Utility class" hinzufügen:

•  Statische Klassen: privaten Konstruktor anlegen.

Und zunächst werde ich einen einfachen Matcher erstellen, um nach einer Klasse zu suchen.

suchen:

  class: {}

Dies passt zu jeder Klasse, was gut genug ist, um mit dem Schreiben eines Quick Fixes zu beginnen. Sobald ich einen Quick Fix habe, der funktioniert, werde ich die Suche so verfeinern, dass sie hervorhebt, wenn es wahrscheinlicher ist, dass es eine Klasse gibt, die einen privaten Konstruktor benötigt.

Schnellbehebung

Für den Quick Fix möchte ich einen privaten Konstruktor erzeugen.

In der Beispielklasse würde dies wie folgt aussehen:

   private UtilityClass(){}

Um den obigen Code zu meiner Klasse hinzuzufügen, wird mein Quick Fix eine Methode hinzufügen, und der Name der Methode wird eine Mustache-Vorlage sein, die den Namen der Klasse verwendet.

availableFixes:

- name: "add private constructor"
  actions:
  - addMethod:
      method: "private {{{ name }}}(){}"

Im GUI-Editor verwende ich die Variablen anzeigen, um die Mustache-Vorlage zu erstellen und bearbeite dann das Feld, um den privaten Modifikator, die Klammern und die geschweiften Klammern hinzuzufügen, damit es syntaktisch korrekt ist.

Dies würde mir nun erlauben, einen privaten Konstruktor zu jeder Klasse hinzuzufügen.

Die QuickFix-Vorschau hilft mir, weil ich den generierten Code sehen kann, während ich die Mustache-Vorlage schreibe.

Da ich nun weiß, dass ich das Problem beheben kann. Ich werde die Suchbedingungen so verfeinern, dass das Rezept angezeigt wird, wenn es am besten geeignet ist.

Suche nach fehlenden Konstrukteuren

Im Idealfall möchte ich nicht ein Rezept erstellen, das bei jeder Klasse einen Fehler meldet. Also füge ich einige zusätzliche Bedingungen in die Suche ein, damit wir nur auf Klassen passen, die keinen Konstruktor haben.

suchen:

  Klasse:
ohne:
Kind:
Methode:
Konstruktor: true

Die YAML ist etwas anders als die GUI.

In der GUI konfiguriere ich es so, dass es nach einer Klasse ohne eine Child-Methode sucht, die ein Konstruktor 'yes' ist. Wir verwenden 'yes' in der GUI anstelle von 'true', um die GUI ein wenig menschenfreundlicher zu gestalten.

Dieses Rezept zeigt sich nun nur noch bei allen Klassen ohne Konstruktor.

Eingrenzung der Suche nach wahrscheinlichen Verursachern

Ich möchte also vielleicht noch weiter gehen und nach dem Vorhandensein von statischen Methoden oder Feldern suchen.

Ich suche nach einer beliebigen Klasse ohne Konstruktor, die entweder alle öffentlichen statischen Felder oder alle öffentlichen statischen Methoden hat.

suchen:

  Klasse:
mit:
anyOf:
- Kind:
Methode:
allOf:
- Modifikator: "public"
- modifier: "static"
- child:
field:
allOf:
- modifier: "static"
- Modifikator: "public"
ohne:
Kind:
Methode:
Konstruktor: true

Da Sensei dazu dient, mir als Programmierer in der IDE zu helfen, und nicht dazu, den Code statisch zu analysieren und alle Fehler zu melden, ist dieser Filter gut genug, um die meisten Klassen in meiner Codebasis auszuschließen, bei denen ich einen guten Grund haben könnte, einen öffentlichen Standardkonstruktor zu haben.

In einigen Projekten könnte dies ein Schritt zu weit sein, weil die Utility-Klassen private Methoden haben könnten, so dass ich nach dem Vorhandensein von "beliebigen" öffentlichen statischen Methoden suchen könnte, anstatt nach "allen".

       - Kind:
Feld:
anyOf:
- Modifikator: "static"
- modifier: "public"

Hinweise

Sensei ist nicht als Ersatz für ein statisches Analysewerkzeug gedacht. Sensei kann ein statisches Analysewerkzeug bei häufigen Problemen im Zusammenhang mit Ihrem Codierungsprozess oder Ihrer Technologie ergänzen. Durch die Replikation einer ausreichenden Anzahl von Übereinstimmungen wird ein Problem hervorgehoben, und der Entwicklungsprozess wird durch die Generierung des QuickFix-Codes unterstützt.

Was ich versuche, ist ein Rezept zu erstellen, das einfach genug ist, um alle Situationen einzuschließen, in denen ich es brauche, aber es so zu filtern, dass es nicht in jeder Klasse vorgeschlagen wird.

Wenn ich an Rezepten arbeite, versuche ich, das Risiko zu minimieren. In diesem Fall war ich nicht sicher, ob ich den privaten Konstruktor erstellen kann, also habe ich zuerst den QuickFix erstellt. Dann überarbeitete ich die Suchbedingungen, um sie spezifischer zu machen.

Manchmal bin ich bei der Arbeit an Rezepten nicht sicher, wie ich die Suche durchführen soll, also arbeite ich zuerst daran.

Ich finde es einfacher, Rezepte zu erstellen, wenn ich sie inkrementell aufbaue, indem ich zwischen dem Refactoring des QuickFix und der Suche wechsle.

---

Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.

Der Quellcode und die Rezepte dafür befinden sich im `sensei-blog-examples` Repository im Secure Code Warrior GitHub-Konto, im Modul `pojoexamples`.

https://github.com/securecodewarrior/sensei-blog-examples

‍

Tapjacking, eine Kombination aus "Tap" und "Hijacking", bedeutet genau das. Es ist ein Angriff, bei dem der Angreifer die Taps des Benutzers entführt und ihn dazu bringt, etwas zu tun, was er nicht beabsichtigt hat. Wie funktioniert es also und wie können wir es verhindern?

Beginnen wir unsere Geschichte mit Bildschirm-Overlays. Bildschirm-Overlays oder wie Google sie nennt, Fenster mit dem Typ TYPE_APPLICATION_OVERLAY. Dies sind Fenster, die über andere Apps gezeichnet werden und normalerweise nur einen Teil des Bildschirms verdecken. Sie werden oft verwendet (wie das Beispielbild unten), wenn eine App neue Berechtigungen anfordert.

Dies ist eigentlich eine coole und lustige Funktion und immer mehr Apps beginnen, sie zu nutzen, denken Sie an Facebooks Chat-Blasen oder die Google Maps-Navigation in einer Ecke Ihres Bildschirms, wie der Screenshot unten.

Allerdings gibt es einige Sicherheitsrisiken, die mit diesen Overlays verbunden sind. Jedes aktive Bildschirm-Overlay kann auf Tippen hören, wie sonst würde Facebook wissen, dass wir die Sprechblase angetippt oder gezogen haben? Dies ermöglicht es Apps, Sie auszuspionieren und möglicherweise Passwörter und Kreditkartendaten zu stehlen.

Einen Schritt weiter, und daher kommt der Begriff Tapjacking, können Overlays Dinge über andere Apps zeichnen und den Benutzer dazu verleiten, verschiedene Aktionen auszuführen. Der Benutzer denkt, dass er mit dem Overlay interagiert, aber in Wirklichkeit führen seine Taps auch Aktionen in der darunter liegenden App aus. Auf diese Weise kann das Overlay Sie dazu verleiten, bestimmte Berechtigungen zu aktivieren oder gefährliche Einstellungen zu ändern, wie in diesem alten YouTube-Video gezeigt wird.

Das obige Demonstrationsvideo wurde 2010 auf YouTube hochgeladen, wurde also auf einer älteren Version von Android durchgeführt. Der Angriff ist aber auch heute noch relevant, da Schwachstellen bekannt wurden, die Tapjacking in neueren Versionen von Android wie Nougat und Marshmallow ermöglichen.

Was können Sie also dagegen tun? Als Benutzer ist es wichtig, die Konsequenzen dieser Überlagerungen zu erkennen und sich der Apps bewusst zu sein, die sie verwenden. Ab API-Level 23 (Android 6.0 Marshmallow) ist dies zu einer Erlaubnis geworden, die vom Benutzer explizit erteilt werden muss. Damit sind aber immer noch 50 % der Android-Nutzergefährdet. Sie können immer noch in den Einstellungen unter "Anzeige über anderen Apps" überprüfen, welche Apps diese Erlaubnis nutzen.

Als Entwickler liegt es an uns, dafür zu sorgen, dass Benutzeraktionen mit dem vollen Wissen und der Zustimmung des Benutzers durchgeführt werden. Android bietet eine Einstellung für Ihre Ansichten, die genau das tut, genannt filterTouchesWhenObscured. Wenn sie aktiviert ist, verwirft das Framework Berührungen, die empfangen werden, wenn das Fenster der Ansicht von einem anderen sichtbaren Fenster verdeckt wird. So einfach ist das: Setzen Sie filterTouchesWhenObscured auf true, und Ihre App ist vor Tapjacking sicher.

Viel Glück und bis nächste Woche!

Manchmal ist es wichtig, dass eine Anwendung in der Lage ist, zu überprüfen, ob eine Aktion mit vollem Wissen und Einverständnis des Benutzers durchgeführt wird, wie z. B. das Erteilen einer Berechtigungsanfrage, das Tätigen eines Kaufs oder das Klicken auf eine Werbung. Leider könnte eine bösartige Anwendung versuchen, den Benutzer dazu zu verleiten, diese Aktionen unbewusst auszuführen, indem sie den beabsichtigten Zweck der Ansicht verschleiert.

https://developer.android.com/reference/android/view/View.html

Die Geräteverschlüsselung ist der Prozess der Verschlüsselung aller Daten auf dem Android-Gerät. Sobald dies für ein Android-Gerät aktiviert ist, werden alle vom Benutzer erstellten Daten sofort verschlüsselt, bevor sie in den Speicher geschrieben werden. Dies schützt die Daten, so dass selbst wenn eine nicht autorisierte Partei versucht, auf die Daten zuzugreifen, sie nicht in der Lage sind, sie zu lesen. Dies ist eine besonders gute Funktion für Smartphone-Geräte, da diese vom Benutzer herumgetragen werden und anfälliger für Verlust oder Diebstahl sind als andere Computergeräte. Jeder neugierige Finder oder Dieb kann nicht auf die Daten zugreifen, es sei denn, er kann das Telefon entsperren.

Android verfügt über zwei Arten der Geräteverschlüsselung: Verschlüsselung der gesamten Festplatte und dateibasierte Verschlüsselung.

Verschlüsselung der gesamten Festplatte

Die Festplattenverschlüsselung wurde in API-Level 19 (Android 4.4 KitKat) eingeführt, aber die neuen Funktionen in API-Level 21 (Android 5.0 Lollipop) haben ihre Verwendung erst richtig in Gang gebracht. Bei der Festplattenverschlüsselung wird ein einzelner Schlüssel verwendet, um die gesamte Partition mit den Benutzerdaten des Geräts zu schützen. Der Schlüssel ist mit den Anmeldeinformationen des Benutzers geschützt und muss beim Booten angegeben werden, bevor ein Teil der Festplatte zugänglich ist.

Das ist gut für die Sicherheit, aber es bedeutet auch, dass die meisten Funktionen des Geräts nicht verfügbar sind, bis der Benutzer seine Anmeldeinformationen eingibt. Das bedeutet, wenn das Gerät neu gestartet, aber nicht entsperrt wird, können einige Funktionen wie Alarme nicht funktionieren, Dienste sind nicht verfügbar und Telefone können keine Anrufe empfangen. Aus diesem Grund wurde der zweite Verschlüsselungsmodus geschaffen.

Dateibasierte Verschlüsselung

Die dateibasierte Verschlüsselung, der zweite Modus der Geräteverschlüsselung, ist seit API-Level 24 (Android 7.0 Nougat) verfügbar. In diesem Modus werden verschiedene Dateien mit unterschiedlichen Schlüsseln verschlüsselt, die unabhängig voneinander entsperrt werden können. Mit diesem Verschlüsselungsmodus kam der Direct Boot-Modus, der es verschlüsselten Geräten ermöglicht, direkt zum Sperrbildschirm zu booten und die zuvor fehlenden Funktionen zu aktivieren, bevor das Gerät entsperrt wird.

Der Direct Boot ermöglicht es Apps, in einem begrenzten Kontext zu arbeiten, bevor das Gerät entsperrt wird. Auf diese Weise können sie weiterhin wie erwartet funktionieren, ohne die Benutzerinformationen zu gefährden. Um diese Funktionalität bereitstellen zu können, benötigt das Android-Gerät zwei Speicherorte:

1. Berechtigungsnachweis Verschlüsselter Speicher. Standardspeicherort, nur verfügbar, nachdem der Benutzer das Gerät entsperrt hat.
2. Gerät Verschlüsselter Speicher. Verfügbar im Direct Boot-Modus und nachdem der Benutzer das Gerät entsperrt hat.

Wenn Ihre App auf Daten zugreifen muss, während sie im Direct Boot-Modus läuft, sollte sie den Device Encrypted-Speicher verwenden. Seien Sie sich jedoch über die Auswirkungen auf die Sicherheit im Klaren! Device Encrypted Storage sollte nicht zum Speichern sensibler Daten verwendet werden! Der Device Encrypted Storage ist mit einem Schlüssel verschlüsselt, der verfügbar ist, sobald das Gerät erfolgreich gebootet hat. Alle Daten, auf die nur der Benutzer zugreifen soll, sollten im Standardspeicher, dem Credential Encrypted Storage, gespeichert werden.

Wenn Sie mehr darüber erfahren möchten, was Verschlüsselung ist oder warum sie wichtig ist, sehen Sie sich das Video auf dem Portal Secure Code Warrior an. Oder Sie können versuchen, Ihr Wissen über Verschlüsselung zu testen, indem Sie einige Herausforderungen spielen.

Brauchen Sie eine Schritt-für-Schritt-Anleitung für Ihr Gerät? Sehen Sie sich diesen Artikel von Bill Hess bei Pixel Privacy an.

Ich hoffe, Sie haben etwas Neues gelernt. Bis nächste Woche!

Berechtigungsverschlüsselter Speicher, der der Standardspeicherort ist und nur verfügbar ist, nachdem der Benutzer das Gerät entsperrt hat.

https://developer.android.com/training/articles/direct-boot.html