Security QA mit Kotlin-Bibliotheken und Java

vorhergehende Artikel in: Java Software-Test
12.11.2022

Über die Probleme und Herausforderungen beim Unit-Testen im Security-Umfeld mit Kotlin-Bibliotheken...

Ich habe mich dafür entschieden, die Tests für meinen Timestamping Server zu veröffentlichen und - wo möglich und sinnvoll - zu automatisieren.

Ich dachte, dass die größte Schwierigkeit dabei darin bestünde, die Tests so weit zu automatisieren, dass die Code-Coverage nahe 100 % läge, ohne sensibles Crypto-Material im Repository zu exponieren. Schließlich wollte ich, dass das Projekt auf GitHub über die GitHub-Actions gebaut werden sollte.

Und im Zuge der CI/CD sollten natürlich möglichst auch alle Tests abgearbeitet werden. Viele dieser Tests benötigen aber tatsächliches Crypto-Material (Schlüssel, Zertifikate, ...). Was ich vermeiden wollte war, echtes Crypto-Material in das Repo zu packen - das würde unweigerlich dazu führen, dass Leute, die das Projekt verwenden keine eigenen Materialien dazu nutzen würden, sondern aus Faulheit einfach das dem Projekt beiliegende.

Ich erinnerte mich an RFC 6963 - Certificate Transparency und die darin beschriebene Methode des Vergiftens eines Zertifikats mittels einer kritischen Erweiterung (poison extension) - ist eine Erweiterung im Zertifikat, die als critical eingestuft, jedoch unbekannt ist, muss das Zertifikat insgesamt als ungültig betrachtet werden.

Genau auf diese Weise habe ich letztlich das Zertifikat der Test-TSA markiert: Es enthält eine solche Erweiterung und damit wird effektiv verhindert, dass dieses Zertifikat jemals im Produktivbetrieb eingesetzt werden kann.

Dadurch kommen unter Umständen neue Herausforderungen auf mich zu wenn es darum geht, auch die Integrationstests zu automatisieren, aber das lasse ich erst einmal in Ruhe auf mich zukommen.

Das eigentlich interessante Problem beim Publizieren der Unit-Tests kam aus einer gänzlich unerwarteten Richtung: Das Projekt nutzt als Grundlage Javalin - ein Kotlin-Framework. Diese Tatsache sorgte dafür, dass ich meinen bestehenden Code umstrukturieren musste: In Kotlin sind per Definition alle Klassen und deren Member final - was offenbar dazu führt, dass interne Variablen nicht mehr per Getter und Setter maskiert werden - man greift direkt darauf zu. Das führt aber dazu, dass es nicht mehr trivial ist, solche Infrastruktureelemente zu "mocken" - zum Beispiel mit Mockito.

Bei mir führte das dazu, dass ich tatsächlich Code umschreiben musste, da ich auf Methoden und Felder einer zentralen Javalin-Klasse zugriff und beides zusammen nicht zu mocken ist - entweder werden die Felder einzeln durch Mocks ersetzt - dann kann die umgebende Klasse kein Mock sein - oder die Klasse selber wird gemockt - dann kann man aber die Felder nicht mocken.

Glücklicherweise war die daraus resultierende Änderung minimal und betraf nicht die Funktionalität, sondern lediglich das Monitoring. Dadurch kann das Projekt jetzt mit einer - meiner Ansicht nach - durchaus ordentlichen Code Coverage aufwarten.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Neueste Artikel

  • Github hat keine Ahnung von Crypto und Sicherheit

    Morgen - am 1.2.2023 - soll mein neuer $dayjob anfgangen - und damit die Quelle, aus der ich die Mittel beziehe, weiterhin meine Kuchenzutaten bezahlen zu können. Das wird irgendwas mit Sicherheit sein. Und am Tag davor hat sich - wer eigentlich genau? - überlegt: "Komm, lass ihn uns nochmal so richtig auf Betriebstemperatur überkochen!". Aber - der Reihe nach...

    Weiterlesen...
  • Aktualisierung TileServer - Restrukturierung

    Ich habe meinen Tile-Server für OpenStreetMap-Daten aktualisiert

    Weiterlesen...
  • Drunken Bishop in Java

    Ich habe neulich wieder einmal Lust auf eine kleine Fingerübung gehabt und deshalb ein Verfahren in Java implementiert, das ich ursprünglich als Möglichkeit kennenlernte, zwei Schlüssel beim Versuch des Aufbaus einer Verbindung mittels SSH zu vergleichen...

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.