Wie man ein Guice-Abhängigkeitsinjektionsproblem abfängt und behebt, indem man 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
Ein Beispielszenario für eine Fehlkonfiguration von Guice, die dazu führen kann, dass zur Laufzeit beim Testen eine NullPointerException gemeldet wird.
Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.
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
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
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.
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
Inhaltsübersicht
Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
