API Sicherheit – 12 Sicherungen für REST + GraphQL API

Wie stehts mit Der API Sicherheit Deiner API?

Wie kann ich eine API sicher programmieren?

Diese Fragen möchte ich in diesem Post klären:

Eine State-of-the-Art-API bezeichnet eine Programmierschnittstelle, die sich durch den letzten / höchsten Standard der Technik auszeichnet. Eine REST- oder GraphQL-API besitzt für mich (in November 2019) alle Eigenschaften einer State-of-the-Art-API.

Steffen Lippke

Die optimale API schützt sich mit oAuth und besteht aus sich-selbst beschreibenden Schnittstellen, die gut verständlich für jeden Entwickler (Developer Experience).

Entwicklung einer API

Der API-Entwickler hat nur 1 Chance nutzen.

Wenn die API veröffentlicht ist, kann dieser die API später nicht ändern. Eine Versionierung können die Entwickler zur Weiterentwicklung einführen – die Entwickler der nutzenden Applikationen müssen mitziehen.

Eine grandiose API verwendet das folgende Design-Prinzip:

So einfach wie möglich – so schlank wie möglich.

Die API-Entwickler haben „am Anfang das Ende im Sinn“:

Die Entwickler formulieren Anwendungsfälle und fragen Kunden, was die API leisten soll.

Typen von APIs

Die APIs können Entwickler …

  • … nach Besitz: Offene / Geschlossene
  • … nach Zugang: Frei / Kommerziell
  • … nach Datentyp: JSON, XML, SOAP
  • … nach Inhalt: abstrakte, explizite, Web Service

gruppieren. Je nach Verwendung eignen sich die APIs unterschiedlich gut

Gute Benennung – Developer Experience fördern

In meinem dreiteiligen Clean-Code-Guide habe ich viel über die korrekte Benennung geschrieben. Bei APIs können die Entwickler viel falsch machen. Die Schnittstellen und Parameter sollten spezifisch und inhaltlich korrekt benannt sein, sodass ein Dritter die API gut verstehen kann.

Regel #1: Verwende NUR Nomen für die URL

NICHT Funktionsnamen 
/getAllPosts/ … gibt per JSON 13 Blogposts zurück.

BESSER Nomen
/posts/ … gibt per JSON 13 Blogposts zurück.

Regel #2 Verwende den englischen Plural bei Beschreibung von Objekten

NICHT Singular
/post/ … gibt per JSON 13 Blogposts zurück.

BESSER Plural
/posts/ … gibt per JSON 13 Blogposts zurück.

Regel #3 Nutze mehr Parameter statt Schnittstellen

NICHT neue Schnittstellen
/getFeaturesPosts/

Lieber. /post?type=features

Hilfreiche Fehlermeldungen erstellen

Verwende für die Fehlermeldungen Deiner API die Standard-HTTP-Fehlermeldung (nach RFC-Definition):  Versende neben dem Code als Nachrichtentext einen aussagekräftigen Fehlertext.

  • Gebe Hinweise, dass der Code der API einen Fehler produziert.
    • „Ihr Authentifizierung-Schlüssel ist abgelaufen …“
  • Gebe Anleitungen, wie der Nutzer den Fehler beheben kann.
  • Formuliere kristallklar Deinen Fehlertext.
    • NICHT: „Ein Fehler ist aufgetreten!“ BESSER: „Ein Fehler bei der Authentifizierung ist Ihr Token stimmt nicht.“
  • Vermeide Standard-Floskeln in der Fehlerbeschreibung.
    • NICHT „Fehler! Versuchen sie es später noch einmal!“

Software-Architektur für API Sicherheit

Die Software-Architektur plant Software-Projekte auf einer abstrakten Ebenen. Diese verwendeten Muster (Patterns), um wiederkehrende Standard-Probleme mit Software-Lösungen zu efüllen. Zu den Mustern gehören Backend-for-Frontend und das Gateway.

Normalerweise richtet sich ein Frontend an das Backend und die angebotenen Schnittstellen. Bei Backend-for-Frontend passt sich das Backend an die Bedürfnisse der Frontends an.

Backend-for-Frontend eignet sich für verschiedene Client-Typen (Desktop, Smartphone, Fernseher). Graph-QL stellt die Grundlage für ein BBF-Backend zur Verfügung. Das Frontend muss mit einem erweiterten API-Aufruf dem Backend mitteilen, welche Inhalte das Backend individuell liefern soll.

Ein Gateway stellt eine zentrale Ansprechstelle für Frontends, andere Schnittstellen und Anwendungen dar. Ein Gateway gleicht einen Immobilen-Makler, der statt Wohnungen Services vermittelt. Dieses Muster verwenden Architekten, um die …

  • Sicherheit / Authentisierung (über Token oder Passwörter)
  • Zentralisierung (Vereinheitlichung der Services)
  • Load Balancing (Verteilung der Arbeitslast auf verschiedene Microservices)
  • Caching (wiederholende Abfrage = gleiche Antwort)
  • Logging (Forensik)
  • Domainisierung (Umsetzung von Domain Driven Design)
  • Routing (Vermittlung von Services)
  • … und Überwachung …

