Assessor_2.0/docs/IMPORT_SECURITY_LIMITS.md

Import-Sicherheit und Ressourcenlimits

Geltungsbereich

Diese Grenzen gelten für alle von der gemeinsamen Importengine unterstützten Dateien: CSV, JSON, XML, HTML/HTM, XLSX und XLS. Im empfohlenen lokalen Serverbetrieb wird jeder Parserauftrag in einem eigenen Node.js-Worker ausgeführt. Der Browser- und Tauri-Fallback verwendet dieselben Inhaltsgrenzen, besitzt aber keine gleichwertige harte Zeit- und Speicherisolation. Für den späteren Firmenbetrieb ist deshalb ausschließlich der Serverpfad vorgesehen.

Verarbeitungsreihenfolge

1. Die API begrenzt den JSON-Request und prüft Erweiterung, Base64-Daten linear und stack-sicher sowie deklarierte Größe und tatsächliche Byteanzahl.
2. ZIP-basierte Excel-Dateien werden anhand ihres Zentralverzeichnisses geprüft, bevor SheetJS sie öffnet.
3. Dekodierte Textformate werden vor DOM-, JSON- oder CSV-Parsing auf Größen und gefährliche Konstrukte geprüft.
4. Die formatspezifischen Parser erzeugen das gemeinsame Zwischenmodell.
5. Tabellen-, Zeilen-, Spalten- und Zellgrenzen werden auf diesem Zwischenmodell erneut geprüft.
6. Erst danach folgen Erkennung, Normalisierung, Vorschau und eine ausdrücklich bestätigte, atomare Persistenz.

Limitverletzungen erzeugen strukturierte Importdiagnosen. Beim Batchimport bleibt der Fehler auf die betroffene Datei begrenzt.

Inhaltsgrenzen pro Datei

Ressource	Standardgrenze
Quelldatei	100 MiB
dekodierter Text	64 Mi Zeichen
Tabellen	256
Zeilen je Tabelle	250.000
Zeilen insgesamt	500.000
Spalten je Tabelle	2.000
Zeichen je Zelle	1.000.000
Zeichen in allen Zellen	64 Mi Zeichen
HTML-/XML-Elemente	500.000
JSON-Verschachtelung	256 Ebenen
ZIP-Einträge	20.000
entpackte Größe je ZIP-Eintrag	128 MiB
entpackte ZIP-Gesamtgröße	512 MiB
ZIP-Kompressionsverhältnis	200:1

Zusätzlich gelten maximal 50 Dateien pro Importvorschau und 140 MiB pro API-Request einschließlich Base64-Overhead.

Parserisolation im Serverbetrieb

Einstellung	Standard	Zulässiger Bereich
ASSESSOR_PARSER_TIMEOUT_MS	30.000 ms	1.000–300.000 ms
ASSESSOR_PARSER_MAX_CONCURRENT	2 Worker	1–8
ASSESSOR_PARSER_MAX_QUEUE	8 Aufträge	0–100
ASSESSOR_PARSER_MAX_QUEUE_MB	256 MiB	16–2.048 MiB
ASSESSOR_PARSER_MEMORY_MB	512 MiB Old Generation	128–2.048 MiB

Jeder Auftrag erhält einen neuen Worker. Nach Ablauf des Zeitlimits wird dieser beendet. Workerfehler und Speicherabbrüche werden als kontrollierte Parserdiagnose zurückgegeben. Ist gleichzeitig die Auftrags- oder Bytekapazität der Warteschlange erreicht, lehnt der Server weitere Parseraufträge kontrolliert ab. Die Young Generation ist zusätzlich auf 64 MiB und der Worker-Stack auf 8 MiB begrenzt.

Formatspezifische Härtung

• HTML: script, style, eingebettete Frames/Objekte, Formulare, Medien, SVG und weitere aktive Elemente werden entfernt. Ereignisattribute und navigierende oder nachladende Attribute wie src, href, srcdoc und action werden vor der Tabellenauswertung gelöscht. Importierter Code wird nicht ausgeführt. Berichte oberhalb von 4 Mi Zeichen sowie DOM-Stacküberläufe wechseln automatisch in eine begrenzte, nicht rekursive Tabellenextraktion.
• XML: DOCTYPE, ENTITY, SYSTEM und PUBLIC werden vor dem DOM-Parser abgewiesen. Externe Entitäten und lokale Dateireferenzen werden dadurch nicht aufgelöst.
• Excel: Verschlüsselte ZIP-Einträge, nicht zugelassene Kompressionsverfahren, ausbrechende Archivpfade, ZIP64 und eingebettete vbaProject.bin-Inhalte werden abgewiesen. SheetJS läuft ohne Formel- oder VBA-Auswertung.
• CSV-Export: Intern bleiben Originalwerte unverändert. Spreadsheet-orientierte Downloads, Aktionslisten und kopierte Tabellen neutralisieren führende =, +, - oder @, damit ein späteres Öffnen keine Formel aktiviert.
• ZIP: Eintragsanzahl, Einzel- und Gesamtgröße sowie Kompressionsverhältnis werden ausschließlich aus dem Zentralverzeichnis vor dem Entpacken geprüft.

Vorschau, Persistenz und Protokollierung

Nicht bestätigte Vorschauen liegen höchstens 15 Minuten im Arbeitsspeicher. Der Cache ist auf 10 Batches und 256 MiB Quelldaten begrenzt. Abgelaufene oder verdrängte Vorschauen können nicht persistiert werden. Beim Abschluss werden IDs, SHA-256, Dateiname, Größe und Änderungszeit gegen die serverseitige Vorschau geprüft.

Die Importpipeline schreibt keine Quelldateien oder Parser-Zwischendateien in temporäre Verzeichnisse. PostgreSQL-Zugriffe verwenden Parameter; ein bestätigter Batch wird in einer Transaktion gespeichert.

Das aktuelle Audit-Log enthält nur Zeitpunkt, Request-ID, Methode, Pfad, Status, Dauer und gegebenenfalls einen Fehlercode. Datei- und Requestinhalte werden nicht protokolliert. Das Log liegt derzeit nur im Prozessspeicher; dauerhafte zentrale Protokollierung, Zugriffsschutz und Aufbewahrung gehören zu Phase 14.

Verifikation

Die automatisierten Sicherheits- und Lasttests prüfen unter anderem Größenfehler, ZIP-Bomb-Metadaten, verschlüsselte/VBA-haltige Archive, XML-Entitäten, tiefe JSON-Strukturen, Nullbytes, aktives HTML, Parser-Timeout, Warteschlangenkapazität, Vorschauablauf, Formel-Injection, einen CSV-Import mit 30.000 Datensätzen, ein Zwischenmodell mit 140.000 Zeilen und einen PingCastle-ähnlichen HTML-Bericht mit 5,9 MB. Der PostgreSQL-Integrationstest prüft den tatsächlichen Transaktions- und Persistenzpfad.