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 ü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 Codeberg Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • 8TB Raid5 mit Raspberry Pi

    25.04.2020

    Ich habe mir neulich überlegt, ob man einen Pi als Raid benutzen könnte - aber nicht mit dem ewig gleichen Setup mit 4 USB-Sticks...

    Weiterlesen...

Neueste Artikel

  • Watch David Byrne Lead a Massive Choir in Singing David Bowie’s “Heroes”

    Durch die Seite Open Culture bin ich auf diesen spektakulären Auftritt aufmerksam geworden:

    Weiterlesen
  • Zufälliges Füllen der Ebene

    Ich fand neulich einen sehr interessanten Artikel Zum Thema der algorithmischen Erzeugung von dekorativen (obwohl - das liegt im Auge des Betrachters) Bildern.

    Weiterlesen
  • Sicherheit beim Fernzugang per SSH

    Ich habe vor einiger Zeit bereits zwei Vorträge gestaltet und dafür meine Ideen zur unkomplizierten Erstellung von Präsentationen genutzt - nun ist ein weiterer hinzugekommen.

    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, muss 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 Codeberg-Repositories findet man hier.