Heartbleed Schwachstellentests
Überprüfen Sie jede Webserver-Fehlkonfiguration in Ihrem Server und vermeiden Sie Heartbleed-Schwachstellen in jedem SSL/TLS-Zertifikat.
- OpenSSL-Angriffsvektoren in Ihrer API / REST API oder Webanwendung automatisch erkennen
- Umfassende Berichte mit Lösungen zur Behebung jeder Schwachstelle und Integration mit mehr als 20 Systemen und Tools
- Schnelle Sicherheitsbewertung mit wenigen False Positives
- Automatisierte Online SaaS Heartbleed Schwachstellentests
Funktionen
Scanner Funktionen von denen Sie profitieren
Die Erkennung von Eindringlingen und die Bewertung der tatsächlichen Ausnutzungsversuche und Erfolge des Heartbleed-Problems sind eine Herausforderung, da die Angriffe keine Spuren in den Protokollen hinterlassen. Mit Crashtest Security haben Sie jetzt eine schnelle und einfache Möglichkeit, diese Probleme zu vermeiden, indem Sie Ihre Web-App absichern.
Zeitlicher Plan
Zeitplan für Scans erstellen
Konfigurieren
Credentials konfigurieren (System und Anwendung)
CI-Integration
Erstellen Sie einen Webhook und starten Sie einen Scan über die CI-Integration
Benachrichtigungen einstellen
Chat-Benachrichtigung einbinden (z.B. Slack)
Berichte erhalten
Erhalten Sie ausführliche Berichte mit Empfehlungen zur Behebung
Nutzen
Vorteile des Heartbleed Bug Tests
- Laden Sie PDF-, JSON/XML- und CSV-Berichte herunter und geben Sie sie mühelos an Kollegen, Führungskräfte und Kunden weiter.
- Verringern Sie Ihre Anfälligkeit für Hackerangriffe und schützen Sie Ihre Benutzer vor den OWASP Top 10 Sicherheitslücken.
- Scannen und bewerten Sie die Sicherheit von Komponenten Dritter in Ihrer Online-Anwendung.
- Analysieren Sie die Sicherheit von APIs und Microservices mit einem automatisierten Tool.
- Integrieren Sie unseren Schwachstellen-Scanner ganz einfach in Ihren Entwicklungsprozess und Workflow.
Berichte
Heartbleed-Bug-Berichte
Der Heartbleed-Report zeigt, wie unser automatisiertes Tool API-Schwachstellen testet, findet, klassifiziert und deren Behebung empfiehlt und dabei stundenlange Sicherheitsprüfungen durch Menschen und Kosten für Pentests spart.
Umfassende Schwachstellenerkenntnisse
Der Bericht beginnt mit einer Übersicht über die Schwachstellen des Scan-Ziels, dem Schweregrad der aufgedeckten Schwachstellen und einer Checkliste der ausgenutzten Angriffsvektoren und des Scanner-Status.
Ratschläge zur Behebung
Zu jeder entdeckten Schwachstelle gibt es eine Risikokategorisierung, eine Erklärung und Empfehlungen zur Behebung des Problems.
Checkliste der gefundenen Schwachstellen
Zur Übersicht darüber, welche Schwachstellen bereits behoben oder gemeldet wurden.
Kontinuierliche Sicherheit
Weitere Gründe für kontinuierliche Heartbleed-Bug-Tests
Automatisiertes Pentesting
Führen Sie regelmäßig Black-Box Pentests für Ihre Web-Assets durch und sparen Sie sich die Kosten für unregelmäßige manuelle Penetrationstests.
Cybersecurity-Risikos verringern
Vergleichen Sie Ihre geplante Version mit den OWASP Top 10 und anderen bekannten Sicherheitslücken.
Scans terminieren
Passen Sie das Scannen von Sicherheitslücken an Ihren agilen Entwicklungszyklus an.
Konformität gewährleisten
Scannen Sie jede neue Version vor der Einführung und stellen Sie die Einhaltung von Vorschriften und Standards (HIPAA, GDPR, ISO und viele mehr) sicher.
Sicherheitslücken schneller erkennen
Erkennen und entschärfen Sie Schwachstellen schneller, indem Sie Ihre Web-Assets regelmäßig scannen.
Integrierte Entwicklungspipeline
Integrieren Sie Schwachstellen-Scans in Ihre Entwicklungsprozesse und -umgebung und verlagern Sie die Sicherheit nach links.
Andere relevante Schwachstellenscanner
Heartbleed Tests
Wie kann man Hearbleed verhindern?
Zunächst einmal müssen Sie OpenSSL auf die neueste Version aktualisieren. Mit den folgenden Versionen wurde die Heartbleed-Schwachstelle behoben:
OpenSSL 1.0.1g
OpenSSL 1.0.0 (nicht betroffen)
OpenSSL 0.9.8 (nicht betroffen)
Z.B., ausführen:
apt-get update; apt-get upgrade # Debian / Ubuntu
yum update # RHeL / CentOS
pacman -Syu # Arch Linux
Dieser Schritt ist wichtig, denn wenn Sie anfällige Versionen von OpenSSL verwenden, bleibt das Risiko von Angriffen bestehen.
Wo waren die Anfänge des Heartbleedangriffs?
Ende 2011 steuerte der 31-jährige deutsche Ingenieur Robin Seggelmann die fehlerhafte Heartbeat-Funktionalität zu einer experimentellen Version von OpenSSL bei, der eine Validierungsmethode für eine Variable mit Länge fehlte. Daraufhin wurden seine Funktionen zur Bewertung an OpenSSL geschickt, doch auch die dortigen Entwickler übersahen die Fehler.
Seit wann gibt es die anfälligen Versionen von OpenSSL?
Bevor das Problem gefunden und veröffentlicht wurde, waren anfällige Versionen von OpenSSL bereits seit mehr als zwei Jahren im Umlauf – seit März 2012. Infolgedessen waren Computer, auf denen frühere Versionen von OpenSSL (vor 1.0.1) liefen, nicht betroffen.