Anbindungssicherheit des Control Panels

Geschätzte Lesedauer: 1 min

API

  • Zugriff auf API-Funktionen ausschließlich via SSL-Kommunikation erlaubt
  • Zugriff auf API-Funktionen ausschließlich via POST
  • Zugriff auf API-Funktionen nur mit gültigem Hornetsecurity-Account
  • Zugriff gesteuert über IP-Restriktionen und Passwort und Tokenkomplexität
  • Authentifizierung resultiert in einem Autorisationstoken (Gültigkeit xx Minuten)
  • Das vorab generierte Token ordnet benutzerempfindliche Daten, welche vom Server aus vorgehalten werden, zu
  • Zugriffssteuerung auf Funktionen anhand des Autorisationstokens (nicht alle dürfen jede Funktion benutzen)
  • Sowohl die Weitergabe durch Hibernate, wie auch der Rückgabewert des Backends werden geprüft und vor der Auswertung validiert, bevor eine Antwort generiert wird (SQL-Injection)
  • (D)DOS-Schutz durch vorgelagerten Webservice
  • Security Manager verhindert Ausführung von unerwünschten/nativem/externen Code

FLEX

  • Der Disassemlierungsschutz ist mithilfe von Obfucation zu 100% vorhanden. Deshalb ist Flex nur zur Darstellung da. Hier werden im Quelltext keine wichtigen informellen Daten gespeichert (IP-Adressen, interne Verzeichnisstrukturen, Passwörter, etc.)
  • SQL-Injection protection
    • Vorfilterung der Benutzereingaben
    • Zusätzliche Parameter- und Syntaxvalidierung im Backend (Library-gestützt)
    • Gefilterte Ausgabe der Rückgabewerte
  • Man in the Middle
    • Die Kommunikation findet ausschließlich über eine SSL Verschlüsselung statt. Außerdem ist die Zertifikatsvalidierung nicht umgeh bar.
  • Remote Code Execution
    • Backend: Keine Code-Execution von Fremddaten möglich (keine off-site includes)
    • FLASH: kein Nachladen von externen/nicht vertrauenswürdigen Codes möglich durch Sandboxing, SameOriginPolicy
  • Cross Site Scripting
    • SameOriginPolicy und Sandboxing
  • Die Parameter können nur mit der Ausführung des Flash-Codes übergeben werden
War dieser Artikel hilfreich?
Dislike 0
Views: 12