Expertise · Cybersicherheit

Die Sicherheit der Anwendungen, die wir bauen und betreiben — in Code geschriebene, von außen überprüfbare Kontrollen, ohne Zertifizierungen, die wir nicht haben.

Die Arbeit deckt die Sicherheit der Anwendung und die Engineering der Vertraulichkeit ab: Header und Content Policy, Ratenbegrenzung, die Standardposition „geschlossen“ von Prüfungen, die Verschlüsselung von Geheimnissen, nicht überschreibbare Protokolle, Anonymisierung von Daten und in Code festgelegte Aufbewahrungsfristen, nicht nur in der Richtlinie. Wir sind keine zertifizierten Prüfer und stellen keine Zertifikate aus.

Ein Projekt besprechen

Bereits gebautAm ales „livrat” pentru un domeniu deliberat îngust, iar limita o scriem înaintea listei de capabilități. Controalele descrise mai jos rulează în sisteme proprii și o parte se pot verifica din exterior chiar acum: limitarea de rată se demonstrează cu douăsprezece cereri consecutive (a zecea primește 429, verificat pe producție la 06.09.2026), sonda de sănătate întoarce doar valori logice, iar antetele de securitate se citesc din răspuns. A doua și a treia implementare citate sunt platforma de sesizări — politică de conținut cu valoare unică per răspuns, listă albă de destinații de rețea verificată în integrarea continuă, autentificare în doi pași obligatorie pentru personal — și clientul de semnătură electronică scris fără nicio dependență nouă, cu apărare împotriva încadrării semnăturii XML. Ce NU susține dovada: nu avem nicio certificare, nu facem testare ofensivă ca serviciu, nu operăm un centru de monitorizare și nu emitem atestate de conformitate.

Die meisten Lücken, die wir in unseren eigenen Systemen gefunden haben, waren keine ausgefeilten Exploits. Es waren Standardwerte. Eine Route, die einen Telefonanruf an irgendeine Nummer initiierte, ohne Authentifizierung, und die seit Langem von keiner Komponente in der Oberfläche mehr aufgerufen wurde. Eine Origin-Prüfung, die durchging, wenn die Liste leer war. Eine vollständige IP-Adresse, die in einer Benachrichtigungsnachricht gesendet wurde, während die öffentliche Seite Anonymisierung versprach. Alle drei standen in unserem Code, und keine davon wäre in einem automatischen Scanner sichtbar gewesen.

Daraus ergibt sich die Form des Dienstes. Wir verkaufen keinen Scanbericht. Wir lesen den Code mit einer präzisen Frage: Wenn diese Prüfung nicht entscheiden kann, was tut sie — erlauben oder verweigern? Die Standardposition ist der Unterschied zwischen einem Tor und einer Dekoration. In unseren Systemen gibt das Verbrauchertor bei einer Ausnahme „unzulässig“ zurück, und die Telefonanruf-Route antwortet mit 404, wenn das Secret nicht konfiguriert ist — das heißt, die Funktion ist deaktiviert, wenn jemand sie nicht absichtlich eingeschaltet hat.

Die zweite Hälfte der Arbeit ist die Ingenieurtechnik der Vertraulichkeit, denn in der Praxis lassen sich die beiden nicht trennen. Die öffentlich deklarierte Aufbewahrungsfrist bedeutet nichts, wenn sie nicht vom Code durchgesetzt wird. Bei uns löscht das Anfrageprotokoll Dateien, die älter sind als die deklarierte Frist, wobei die Tageszahl aus demselben Wert stammt, der in der veröffentlichten Richtlinie erscheint. In einem anderen System hält die Retentionstabelle zu jeder Frist den veröffentlichten Text Wort für Wort und die rechtliche Grundlage daneben — damit Richtlinie und Datenbank nicht stillschweigend voneinander abweichen können.

