Zusammenfassung

  • Der Test setzt die Pufferschwelle auf ein Byte, erzwingt damit den temporären Datenträger und vergleicht die Ausgabe von Wickets FileUpload.getBytes() exakt mit der Eingabe.
  • Hinter organizations.xlsx steckt nur kurzer UTF-8-Text, hinter carta-ce.pdf lediglich ein PDF-Präfix mit Kommentar; kein Parser bestätigt die benannten Formate.
  • Sinnvoll ist eine Belegkette: Transporttest behalten, echte Dokumente ergänzen und Format, Fachregeln, Berechtigung sowie Ressourcen jeweils separat prüfen.

Eine präzise grüne Lampe

Am 11. September 2026 ergänzte LACNIC sein öffentliches Wahlsoftware-Repository um die Methode wicketFileUploadGetBytesWorksForDiskBackedExcelAndPdf. Der Name klingt wie eine umfassende Aussage über zwei Dokumentklassen. Der Code beantwortet eine kleinere, klar definierte Frage: Liefert Wicket dieselben Bytes zurück, wenn Commons FileUpload den Inhalt nicht im Arbeitsspeicher, sondern in einer temporären Datei hält?

Dafür baut der Test eine DiskFileItemFactory mit dem von JUnit bereitgestellten temporären Verzeichnis. Die Puffergröße beträgt 1. Beide nicht leeren Nutzlasten überschreiten damit die Schwelle zum datenträgergestützten Zustand. Ein Hilfsverfahren schreibt die Bytes in das Element, verpackt es als Wicket-FileUpload, ruft getBytes() auf und vergleicht beide Arrays. Im finally-Block wird das temporäre Element gelöscht.

Dieser Aufbau ist nicht trivial. Commons FileUpload unterscheidet je nach Schwelle zwischen Speicher und temporärer Datei. Ein Bibliothekswechsel kann an genau dieser Grenze scheitern, obwohl derselbe kleine Inhalt im Speicherpfad funktioniert. Ein gezwungener Datenträgertest isoliert die Kompatibilität von Multipart-Objekt, Dateiablage und Wicket-Hülle. Sein grünes Ergebnis ist deshalb ein belastbarer Transportbeleg.

Die Formatnamen stammen dagegen nur aus den Dateinamen. Das als spreadsheet bezeichnete Array enthält ORGID, einen Zeilenumbruch und ALFA-001. Eine echte .xlsx-Datei ist ein OOXML-Paket mit ZIP-Struktur, Inhaltstypen, Beziehungen und XML-Bestandteilen. Das als pdf bezeichnete Array besteht aus %PDF-1.1, einem Zeilenumbruch, %carta und einem weiteren Umbruch. Es besitzt eine Signatur, aber keine vollständige PDF-Struktur. Der Test öffnet weder XSSFWorkbook noch einen PDF-Parser.

Aus dem Ergebnis folgt also: Die Bytes wurden beim Wechsel auf den Datenträger und zurück nicht verändert. Nicht daraus folgt: Die Bytes bilden ein akzeptables Dokument, die enthaltenen Werte sind fachlich zulässig, die sendende Person besitzt Rechte oder eine Änderung wurde korrekt gespeichert. Diese Grenzen machen den Test nicht schwächer. Sie verhindern nur, dass er als Ersatzbeleg für andere Kontrollen dient.

Was die echten Wege zusätzlich prüfen

Das Repository liefert selbst ein Gegenbeispiel zur bloßen Dateinamenslogik. In derselben Testklasse wird Text als photo.jpg an den Kandidatenfoto-Validator übergeben und als ungültiges Format zurückgewiesen. Ein weiterer Test erzeugt ein echtes PNG, lässt es verarbeiten, erwartet JPEG und decodiert das Ergebnis erneut. Außerdem kontrolliert er, dass Breite und Höhe höchstens 400 Pixel betragen. Hier muss der Inhalt tatsächlich ein Bild sein und eine Transformation überstehen.

