Sollte ich meinen Json vom Backend zu AngularJs kodieren?

Question

Ich habe ein .NET-Backend mit einem AngularJS-Frontend. alles funktioniert (kein JavaScript ausgeführt wird), wenn ein Benutzer seinen Namen eingibt als

<script>alert('xss');</script> 

Die Daten gesendet wird, als Json zu meinem Backend nicht codiert, ich den Text speichern als in der Datenbank eingegeben, und den Text senden , wie Json, beim Lesen der Daten zurück zum Frontend.

Das alles funktioniert wie gesagt, aber einen Sicherheitskurs zu beobachten rieten sie, den Json zu kodieren.

In meinem Fall sollte ich besser meinen Json codieren?

Dies ist ein Teil der Json beim Speichern und Laden:

,"aanvragernaam":"<script>alert('xss');</script>"," 

Answer 1

Solange Sie den Inhaltstyp auf application/json dann this content type will not be sniffed by browsers setzen, weil es nicht "bekannt" ist. Daher sollte dies sicher gegen XSS sein.

Es ist nicht notwendig, es weiter zu kodieren.

JSON Hijacking ist eine weitere Schwachstelle mit GET-Anfragen, aber es ist not an issue in modern browsers.

Das einzige andere Risiko, das ich sehe, ist DOM XSS. Solange Sie nicht den Wert "wie er ist" in das DOM schreiben, gibt es kein XSS-Risiko. Wenn dies der Fall ist, sollten Sie HTML-Code codieren oder JQuery oder JavaScript verwenden, um text/textContent nach Bedarf richtig zu setzen, damit der Browser es nicht als Skript interpretiert.

Beachten Sie, dass das Risiko hier nicht <script>alert('xss')</script> ist, es müsste etwas wie sein, damit es ausgeführt wird, wenn es dynamisch zu einem Dokument hinzugefügt wird.

Answer 2

Ich denke, man sollte encodeURI (Name), bevor Sie eine Anfrage senden Ende zu sichern, den Namen Datenbank zu speichern.

Und Sie werden die decodeURI-Funktion verwenden, wenn Sie Daten vom Back-End erhalten.

Answer 3

Wahrscheinlich möchten Sie die Eingabeüberprüfung durchführen und Klammern ablehnen, da die Namen diese selten enthalten. Dies ist jedoch keine ausreichende Sicherheitskontrolle, als wenn wir andere Arten von Daten (z. B. Kommentare) unterstützen möchten, müssen wir diese Zeichen möglicherweise unterstützen und unsere Kontrolle funktioniert nicht.

Das Risiko, HTML (Script-Tags usw.) in JSON zu haben, liegt vor, wenn der Angreifer einen Benutzer irgendwie dazu bringen kann, ihn zu laden und als HTML im Browser anzuzeigen. Das war früher ziemlich einfach in < IE9, da diese Browser nicht wussten, was die Content-Type-Anwendung/json war. Daher würde der Browser versuchen, den Inhalt zu erraten (zu schnüffeln). Diese Art von Sniffing kann jedoch mit dem Header X-Content-Type-Options: nosniff deaktiviert werden.

können Sie den Schutz weiter stärken

Content-Disposition: attachment;filename=data.json 
X-Download-Options: NoOpen 

durch Hinzufügen Wenn ein Benutzer die JSON direkt in einem Browser-Fenster zu öffnen versucht, wird die Datei zu werden angezeigt anstatt heruntergeladen werden.

IMHO keine Codierung im JSON notwendig.