Was wir über uns selbst veröffentlichen, ist Teil der Methode. Die Inhaltsrichtlinie dieser Website erlaubt `unsafe-inline` und `unsafe-eval` in Skripten. Das ist eine reale Schwäche, und wir schreiben sie hier, nicht in einen internen Bericht — es war sogar der Mechanismus, mit dem unser eigener Barrierefreiheits-Audit ein Prüfwerkzeug direkt in die Produktionsseite einschleusen konnte. Ein Anbieter, der seine eigenen bekannten Schwächen nicht veröffentlicht, kann Ihre nicht finden.

Was dazugehört

Die Arbeit, nach Bestandteilen

Wir lesen die Standardposition jeder Prüfung

Die zentrale Frage der Analyse: Wenn die Prüfung nicht entscheiden kann, erlaubt oder verweigert sie? Reales Beispiel aus unserem eigenen Code, ausdrücklich so markiert: Die Liste der erlaubten Ursprünge eines Widgets lässt die Prüfung durchgehen, wenn die Liste leer ist — eine absichtliche Wahl zur Kompatibilität mit älteren Installationen, im Kommentar vermerkt, die aber bedeutet, dass die Beschränkung auf die Domain bei jeder Implementierung ausdrücklich konfiguriert werden muss. Das Gegenbeispiel: das Verbrauchertor, das bei jeder Ausnahme „unzulässig“ zurückgibt.

Korrekte Ratenbegrenzung hinter einem Proxy

Zehn Anfragen pro Minute und Adresse, mit einer Feinheit, die entscheidet, ob die Grenze funktioniert oder nicht: Der Schlüssel wird aus dem letzten Sprung des Weiterleitungs-Headers genommen, nicht aus dem ersten. Unser Proxy fügt die echte Adresse am Ende dessen hinzu, was der Client gesendet hat, also ist der erste Eintrag vom Angreifer kontrolliert — wer den Schlüssel darauf aufbaut, kann seine Grenze überschreiten, indem er zufällige Werte sendet. Von außen überprüfbar: Zwölf aufeinanderfolgende Anfragen ergeben neun erfolgreiche Antworten, danach 429.

Header und Inhaltsrichtlinie, mit einmaligem Wert pro Antwort, wo möglich

Auf dieser Website: striktes Transport-Security für zwei Jahre mit Subdomains und Aufnahme in die Vorlade-Liste, nicht ableitbarer Inhaltstyp, eingeschränkte Referrer-Policy, Berechtigungsrichtlinie, die die Kamera schließt und Mikrofon und Standort nur für die eigene Seite zulässt. Auf der Beschwerdeplattform, strenger: Die Inhaltsrichtlinie erhält bei jeder Antwort einen einmaligen Wert, im Proxy generiert, ohne Drittquellen für Skripte, Verbindungen oder Schriften, und das Einbetten in Frames wird vollständig verweigert.

Whitelist von Netzwerkzielen, automatisch verifiziert

In einem öffentlichen Projekt wird die Liste der Adressen, die die Anwendung kontaktieren darf, durch einen in der kontinuierlichen Integration ausgeführten Befehl verifiziert, sowohl statisch als auch zur Laufzeit. Ein neues Paket, das anfängt, nach Hause zu telefonieren, fällt bei der Prüfung durch, nicht in der Produktion. Es ist die Kontrolle, die genau die Klasse von Vorfällen aus der Lieferkette auffängt, gegen die sich niemand mit einem Schwachstellenscanner schützt.

Geheimnisse gelangen nicht in Antworten, Protokolle oder Benachrichtigungen

Die Health-Check-Sonde des Kontaktformulars gibt nur logische Werte zurück — ob sie konfiguriert ist, ob die Anmeldedaten gültig sind, ob das Protokoll geschrieben werden kann — niemals das Token, die Gesprächs-ID oder den Bot-Namen. Die Kanal-Token der Messaging-Plattform werden verschlüsselt aufbewahrt. Alarmprotokolle laufen vor dem Schreiben durch ein Modul zur Redigierung personenbezogener Daten.

Anonymisierung vor dem Schreiben angewendet, nicht danach