Der Upload von Organisationslisten besitzt ebenfalls nachgelagerte Prüfungen. Der UI-Validator lässt eine Datei zunächst weiter, wenn entweder der Name auf .xlsx endet oder der angegebene MIME-Typ dem OOXML-Tabellenformat entspricht. Diese Oder-Regel verlässt sich am Rand auf Angaben des Clients, ist aber nicht die letzte Entscheidung. Schuldner- und Löschlisten gehen an entfernte Prüfverfahren. Einfügungen und Aktualisierungen werden beim Absenden ausführlich validiert.

ExcelUtils schreibt die Bytes in eine temporäre Datei, verlangt den OOXML-MIME-Typ und öffnet sie mit Apache POIs XSSFWorkbook. Danach wählt der Code das erste Tabellenblatt, liest Überschriften und verarbeitet Zeilen. Eine Schuldnerliste benötigt ORGID; eine Aktualisierungsliste braucht weitere festgelegte Spalten. Fehlende oder doppelte Organisationskennungen sowie unzulässige Werte werden fachlich beanstandet. Vor dem Einreihen einer Änderung laufen zusätzliche, operationsbezogene Prüfungen. Ein zweiter Auftrag wird nicht gestartet, wenn bereits einer bearbeitet wird.

Der kurze Text aus dem neuen Test kann daher problemlos die Byte-Prüfung bestehen und anschließend am realen Workbook-Parser scheitern. Beide Resultate sind richtig. Die Tests beantworten nur verschiedene Fragen.

Beim Wählerverzeichnis ist die Trennung ähnlich. Das Upload-Panel entnimmt die Bytes, prüft die Anwendbarkeit auf die konkrete Wahl und versucht erst danach, eine Aktualisierung einzureihen. Der Kompatibilitätstest bildet die Leseform nach, nicht die Spalten, Wahlbedingungen oder dauerhafte Wirkung.

Ergebnisbriefe haben wiederum eigene Kontrollen. Das Multipart-Formular ist auf 10 MB begrenzt. Beim Speichern lädt die Seite die Wahl erneut, setzt die Zugriffsprüfung durch und bricht bei einer geschlossenen Wahl ab. Optionale spanische, englische und portugiesische Schreiben werden geprüft, bevor die ausgewählten Bytes zusammen mit Administrator- und Client-Kontext gespeichert werden.

Die PDF-Erkennung selbst ist schmal: ElectionResultLetterSupport.isPdf vergleicht die ersten vier Bytes mit %PDF. Deshalb erfüllt das synthetische Beispiel die Regel. Das beweist keinen vollständigen, darstellbaren oder richtlinienkonformen PDF-Inhalt. Berechtigung, Wahlstatus und Größenlimit bleiben echte Schutzmechanismen; sie dürfen lediglich nicht als Strukturprüfung umgedeutet werden.

Fünf Belege für eine Annahmeentscheidung

Eine überprüfbare Testsuite kann ihre Aussagen als getrennte Belege organisieren.

Der Transportbeleg testet Speicher und Datenträger, bestätigt ausdrücklich isInMemory() == false, vergleicht Bytes, schließt Datenströme und kontrolliert die Bereinigung. LACNICs neue Methode bildet dafür einen guten Kern. Ein engerer Name könnte den Erhalt der Bytes durch Wickets getBytes() bei datenträgergestütztem FileItem nennen. Die Dateinamen bleiben anschauliche Beispiele, ohne Parserleistung zu suggerieren.

Der Formatbeleg verwendet echte Dateien. Für OOXML gehört dazu eine kleine, mit POI oder einem gleichwertigen Werkzeug erzeugte Mappe samt Blatt und Pflichtüberschriften. Negative Fälle sind ein gewöhnliches ZIP, ein abgeschnittenes Paket und je nach Richtlinie ein verschlüsseltes Dokument. Für PDF braucht es ein vollständiges Minimaldokument, das der ausgewählte Parser akzeptiert, daneben ein reines Präfix, eine abgeschnittene Datei und relevante Täuschungsfälle. Endung, MIME-Typ und Signatur liefern Hinweise; sie ersetzen die Struktur nicht.

Der Fachbeleg führt das echte Workbook durch die Organisations- oder Wählerverzeichnisregeln. Er trennt Lesefehler von fehlender Spalte, leerer Zeile, doppelter Kennung oder unzulässigem Wert. Er prüft den Fehlerbericht und stellt sicher, dass abgelehnte Eingaben keinen Auftrag hinterlassen. Wahlbezogene Bedingungen benötigen bekannte Ausgangsdaten und einen konkret erwarteten Effekt.