…sicherzustellen.

API Sicherheit – 12 Stategien

Eine „State-of-the-Art“-API muss sicher sein.

Die API muss Hackern keine Chance lassen, die API auszuschalten, zu überlasten oder zu zerstören. Folgenden Konzept helfen bei der Sicherung:

Kryptografische Strategien

  • #1 Verwende einen sicheren Kanal
    HTTPs kann Man-in-the-Middle-Angriffe abblocken. Aus den übermittelten Bits können für Dritte keine Informationen extrahieren.
  • #2 Keine offenen Informationen
    HTTPs verschlüsselt nur die Inhalte / Payload der Nachricht. Die URL können Sniffer mitlesen. Ein API-Keys oder geheime Inhalte sollte nicht in der URL ablesbar sein.
  • #3 Authentisierung für API Sicherheit einführen
    Zum Authentifizieren können die Entwickler statt Nutzernamen und Passwörter Token verwenden. Ein API-Schlüssel, das klassische Benutzername/Passwort und das OpenID-Connect mit OAuth schützen APIs weltweit.

#2 Secure by Design

  • #4 So wenig Rechte wie möglich
    Ein gutes Berechtigungskonzept besagt, dass der „neu angelegte“ Nutzer keinen Zugriff / Berichtigung auf irgendeinen Service hat. Wenn der Nutzer nachfragt und der Admin dem Nutzer und dessen Fähigkeiten vertraut, schaltet er nur die angefragte Funktionen frei.
  • #5 Quoten festlegen
    Jeden Nutzer erhält mit der Anmeldung ein Abfragemaximum pro Monat. Exzessive Abfragebefehle und -prozesse kann eine solche Einschränkung verhindern. Die angebundenen Kunden können gegen Entgelt mehr Abfragekapazität anfragen, sodass die API-Betreiber Ihre Server ausbauen und betreiben können.
  • #6 Minimalistische Antworten
    Die API soll nur die angefragten Daten senden. „Nebensächliche“ Informationen zu der API oder der Abfrage können ein Sicherheitsrisiko sein. Die erhörten Datenmengen durch die „extra“ Daten belasteten den API-Server und Bandbreite der Leitung unnötig.

Schutz vor Hackern für API Sicherheit

  • #7 Nutze einen DDoS-Schutz
    Hacker versuchen bei einem Distributed-Denail-of-Service-Angriff den Service mit Anfragen zu überlasten. Lesen meine DDoS-Attacke-Post durch, um mehr Verständnis von diesem Typ der Attacke zu bekommen.
  • #8 Machine Learning Erkennung
    Abfrage-Abnormalitäten wie ein Hacker-Angriff kann ein Machine-Learning-Algorithmus erkennen und den gestohlenen Account frühzeitig sperren.
    Echte menschliche Nutzer weisen ein natürliches Verhalten auf. Die meisten Abfragen finden zwischen 8 und 16 Uhr statt. Die API verzeichnet natürliche Leistungsspitzen um 10 und 15 Uhr. Ein Hacker zeigt ein anderes API-Abfrage-Verhalten. Ungewöhnliche Abfragen, Zeiten und Datenmengen können auf einen Hacker hinweisen.
  • #9 Gewährleiste eine sichere Basis
    Der API-Server-Software sollte upgedatet sein und starke Passwörter verwenden. Viele IT-Betreiber ändern die Standard-Passwörter von den Routern nicht. Der Hacker muss nur nach dem Standard-Passwort von Router XY googeln, um sich einen Zugang zu verschaffen.
  • #10 Baue Web Application Firewall ein
    Diese Firewall basiert auf Regeln, um SQL-Injektion und XSS-Angriffe abzuwehren. Die Web Application Firewall schützt die Server vor Datenverlust und Datenlecks.

Bonus API Sicherheit

  • #11 Überwache die API
    Mit Tools wie Splunk kannst Du die Aktivität Deiner API überwachen, analysieren und in Echtzeit abfragen, sodass Du über Unregelmäßigkeiten und Angriffe informiert bist.
  • #12 Penetration-Testung
    Viele API-Hersteller glauben, dass sie die sicherste API der Welt entwickeln. Ein Dritter von außerhalb findet in wenigen Minuten ernstzunehmende Sicherheitsrisiken, weil der Hersteller mit betriebsblind gegenüber seinem eignen Produkt ist. Penetration Tester führen White-Box- und Black-Box-Hacking-Test durch, die viele Probleme aufdecken

Kommentare 1

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.