Die IP-Adresse wird vor der Aufnahme in das Protokoll oder in eine Benachrichtigung auf das Netzwerkpräfix gekürzt — /24 für IPv4, /48 für IPv6. Mit zwei wichtigen Details: Es wird der letzte Hop genommen, nicht der erste, aus demselben Grund wie bei der Ratenbegrenzung; und IPv4-Adressen, die in gemappter IPv6-Form gemeldet werden, werden erkannt und als IPv4 behandelt, andernfalls würden sie vollständig beibehalten, also genau entgegen dem Zweck.

Protokoll, das hinzufügt, nicht überschreibt

Formularanfragen werden in ein Append-Protokoll geschrieben, ein Objekt pro Zeile, mit 0600-Berechtigungen für die Datei und 0700 für das Verzeichnis, bevor die Zustellung versucht wird. Der Grund ist ein realer Fehler: Als der Benachrichtigungskanal ausfiel, gab der Endpunkt 500 zurück und jede Anfrage ging spurlos verloren. Jetzt bedeutet ein defekter Kanal „wir müssen in die Datei schauen“, nicht „die Anfrage hat nie existiert“. Das Zustellungsergebnis wird als zweite Zeile mit derselben Kennung geschrieben.

Die vom Code angewandte Aufbewahrungsfrist, nicht nur deklarierte

Das Anfragenprotokoll löscht Dateien, die älter sind als die öffentlich deklarierte Frist, wobei die Anzahl der Tage aus demselben Wert genommen wird. In einem anderen System führt die Aufbewahrungstabelle neben jeder Frist den wortwörtlich veröffentlichten Text und die rechtliche Grundlage, und die Bereinigungsfunktion meldet standardmäßig, was sie löschen würde; das tatsächliche Löschen erfordert ein explizites Argument. Stilles Löschen ist ein Fehlermodus, keine Funktion.

Identität und Signatur, wenn das Projekt sie verlangt

Wir haben von Grund auf und ohne neue Abhängigkeiten einen Dienstanbieter für föderierte Authentifizierung und einen Client für elektronische Signaturen geschrieben. Der XML-Parser verarbeitet keine Document-Type-Definitionen, daher gilt die Angriffsart über externe Entitäten nicht; die Signaturprüfung gibt den von der Signatur abgedeckten Knoten zurück, nicht einen logischen Wert, und der Aufrufer ist verpflichtet, die Objektidentität zu vergleichen — die Verteidigung gegen Signaturumhüllung. Die Kanonisierung wurde an den offiziellen Vektoren der Spezifikation geprüft.

Wie es aussieht

Der Weg, Schritt für Schritt.

Wir legen den Umfang fest und was wir nicht berühren dürfen

Schriftlich, vor jeder Bestellung: welche Systeme, welcher Zeitraum, welche Arten von Prüfungen erlaubt sind und wer die Kontaktperson ist, falls etwas stoppt. Wir liefern: das unterzeichnete Umfangsdokument und die Liste der ausgeschlossenen Systeme.

Wir lesen den Code und die Konfiguration, mit Schwerpunkt auf der impliziten Position

Prüfungen, die nicht entscheiden können, Geheimnisse, die in Antworten oder Protokollen landen, Pfade, die niemand mehr aufruft, die aber offen bleiben, fehlende Header. Wir liefern: die Feststellungen mit Datei und Zeile, geordnet nach dem, was man damit tun kann, nicht nach der theoretischen Schwere.

Wir beheben oder beschreiben die Behebung genau

Wo wir Zugriff haben, setzen wir die Kontrolle und schreiben den Test, der sie festhält — eine Prüfung ohne Test geht bei der ersten Refaktorisierung verloren. Wo wir keinen Zugriff haben, liefern wir die Änderung so präzise beschrieben, dass das Kundenteam sie anwenden kann, ohne uns noch einmal zu fragen.

Wir verknüpfen Vertraulichkeit mit Code

Aufbewahrungsfrist, Anonymisierung und Empfängerliste werden zu Werten im Code, zusammen mit dem veröffentlichten Text. Wir liefern: das ausgefüllte Verarbeitungsverzeichnis mit der Spalte „wo implementiert“ gefüllt und die Liste der noch zu entscheidenden Punkte, mit jeweils der entscheidenden Person.