Der Verfahrensbeleg prüft Befugnis und Wirkung. Eine berechtigte Administration darf eine offene Wahl bearbeiten; fehlender Zugriff oder ein geschlossener Zustand verhindern dies. Eine gültige Datei erzeugt genau einen Auftrag, dessen Ergebnis zu den akzeptierten Zeilen passt. Parallele Einsendungen müssen den vorgesehenen Sperrfall erreichen. Bei Ergebnisbriefen sollte ein ungültiger Sprachupload alle drei Änderungen stoppen, bevor ein Teilzustand entsteht.

Der Ressourcenbeleg misst Anfragegröße, Speicher, temporären Pfad, Löschung, Laufzeit und komprimierte Expansion. Commons FileUpload dokumentiert Schwellenwerte und Größenbegrenzungen. Apache POI weist darauf hin, dass die Verarbeitung fremder Dokumente zusätzliche Schutzschichten erfordert, weil eine Bibliothek nicht alle schädlichen Effekte verhindern kann. ZipSecureFile bietet Grenzwerte für Kompressionsverhältnis und entpackte Eintragsgröße. OWASP empfiehlt eine Kombination aus Berechtigung, erlaubten Endungen, Typ, Signatur und Limits nach dem Entpacken.

Diese allgemeinen Empfehlungen belegen keine Sicherheitslücke bei LACNIC. Untersucht wurde ein öffentlicher Quellstand, kein Produktivsystem. Im festgehaltenen Admin-POM steht Wicket 10.9.0; das WildFly-Modul verweist auf POI OOXML 5.0.0. Daraus lässt sich die tatsächlich eingesetzte Version nicht ableiten. Auch die zeitliche Nähe zwischen einer Abhängigkeitsänderung und einem Regressionstest ist kein Nachweis für Ursache oder Störung.

Testnamen werden zu Organisationswissen

Bei einer Freigabe lesen Entscheider eher Testnamen als Implementierungen. „Datenträgergestütztes Excel und PDF funktionieren“ kann dadurch zur erinnerbaren Aussage werden, obwohl nur Byte-Gleichheit gemessen wurde. Je länger dieser Satz zirkuliert, desto schwerer lässt er sich später präzisieren.

Die bessere Lösung behält die Geschwindigkeit des kleinen Tests. Sie versieht ihn mit einer engen Behauptung, der Bibliotheksidentität und Links zu den anderen Belegen. Dann zeigt ein Fehlschlag sofort auf die Übergabestelle, während ein Erfolg keine ungetestete Parser-, Rechte- oder Ressourcenbehauptung mitzieht. Technische Bescheidenheit ist hier keine geringere Sicherheit. Sie ist die Voraussetzung dafür, dass Sicherheit nachvollziehbar addiert werden kann.

Ein solcher Aufbau verbessert auch die Pflege der Testdaten. Synthetische Bytefolgen sind klein, schnell und dauerhaft verständlich; sie eignen sich hervorragend für den Transportbeleg. Echte Office- und PDF-Dateien sind schwerer zu überprüfen und können sich bei Bibliotheksänderungen anders verhalten. Gerade deshalb gehören sie in einen separaten, versionierten Fixture-Bestand. Fachliche Arbeitsmappen brauchen wiederum erkennbare Ausgangsdaten und erwartete Zeilenresultate. Werden diese Kategorien vermischt, ersetzt ein einziger großer Beispieldatensatz viele präzise Aussagen, und ein Fehlschlag liefert wenig Orientierung.

Werden sie getrennt, kann jede Fixture so einfach wie möglich bleiben, ohne so einfach zu werden, dass sie eine andere Dateiklasse nur noch im Namen trägt. Die Belegkarte ist damit nicht zusätzliche Bürokratie, sondern eine Methode, Testgeschwindigkeit, Wartbarkeit und Aussagekraft gleichzeitig zu erhalten.

Sie hält außerdem offene Fragen ausdrücklich sichtbar und verhindert bequeme Schlussfolgerungen aus bloßen Dateinamen.

Quellen