23 Punkte von GN⁺ 2024-05-29 | 5 Kommentare | Auf WhatsApp teilen
  • TL;DR: Statt API-Aufrufe von HTTP auf HTTPS umzuleiten, sollte ein Fehler signalisiert werden. HTTP sollte vollständig deaktiviert oder eine eindeutige HTTP-Fehlerantwort zurückgegeben werden, und API-Schlüssel, die über unverschlüsselte Verbindungen gesendet wurden, sollten widerrufen werden. Leider tun das derzeit viele bekannte API-Anbieter nicht.

Hintergrund

  • Wenn Webbrowser eine HTTP-URL aufrufen, leitet der Dienst die Anfrage oft auf eine HTTPS-Seite um.
  • Der anfängliche HTTP-Traffic ist unverschlüsselt und daher anfällig für Man-in-the-Middle-(MITM)-Angriffe.
  • Technologien wie HSTS (HTTP Strict Transport Security) wurden eingeführt, um die Sicherheit zu erhöhen.

Das Risiko eines einfachen Tippfehlers

  • Bei der Integration mit einer Drittanbieter-API wurde während der Arbeit versehentlich die API-Basis-URL mit http:// statt https:// eingetragen.
  • fetch in Node.js folgt stillschweigend der Weiterleitung zu HTTPS.
  • Der API-Schlüssel wurde im Klartext übertragen, wodurch ein Sicherheitsrisiko entstehen konnte.
  • Der Fehler wurde im Code-Review entdeckt und behoben.

Das Fail-fast-Prinzip

  • Wenn eine API HTTP-Anfragen auf HTTPS umleitet, kann ein Tippfehler leicht unbemerkt bleiben.
  • Es ist besser, dem Fail-fast-Prinzip zu folgen: Unverschlüsselte API-Aufrufe sollten eindeutig fehlschlagen.
  • Am besten deaktiviert man die HTTP-Schnittstelle des API-Servers oder gibt für HTTP-Anfragen eine Fehlermeldung zurück.

Beispiele anderer APIs

  • Mehrere bekannte APIs geben für HTTP-Anfragen einen 403-Fehler zurück oder haben die HTTP-Schnittstelle deaktiviert.
  • Einige APIs leiten jedoch weiterhin von HTTP auf HTTPS um.

Warum Best Practices nötig sind

  • Bei nutzerorientierten Anwendungen ist die Umleitung von HTTP auf HTTPS üblich.
  • Im Fall von APIs kann eine Umleitung von HTTP auf HTTPS jedoch eher schädlich sein.
  • Sicherheitsprojekte wie OWASP brauchen klare Richtlinien für APIs.

Fazit

  • APIs sollten unverschlüsselte Anfragen klar fehlschlagen lassen, statt sie von HTTP auf HTTPS umzuleiten.
  • API-Schlüssel, die über unverschlüsselte Verbindungen gesendet werden, sollten sofort widerrufen werden.
  • API-Sicherheits-Best-Practices müssen aktualisiert werden, um klare Richtlinien bereitzustellen.

Meinung von GN⁺

  • Notwendigkeit stärkerer Sicherheit: API-Sicherheit ist äußerst wichtig, und eine Umleitung von HTTP auf HTTPS kann Sicherheitslücken verursachen.
  • Fail-fast-Prinzip: Es ist wichtig, dem Fail-fast-Prinzip zu folgen, damit Fehler früh in der Entwicklung entdeckt und behoben werden können.
  • Aktualisierung der Best Practices: Sicherheitsprojekte wie OWASP sollten klare Richtlinien zur API-Sicherheit bereitstellen.
  • Automatischer Widerruf von Schlüsseln: API-Schlüssel, die über unverschlüsselte Verbindungen gesendet wurden, sollten automatisch widerrufen werden.
  • An anderen APIs orientieren: Es ist sinnvoll, Sicherheitspraktiken anderer APIs als Referenz zu nutzen, um die eigene API-Sicherheit zu verbessern.

5 Kommentare

 
wkang586 2024-06-03

Das scheint ein Bereich zu sein, der gesetzlich reguliert werden sollte.
Erst mal als Notiz ... Keine HTTPS-Weiterleitungen bei APIs

 
koxel 2024-05-31

Technisch ist das zwar korrekt,
aber bei den meisten Unternehmenskunden gibt es aus Sicherheitsgründen die Vorgabe, bei HTTP-Zugriffen grundsätzlich auf HTTPS umzuleiten.
Außerdem vermeiden sie es, ihren eigenen Kunden überhaupt Fehlermeldungen anzuzeigen, daher ist das eher eine Geschichte aus einer anderen Welt, wenn man nicht den eigenen Dienst betreibt, sondern als Lieferant auftritt..

 
thxgeeknews 2024-05-29

Bei der Integration mit einer Drittanbieter-API während der Arbeit habe ich die Basis-URL der API versehentlich statt mit http:// mit https:// eingegeben.
Es sieht so aus, als wären http <-> https vertauscht worden.

 
xguru 2024-05-29

Ups, die KI hat so einen Fehler gemacht, haha. Ich habe es korrigiert.

 
GN⁺ 2024-05-29
Hacker-News-Kommentar
  • Die OpenAI-API wurde aktualisiert, sodass sie auf HTTP-Anfragen mit einem 403-Fehler antwortet.
  • Bei der Stack-Exchange-API ist der Ansatz gut, API-Schlüssel, die über HTTP gesendet wurden, zu widerrufen und eine Fehlermeldung zurückzugeben.
  • Man sollte darauf achten, nicht automatisch eine Weiterleitung von HTTP auf HTTPS zu konfigurieren.
  • Dass cURL standardmäßig nicht automatisch weiterleitet, ist beabsichtigt und ein guter Standardwert.
  • Es ist wichtig, HTTP-Zugriffe zu blockieren und nur HTTPS bereitzustellen.
  • Erstaunlich ist, dass „Provider B“ geantwortet hat, ein MITM-Angriff liege außerhalb des Programmumfangs.
  • Es gibt die Frage, ob HTTP-Sniffing eine Art von MITM-Angriff ist.
  • Hoffentlich können HTTPS und SVCB-DNS-Records mit der Zeit die traditionelle HTTP-Server-Weiterleitung ersetzen.
  • API-Anbieter sollten historische HTTP-Zugriffslogs prüfen und kontrollieren, wie weit die Nutzung von unverschlüsseltem HTTP verbreitet ist.
  • Viele APIs werden hinter Web Application Firewalls gehostet, bei denen die automatische HTTPS-Weiterleitung als Standardregel gesetzt ist.
  • APIs sollten nicht automatisch von HTTP auf HTTPS weiterleiten, und auch Client-Bibliotheken sollten Weiterleitungen standardmäßig nicht folgen.
  • Das Einrichten einer Weiterleitung von HTTP auf HTTPS hilft langfristig dabei, den Traffic zu reduzieren.
  • In der Infrastruktur werden Weiterleitungen oft eingerichtet, um Probleme durch URL-Tippfehler schnell zu beheben.