Browser und Web­an­wen­dun­gen verfügen über zahl­rei­che Features und Konzepte, um Nutzer und ihre Daten vor Cy­ber­at­ta­cken zu schützen. Eines davon ist die so­ge­nann­te Same-Origin-Policy (dt. Gleiche-Herkunft-Richt­li­nie), kurz SOP, die der ehemalige Browser-Konzern Netscape im Jahr 1996 mit der Im­ple­men­tie­rung von Ja­va­Script einführte. Diese Richt­li­nie verbietet es cli­ent­sei­ti­gen Skript­spra­chen wie Ja­va­Script und Ac­tion­S­cript, aber auch Style­sheet-Sprachen wie CSS, auf Objekte (Grafiken, Videos etc.) zu­zu­grei­fen, die von einer anderen Website bzw. URL stammen.

Hinweis

Der Origin wird als Kom­bi­na­ti­on aus Protokoll (z. B. HTTP oder HTTPS), Domain und Port in der URL definiert. Nur wenn alle drei Elemente identisch sind, gilt die SOP als erfüllt, sodass der site­über­grei­fen­de Skript-Zugriff möglich ist. Eine Ausnahme bilden dabei Sub­do­mains, die über ent­spre­chen­de DOM-Ei­gen­schaf­ten auf Objekte über­ge­ord­ne­ter Domains zugreifen können.

Die von der Same-Origin-Policy gesetzten Grenzen sind al­ler­dings nicht für jede Art von Web­pro­jekt von Vorteil bzw. in be­stimm­ten Fällen sogar hin­der­lich – etwa bei Web­an­wen­dun­gen, die auf eine asyn­chro­ne Da­ten­über­tra­gung zwischen Browser und Server (bei­spiels­wei­se auf Ajax-Basis) setzen. Bei solchen Projekten sind Lösungen zum Umgehen der Richt­li­nie wie die JSON-Methode JSONP gefragt. Eben diese soll in den folgenden Ab­schnit­ten näher erläutert werden.

Was ist JSONP?

JSONP (auch JSON-P ge­schrie­ben) ist eine Methode, mit deren Hilfe sich struk­tu­rier­te Daten im JSON-Format zwischen ver­schie­de­nen Domains ver­schi­cken lassen. Das Akronym steht dabei für JSON (JavaScript Object Notation) with Padding (dt. JSON mit „Pols­te­rung“). Um die Same-Origin-Policy bei der An­for­de­rung von Dateien anderer Domains zu umgehen, nutzt JSONP nicht wie ge­wöhn­li­cher JSON-Code das Objekt „XMLHtt­pRe­quest“, sondern das Element „script“ inklusive eines Funk­ti­ons­auf­rufs. Anders als andere Dateien lassen sich Skripte nämlich auch do­main­über­grei­fend über­tra­gen, ohne dass die SOP verletzt wird.

JSONP wurde 2005 von dem Software-Ent­wick­ler Bob Ippolito erdacht und in den ver­gan­ge­nen Jahren in viele Web-2.0-Frame­works wie Dojo Toolkit, jQuery oder Google Web Toolkit als wählbare Al­ter­na­ti­ve zu ge­wöhn­li­chem JSON in­te­griert.

Hinweis

JSONP ist nur eine Methode von vielen, um do­main­über­grei­fen­de Da­ten­über­tra­gun­gen zu er­mög­li­chen. Mit Cross-Origin Resource Sharing (CORS) existiert ein ver­gleich­ba­rer Me­cha­nis­mus, der nicht an JSON gebunden ist, sondern statt­des­sen mit spe­zi­el­len HTTP-Headern arbeitet.

Wie funk­tio­niert JSONP?

JSONP löst die Same-Origin-Policy-Pro­ble­ma­tik mithilfe des script-Elements. Im „src“-Attribut dieses Elements lassen sich nämlich beliebige Domains angeben, und außerdem greift hier die Richt­li­nie nicht. Durch das Attribut lassen sich also auch URLs aus­zeich­nen, die zu einer fremden Domain gehören, und JSON-Code sowie andere Dateien zu­rück­ge­ben. Das Skript selbst dient in solch einem Fall aus­schließ­lich als Dienst­leis­ter, der die JSONP-Abfrage an den je­wei­li­gen Webserver über­mit­telt, ohne dass es einen eigenen Effekt hat. Damit der Client die Daten später ver­ar­bei­ten kann, verpackt der Server diese wiederum als Parameter in eine Ja­va­Script-Funktion, die im Web­brow­ser bereits vor­de­fi­niert ist und dem Server im Query-String (auch Ab­fra­ge­teil) der URL mit­ge­teilt wird.

Hinweis

Das Format und der Name der Parameter, die im Query-String anzugeben sind, um eine JSONP-Abfrage zu in­iti­ie­ren, sind nicht genormt. Daher können sie sich von Web­an­wen­dung zu Web­an­wen­dung un­ter­schei­den.