Wir prüfen von außen, was von außen geprüft werden kann

Header, Verhalten an der Grenze, was die Health-Checks zurückgeben. Wir liefern: die genauen Prüfbefehle, damit jeder — einschließlich eines Auditors des Kunden — die Prüfung ohne uns wiederholen kann.

Straturile pe care le atingem, de sus în jos

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Was wir in einer Analyse erfassen: Den Code, die Serverkonfiguration, die Antwort-Header und, wo es der Fall ist, das Datenbankschema sowie die Zugriffsrichtlinien Zeile für Zeile. Wir brauchen keine realen Kundendaten, um die Analyse durchzuführen, und wir ziehen es vor, sie gar nicht anzurühren.
Was wir ohne schriftlich autorisierten Umfang nicht tun: Keine Handlung, die Verkehr gegen ein laufendes System erzeugt. Die auf dieser Seite genannten Prüfungen in Produktion sind gewöhnliche Leseanfragen auf eigenen Systemen. Jede Überschreitung dieser Grenze erfordert eine schriftliche Autorisierung mit Zeitraum und Adressen, unterzeichnet von der Person, die das Recht hat, sie zu erteilen.
Wohin die Feststellungen gelangen: In ein Dokument mit einer Feststellung pro Zeile: wo sie ist, was man damit tun kann, was sie genau behebt und wie die Behebung geprüft wird. Feststellungen, die einen Ausnutzungspfad beschreiben, laufen nicht über unsichere Kanäle und gelangen nicht vor der Behebung in öffentliche Materialien.
Verarbeitungsregister: Für den Teil der Vertraulichkeit ist das Ergebnis ein Register mit einer Zeile pro Tätigkeit: Zweck, Rechtsgrundlage, Datenkategorien, Empfänger, Übermittlungen, Speicherort, Frist, Maßnahmen und die Datei im Code, in der es implementiert ist. Was nicht verifiziert werden konnte, wird als „unverifiziert“ eingetragen, nicht aus einer Vorlage ergänzt.
Die Regel, die die Richtlinie an den Code bindet: Wenn eine Codeänderung ändert, was erhoben wird, wem es zugeht oder wie lange es aufbewahrt wird, wird die veröffentlichte Richtlinie im selben Lieferumfang angepasst. Die Abweichung zwischen der veröffentlichten Richtlinie und dem Code war genau das Problem, das uns dazu gebracht hat, unser eigenes Register zu schreiben.

Ein Fall

Ein vergessener Pfad, der jeden hätte anrufen können

Die Ausgangslage

Bei einer Überprüfung unserer eigenen Website stießen wir auf einen API-Pfad, der einen Telefonanruf an jede im Anforderungstext übermittelte Nummer auslöste. Ohne Authentifizierung, auf Kosten und über die Nummer der Firma. Keine Komponente der Benutzeroberfläche rief ihn mehr auf — der einzige Aufrufer war ein Element, das nicht mehr angezeigt wurde. Das heißt, er war offen ins Internet verfügbar, ohne dass jemand einen Grund hatte, ihn sich anzusehen.

Was wir gebaut haben

Wir haben es als zwei Probleme behandelt, nicht als eines. Technisch: Der Pfad verlangt jetzt ein geteiltes Geheimnis in einem Header, und wenn das Geheimnis gar nicht konfiguriert ist, antwortet er mit 404 — die Fähigkeit ist abgeschaltet, wenn jemand sie nicht ausdrücklich einschaltet, nicht eingeschaltet, bis jemand sie abschaltet. Rechtlich und ethisch: Ein automatischer unerbetener Anruf ist eine Datenverarbeitung, die die angerufene Person nicht angefordert hat, also haben wir im Register festgehalten, was für eine mögliche Reaktivierung notwendig wäre — dokumentierte Rechtsgrundlage gegenüber der angerufenen Person, Nachweis der Einwilligung und ein Widerspruchskanal.

Was dabei herauskam

