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

Wie steht es mit der API Sicherheit Deiner API?

Wie kannst Du eine API sicher programmieren?

Diese Fragen möchte ich in diesem Beitrag klären!

Starten wir!

Dilemma einer Entwicklung einer API

Der API-Entwickler hat nur 1 Chance.

Wenn die API veröffentlicht ist, kann dieser die API später nicht ändern. Eine Versionierung kann die API erneuern, aber die Änderungen müssen alle anderen Entwickler, die die API verwenden, nachziehen. Du machst Dich schnell unbeliebt, wenn Du keine fixe solide API lieferst.

Eine grandiose API verwendet das folgende Design-Prinzip:

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

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

Typen von APIs

Die APIs können Entwickler …

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

… gruppieren. Je nach Verwendung eignen sich die APIs unterschiedlich gut.

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 erfüllen. Zu den Mustern gehören Backend-for-Frontend und das Gateway.

Normalerweise richtet sich ein Frontend an das Backend mit den 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, TV). 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 liefern soll.

Ein Gateway stellt eine zentrale Ansprechstelle für Frontends, andere Schnittstellen und Anwendungen dar. Ein Gateway gleicht einen Makler, der 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)
• Bereiche setzen (Umsetzung von Domain Driven Design)
• Routing (Vermittlung von Services)
• Überwachung

… sicherzustellen.

API Sicherheit – 12 besten Strategien

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

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

Kryptografische Strategien

• #1 Verwende einen sicheren Kanal
  HTTPS blockt Man-in-the-Middle-Angriffe. Dritte werden nicht aus dem Bitsalat schlau.
• #2 Keine offenen Tokens mehr
  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 SAML, 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 / Berechtigung 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
  Jeder Nutzer erhält mit der Anmeldung ein Abfrage-Maximum pro Monat. Exzessive Abfragen und Data Breaches 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. Die API soll nicht mit allen Spalten aus einer Tabelle antworten, nur weil diese vorhanden sind. Der Anfrager bekommt nur die Informationen, zu den der Anfrage berechtigt ist.

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 den DDoS-Attacke-Beitrag durch, um mehr Verständnis von diesem Typ des Angriffs 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 Krimineller zeigt ein anderes API-Abfrage-Verhalten auf. Ungewöhnliche Abfragen, Zeiten und Datenmengen können auf einen Kriminellen 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 vor der Ausführung 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 die Entwickler betriebsblind durch seine Arbeit ist. Penetration Tester führen White-Box- und Black-Box-Hacking-Test durch, die viele Probleme aufdecken.

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 Plural für Schnittstellen

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

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

Regel #3 Verstecke Parameter in JSON

HTTPS schützt nicht die URL. Deshalb schreibe alle Parameter in den Body. So vermeidest Du einen Mini Data Breach mit jeder Abfrage.

NICHT
/bank/transaction/?=transfermoney=200&to=Horst%20Schrader

BESSER
POST /bank/transaction/

{„transfermoney: 200, „to“: „Horst Schrader“}

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.
  • „Ihr Authentifizierung-Schlüssel ist Gehen sie auf https://webseite.de/update/oauth, um einen neuen zu beantragen.“
• Formuliere kristallklar Deinen Fehlertext.
  • NICHT: „Ein Fehler ist aufgetreten!“ BESSER: „Der Bilddatei ist nicht im richtigen Format.“
• Vermeide Standard-Floskeln in der Fehlerbeschreibung.
  • NICHT „Fehler! Versuchen sie es später noch einmal!“