Warum nicht eval() JSON?

Soweit ich weiß, ist es aus Sicherheitsgründen JSON-Objekte in JavaScript eval() schlechte Praxis. Ich kann diese Bedenken verstehen, wenn der JSON von einem anderen Server kommt.Warum nicht eval() JSON?

Aber wenn die JSON wird von meinem eigenen Server zur Verfügung gestellt und wird json_encode die erstellt mit PHP (lassen Sie uns annehmen, dass es nicht Buggy ist), ist es legitim, einfach eval() zu verwenden, um die JSON in JS oder gibt es irgendwelche Sicherheitsproblem ich zu lesen kann derzeit nicht denken?

Ich möchte wirklich nicht mit dem dynamischen Laden eines JSON-Parsers beschäftigen und wäre froh, einfach eval() zu verwenden.

PS: Ich werde natürlich das native Objekt JSON verwenden, wenn es verfügbar ist, aber auf eval() für IE/Opera zurückgreifen möchten.

Quelle

2010-11-24 NikiC

JavaScript's 'eval' bewertet * jeden * JavaScript-Code und nicht nur die kleine Teilmenge, die gleich JSON ist. – Gumbo

Natürlich ist es gut, Ihre Daten zu verschlüsseln, aber Sie werden nicht für immer die gleiche Codebasis behalten (hoffentlich), schließlich muss jemand anderes sie pflegen, und was ist, wenn es diesen neuen Teil eines Bugfixes gibt, den jemand gesetzt hat es und es ruft nicht die Verschlüsselungsmethode, oder es nennt es aber an der falschen Stelle - und es öffnet sich eine Sicherheitslücke - mit dem zweiten Sicherheitsnetz dort als Fallback könnte der Unterschied zwischen peinlichen PR-Ankündigung (s), teure Rechtsstreitigkeiten und rechtliche Konsequenzen, im Vergleich zu einem einfachen Code-Patch, um das Sicherheitsnetz der mittleren Stufe zu reparieren. – BrainSlugs83

Die andere Sache, die es zu beachten gilt, ist auch die Wartbarkeit - das Einhalten von bekannten Standards wird es einfacher machen, den Besitz des Codes auf einen anderen Entwickler/Team usw. zu übertragen, wenn die Zeit gekommen ist - was ziemlich gut ist, Aber um dies in den Kontext der Sicherheit zu stellen: Entwickler, die wissen, was ihr Code macht und wie er funktioniert (weil er die standardisierten Best Practices für Ihre spezielle Nische verwendet), werden weniger wahrscheinlich Code einfügen, der alles ablenkt und fügt versehentlich neue Sicherheitsfehler hinzu usw. – BrainSlugs83

Es gibt eine Reihe von Möglichkeiten, die Ihre Sicherheit gefährdet sein kann.

Man in der Mitte Angriffe könnten theoretisch den Inhalt der Daten ändern, die an den Client geliefert werden.
Ihr Serverdatenverkehr könnte an anderer Stelle abgefangen werden und andere Inhalte könnten bereitgestellt werden (nicht ganz die gleichen wie bei einem MIM-Angriff)
Ihr Server könnte kompromittiert sein und die Datenquelle könnte manipuliert werden.

und das sind nur die einfachen Beispiele. XSS ist böse.

„Vorbeugen ist ein Pfund Heilung“

Quelle

2010-11-24 19:19:29 zzzzBov

Wenn der Server kompromittiert ist, kann der Angreifer die ursprüngliche Seite ändern. – SLaks

nicht immer. (vier weitere Zeichen) – zzzzBov

@zzzzBov: Könnten Sie bitte ausarbeiten? Wenn jemand die Kontrolle über meine Verbindung übernommen hat, kann er alles manipulieren - und es ist viel effektiver, JS als JSON zu manipulieren. – NikiC

In Ihrem Szenario wird die Frage, woher kommt PHP, um das Javascript auszuführen? Ist dieser Kanal sicher und frei von möglichen Benutzermanipulationen? Was, wenn Sie diesen Kanal nicht direkt kontrollieren?

Quelle

2010-11-24 19:16:11

Ich weiß nicht, was der Benutzer hier manipulieren kann. Ich konstruiere richtig die Ausgabe mit 'json_encode'. Der Benutzer kann somit nur den Inhalt des JSON manipulieren, nicht seine Syntax. So sehe ich keinen Weg, wie er JS beliebig injizieren könnte. – NikiC

@nikic: Denken Sie an Man-in-the-Middle-Angriffe. – Gumbo

@Gumbo: Ein Man-in-the-Middle könnte das JavaScript direkt manipulieren. Warum hackst du den JSON, wenn du den JS hacken kannst? – NikiC

Neben den offensichtlichen Sicherheitsprobleme:

india JSON ist schneller
Sie brauchen nicht zu "load" einen JSON-Parser es ist nur ein Funktionsaufruf an die JavaScript-Engine

Quelle

2010-11-24 19:17:16

Nun, * einige * Leute da draußen wollen immer noch Unterstützung für IE und Opera haben - ich bin einer von ihnen. Wenn das native JSON-Objekt verfügbar ist, werde ich es natürlich aufrufen. – NikiC

Oper? Welche Version von Opera verwendest du? Opera unterstützt JSON seit fast einem Jahr. Außerdem können Sie immer noch auf Crockfords JSON ausweichen, das * validiert, bevor Sie das Zeug an eval übergeben. –

@Ivo: Ich mache genau das. Aber ich will nicht, wenn es nicht notwendig ist;) – NikiC

Tipp: in asp.net mit JSON wird als schlecht angesehen weil das Parsen von DateTime unterscheidet sich zwischen dem Server und dem Client, so dass wir ein specia verwenden Ich funktioniere, um das Datum in Javascript zu deserialisieren. Ich bin mir nicht sicher, ob PHP das gleiche Problem hat, aber es ist erwähnenswert.

Quelle

2010-11-24 19:18:30

Check out this: http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/

so zumindest für Firefox können Sie die integrierten json-Parser verwenden

Quelle

2010-11-24 19:18:56 Daniel

-2

Ernst? Einige der Leute hier sind paranoid. Wenn Sie das JSON ausliefern und wissen, dass es sicher ist, ist es in Ordnung Fallback (*) zu eval(); anstelle einer JS-Bibliothek für IE. Immerhin müssen IE-Benutzer sich viel mehr Sorgen machen.

Und das Man-in-the-Middle-Argument ist bullsh * t.

(*) die Worte Ausweich und sicher sind fett, weil einige Leute hier, sie nicht gesehen haben.

Quelle

2010-12-08 03:51:40

Antwort

Verwandte Themen