Die Fähigkeit ist standardmäßig geschlossen und bleibt geschlossen, bis jemand eine ausdrückliche Entscheidung trifft. Die Zeile im Verarbeitungsregister beschreibt den Zustand, den früheren Zustand, das Risiko und die Bedingungen für die Reaktivierung — damit die nächste Person, die den Pfad findet, die Begründung nicht neu zusammensetzen muss.

Was der Fall nicht sagt

Wir haben das nicht durch ein Werkzeug bemerkt. Wir haben es gefunden, indem wir die Pfade einzeln gelesen und für jeden gefragt haben, wer ihn aufruft. Ein automatischer Scanner hätte einen Pfad gesehen, der auf eine leere Anfrage 400 zurückgibt, und wäre weitergegangen. Das ist auch die Grenze der Methode: Sie deckt ab, was wir lesen, und was wir nicht lesen, bleibt unbedeckt — deshalb wird der Umfang schriftlich festgelegt.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Haben Sie Sicherheitszertifizierungen?

Nein. Weder ISO 27001 noch SOC 2, noch eine Zertifizierung für offensive Tests, noch eine Auditor-Akkreditierung. Wir stellen keine Zertifikate aus und unterzeichnen keine Konformitätsbestätigungen. Was wir zeigen können, ist die eigene Praxis mit Datei und Zeile sowie die Kontrollen, die wir in laufende Systeme eingebaut haben. Wenn Sie für eine Akte ein Zertifikat brauchen, brauchen Sie eine akkreditierte Stelle, nicht uns — und es ist besser, das jetzt zu erfahren.

Führen Sie Penetrationstests durch?

Nicht als Dienstleistung. Wir haben kein offensives Testteam, keine Lizenz oder zertifizierte Methodik, und wir tun nicht so, als hätten wir welche. Was wir tun, ist Code- und Konfigurationsanalyse sowie nicht-invasive Prüfungen von außen — Header, Verhalten an der Rate-Grenze, was Fehlermeldungen preisgeben. Wenn das Projekt echte offensive Tests erfordert, brauchen Sie ein spezialisiertes Unternehmen; wir können mit ihm bei der Behebung zusammenarbeiten.

Was haben Sie in Ihren eigenen Systemen gefunden?

Drei Dinge, an einem einzigen Tag der Analyse, alle öffentlich in unserem Register dokumentiert. Eine Route, die einen Telefonanruf an jede Nummer im Anfragetext initiiert, anonym, ohne Authentifizierung, die keine Komponente in der Oberfläche mehr aufgerufen hat — jetzt liefert sie 404, wenn das Geheimnis nicht konfiguriert ist, das heißt, sie ist abgeschaltet, wenn jemand sie nicht bewusst startet. Ein Chat-Widget, das bei jeder Ansicht geladen wurde und die Sitzung im Browser-Speicher schrieb, bevor der Besucher etwas angefordert hatte — jetzt wird es beim Drücken der Schaltfläche geladen. Und die vollständige IP-Adresse, die in einer Benachrichtigung gesendet wurde, obwohl die öffentliche Seite Anonymisierung versprach — jetzt wird sie vor dem Schreiben gekürzt.

Ihre Inhaltsrichtlinie erlaubt `unsafe-eval`. Warum sollte ich Ihnen glauben?

Weil wir es Ihnen gesagt haben, nicht weil Sie es selbst herausgefunden haben. Ja, die Richtlinie dieser Seite erlaubt `unsafe-inline` und `unsafe-eval` in Skripten — das ist eine reale Schwachstelle, übernommen aus der Art, wie bestimmte Drittanbieter-Skripte geladen werden, und es ist genau der Mechanismus, durch den unser eigenes Barrierefreiheits-Audit ein Prüfwerkzeug in die Produktivseite injiziert hat. Bei einem Projekt, bei dem wir die Einschränkung von Anfang an setzen, ist die richtige Form die aus der Beschwerdeplattform: ein eindeutiger Wert pro Antwort, im Proxy erzeugt, und keine Drittquelle für Skripte. Der Unterschied zwischen den beiden ist genau die Diskussion, die wir am Anfang eines Projekts führen sollten, nicht am Ende.

