it-swarm.com.de

Codierung der Ausgabe in der JSON-HTTP-API

Ich bin der Autor einer JSON REST API. Diese REST API wird von verschiedenen Clients verwendet, z. B. HTML/JS-Clients, .NET-Clients () Konsolenanwendungen) und Ruby Clients. Die Ausgabe der API erfolgt im JSON-Format, daher wird sie gemäß den JSON-Regeln formatiert und die erforderlichen Sonderzeichen werden maskiert.

Ein Sicherheitsforscher hat mir gemeldet, dass < Und > In der Ausgabe nicht maskiert sind. Wenn also ein Angreifer eine Anforderung wie HTTP POST https: //my.api.example.com/blabla mit dem JSON-Body {Value:"<Hello>"} gibt meine API so etwas wie {Response:"<Hello> is not a valid value"} aus.

Der Sicherheitsforscher erklärte dann, dass ein Angreifer möglicherweise in der Lage ist, mithilfe dieser Funktion ein Reflected Cross-Site-Scripting durchzuführen.

Meine JSON-API gibt immer einen Content-Type: application/json - Header zurück, daher verstehe ich, dass moderne Clients nicht versuchen werden, ihn als HTML zu interpretieren.

< Und > Sind gültige Zeichen in meiner API, sodass ich sie nicht herausfiltern kann. Eine Möglichkeit wäre, die Zeichen in der Ausgabe zu codieren, aber HTML-codierende Zeichen in einer JSON-API scheinen mir etwas seltsam. Eine dritte Option wäre, einfach die Zeichenfolge aus der Ausgabe zu entfernen und stattdessen etwas wie "Der angegebene Wert war ungültig" zu sagen, aber dies würde die Benutzerfreundlichkeit ein wenig verringern.

Gibt es bewährte Methoden, um damit umzugehen?

6
Nitradamus

Können Sie sich auf den Content-Type-Header verlassen? Nein

Wie in der Antwort auf diese Frage zu security.stackexchange.com genau gesagt, können wir uns nicht darauf verlassen, dass Clients die Header von Inhaltstypen in Bezug auf Sicherheit respektieren.

Wie codiere ich JSON?

OWASP gibt Ratschläge für genau Ihre Situation Sie sagen, wenn der Kontext HTML ist, dann codieren Sie Ihre Ausgabe für diesen Kontext. Sie sagen auch:

Eine Alternative zum Escape- und Deescaping von JSON direkt in JavaScript besteht darin, JSON serverseitig zu normalisieren, indem '<' in '\ u003c' konvertiert wird, bevor es an den Browser übermittelt wird.

2
mcgyver5

Bis zu einem gewissen Grad ist dies Ansichtssache, aber ich stimme nicht zu, dass hier eine Sicherheitslücke besteht. Wenn ein Client HTML-Daten aus Ihrer JSON-Antwort ohne Bereinigung widerspiegelt, handelt es sich um eine Sicherheitsanfälligkeit in diesem Client und nicht in Ihrer API. Jede Webseite sollte API-Antworten als nicht vertrauenswürdige Daten behandeln.

Sie haben Recht, dass HTML-Codierung der Antwort eine schlechte Idee ist. Warum sollte die API Annahmen darüber treffen, was eine ordnungsgemäße Codierung für den Client ist? Was ist, wenn Sie die API auch für eine mobile App verwenden möchten, bei der die Daten in einem Nicht-HTML-Kontext angezeigt werden? HTML-Codierung wäre nur schlechtes Design. Es würde ein Problem für den Client auf der Serverseite lösen.

Stattdessen würde ich klar dokumentieren, dass die Ausgabe HTML-Sonderzeichen enthalten kann und dass der Client geeignete Maßnahmen ergreifen sollte.

Eines jedoch: Stellen Sie sicher, dass Sie mit einem No-Sniff-Header antworten. Ohne sie könnten Mime-Sniffing-Browser die Antwort als HTML oder JS interpretieren, was eine echte Sicherheitslücke darstellen würde.

2
Anders

Erstens sind die Überschriften nichts, worauf man sich strikt verlassen kann. Auch wenn diese potenzielle XSS-Sicherheitsanfälligkeit derzeit möglicherweise kein Problem darstellt, können Sie nicht genau wissen, wie Ihre API in Zukunft verwendet wird. Irgendwo auf der Straße könnte jemand beantwortete Werte in HTML verwenden, wodurch die Möglichkeit eines XSS eröffnet wird.

Dies ist möglicherweise nicht Ihr Problem an sich. Sie sollten Ihre Eingabe dennoch validieren und Ihre Ausgabe bereinigen.

  • Was genau sind die Szenarien, wenn <> wären gültige Zeichen in Ihrer Eingabe? `
  • Würde es weh tun, <> wann immer es eine Eingabe gibt, die nicht mit den zuvor definierten Szenarien übereinstimmt?
  • Würde es weh tun, Ihre dritte Option zu verwenden? Dies ist wahrscheinlich am einfachsten zu implementieren.

Wie bei allem hat OWASP eine großartige Anleitung ("Spickzettel" genannt) für Webentwickler, wie man XSS verhindert ( insbesondere in JSON ). Ihr json-sanitizerProjekt auf GitHub könnte auch einen Besuch wert sein.

0