Folgendes Beispiel soll die Funk­ti­ons­wei­se von JSONP ver­deut­li­chen:

<script  type="text/javascript"
    src="http://not-origin-url.com/getjson?jsonp=exampleCallback">
</script>

Wird dieses einfache JSONP-Skript in den HTML-Code einer Website ein­ge­bun­den und dann von einem be­lie­bi­gen Client aus­ge­führt, werden von der fremden Domainnot-origin-url.comJSON-Daten abgerufen („getjson“). Der Query-String?jsonp=ex­am­ple­Call­back“ verrät dem kon­tak­tier­ten Server, dass es sich um eine JSONP-Abfrage handelt. Zudem wird die In­for­ma­ti­on geliefert, dass er die an­ge­for­der­ten Daten als Parameter der Ja­va­Script-Funktionex­am­ple­Call­back“ senden soll.

Der Server generiert daraufhin den ent­spre­chen­den Ja­va­Script-Code inklusive der ab­ge­frag­ten In­for­ma­tio­nen als Parameter – im Falle dieses Beispiels ein Name-Wert-Paar – und gibt diesen an den Client zurück:

exampleCallback( {"name":"test", "value":1} );

Der Funk­ti­ons­auf­ruf wird daraufhin vom Browser aus­ge­führt, als ob er direkt im HTML-Code der Ur­sprungs­sei­te ver­zeich­net wäre. Dem Browser ist es dadurch möglich, die von der Fremd-URL ab­ge­ru­fe­nen Daten zu ver­ar­bei­ten.

Hinweis

Für jede JSONP-Abfrage ist ein einzelnes script-Element er­for­der­lich. Wahlweise lässt sich hierfür auf Client-Seite ein neues Element hin­zu­fü­gen (wird als Script-Element-Injection be­zeich­net) oder ein bereits exis­tie­ren­des Element wie­der­ver­wen­den.

Eine etwas um­fang­rei­che­re De­mons­tra­ti­on der JSONP-Methode liefert folgendes YouTube-Tutorial:

Wie sicher ist JSONP?

JSONP ist in Fach­krei­sen als Lösung zum Umgehen der SOP durchaus um­strit­ten, was vor allem auf das erhöhte Si­cher­heits­ri­si­ko zu­rück­zu­füh­ren ist, das mit den Skript-Abfragen verbunden ist. Hierfür sorgt schon allein die Tatsache, dass eine zu­sätz­li­che Kom­po­nen­te in die Prozesse der Herkunfts-Website ein­ge­bun­den wird, deren Si­cher­heits­sys­tem nicht be­ein­fluss­bar ist. Weist nämlich der kon­tak­tier­te Server Schwach­stel­len auf, die un­er­wünsch­te Ja­va­Script-In­jec­tions (Ein­bin­dung von Ja­va­Script-Code) durch Angreifer möglich machen, ist au­to­ma­tisch auch der Her­kunfts­ser­ver einer un­mit­tel­ba­ren Gefahr aus­ge­setzt – ins­be­son­de­re, da nicht nur JSON-Dokumente (wie im Beispiel), sondern jegliche Art von Daten abgerufen werden können.

Weitere bekannte An­griffs­mus­ter, die sich die JSONP-Methode zunutze machen, sind folgende:

  • RFD (Reflected File Download): JSONP ist anfällig für so­ge­nann­te RFD-Angriffe, bei denen Client-Nutzer nur scheinbar Daten von der ge­wünsch­ten Ziel-Domain her­un­ter­la­den. Tat­säch­lich werden al­ler­dings schäd­li­che Dateien oder URLs geladen, was in den meisten Fällen auf eine Ma­ni­pu­la­ti­on von Callback-Funk­tio­nen zu­rück­zu­füh­ren ist.
  • CSRF/XSRF (Cross-Site-Request-Forgery): Da das script-Element die Same-Origin-Policy ignoriert, kann eine schäd­li­che Website Daten anderer Web­an­wen­dun­gen anfordern, erhalten und auswerten. Ist der Nutzer auf der an­ge­grif­fe­nen Seite an­ge­mel­det, könnten Angreifer mit solchen „ge­fälsch­ten“ do­main­über­grei­fen­den Requests an sensible Daten wie Log-in-In­for­ma­tio­nen gelangen.

Wer JSONP-Skripte im eigenen Web­pro­jekt verwenden möchte, der sollte also absolut sicher sein, dass nicht nur der eigene, sondern auch der Webserver der kon­tak­tier­ten Web­an­wen­dung gegen derartige Angriffe und jegliche Art von Malware geschützt ist. JSONP-Code, der Daten von un­si­che­ren Quellen abruft, sollte man dem­entspre­chend nicht einbinden bzw. nicht zulassen.

Zum Hauptmenü