Wie prüfe ich, ohne Ihnen zu glauben, dass die Ratenbegrenzung funktioniert?

Indem Sie zwölf aufeinanderfolgende Anfragen an eine API-Route dieser Seite senden und die Antworten zählen: Die ersten neun gehen durch, die zehnte erhält 429 mit dem Header, der sagt, nach welcher Zeit erneut versucht werden kann. Das Zeitfenster beträgt eine Minute. Der Befehl steht in der Quellliste dieser Seite und Sie können ihn jetzt ausführen. Dasselbe Prinzip wenden wir bei dem an, was wir liefern: Wenn eine Kontrolle von außen durch den Kunden nicht überprüfbar ist, wird sie nicht geliefert, sondern deklariert.

Was geschieht mit personenbezogenen Daten aus einem Formular?

Sie werden in ein Anfügeprotokoll geschrieben, ein Objekt pro Zeile, mit eingeschränkten Rechten auf Datei und Verzeichnis, bevor die Zustellung versucht wird — damit ein defekter Benachrichtigungskanal die Anfrage nicht verschwinden lässt. Die IP-Adresse wird vor dem Schreiben auf das Netzwerkpräfix gekürzt. Ältere Dateien als die deklarierte Frist werden gelöscht, wobei die Anzahl der Tage aus demselben Wert stammt, der in der veröffentlichten Richtlinie erscheint. Und die Zeile im Verzeichnis der Verarbeitungen sagt für jedes Element, in welcher Datei im Code es implementiert ist.

Können Sie die Anmeldung mit staatlicher elektronischer Identität oder elektronischer Signatur durchführen?

Der Code existiert und ist getestet, aber in der Produktion nirgendwo aktiviert, und der Unterschied ist wichtig. Wir haben einen Dienstanbieter für föderierte Anmeldung und einen Signatur-Client geschrieben, beide ohne neue Abhängigkeiten, mit implementierten spezifischen Schutzmaßnahmen und mit Tests. Was fehlt, betrifft nicht den Code: Vertrag mit der Behörde, Systemzertifikat und Registrierung der Produktionsadresse. Bis dahin ist die heute funktionierende Variante die, in der der Bürger auf dem offiziellen Portal unterschreibt und das unterzeichnete Dokument zurücklädt.

Welche Kontrollen setzen Sie normalerweise in einer neuen Anwendung ein?

Header und Content Policy mit eindeutigem Wert pro Antwort; Ratenbegrenzung mit dem korrekt hinter dem Proxy ermittelten Schlüssel; Mandantentrennung in der Datenbank, nicht nur in der Anwendung; verschlüsselte Geheimnisse und niemals in Antworten oder Protokollen; Idempotenzschlüssel für Ereignisse von Dritten; obligatorische Zwei-Faktor-Authentifizierung für Mitarbeiterkonten; Audit-Protokoll mit getrenkter Sichtbarkeit für intern und öffentlich; und für öffentliche Projekte eine automatisch bei jeder Lieferung überprüfte Whitelist von Netzwerkzielen.

Was deckt dieser Dienst nicht ab?

Die Sicherheit des Firmennetzwerks, Benutzergeräte, kontinuierliches Monitoring durch ein Operations Center, Incident Response 24/7, forensische Untersuchung und Phishing-Schulungen. Das sind keine Dinge, die wir schlecht machen — das sind Dinge, die wir nicht machen. Unser Bereich ist die Anwendung, die wir bauen oder übernehmen, plus die Daten, die durch sie fließen.

Worauf die obigen Aussagen beruhen (24 Quellen)

Verificat pe producție: 12 cereri consecutive dau 9 răspunsuri 200, apoi 429https://www.megapromoting.com/api/health/contact · 2026-09-06
Antete pe producție: transport strict 63072000 s cu subdomenii și precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera; încadrarea în cadru e refuzată complet pe rutele de interfață de programare și limitată la aceeași origine pe paginihttps://www.megapromoting.com/api/health/contact · 2026-09-06

22 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Wie wir arbeiten Alle Dienstleistungen

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen