webthreads.de - Web 2.0, Web-Entwicklung und Netzkultur von Markus Kühle

Zugriff auf Ajax Services sichern

Greg Murray beschreibt auf seinem Blog fünf Möglichkeiten wie man den Zugriff auf Ajax Services, die man selbst nutzt oder anderen anbietet, sichern sollte. Die grundsätzliche Idee hinter dem Vorhaben ist relativ einfach. Man möchte verhindern, dass jemand den Ajax Service, den man auf der eigene Seite anbietet oder für die eigene Seite nutzt, für nicht vorhergesehene Zwecke ausnutzt. Aus diesem Grund sollte man den Zugang zu dieser Ajax Schnittstelle limitieren, aufzeichnen oder verfolgen können.

Hier im kurzen die vorhandenen Möglichkeiten:

  • Token basierte Beschränkung
    Gerade wenn man das Proxy Pattern verwendet um auf entfernte Services zuzugreifen sollte man nur den Zugriff auf bestimmte Services zulassen. Jeder definierte Dienst in dem Proxy sollte einen bestimmten Token als Erkennung haben, der bei einer Anfrage mitgeliefert wird. Ist der übertragene Token nicht vorhanden oder nicht definiert wird die Anfrage ignoriert. So kann der Proxy nicht ausgenutzt werden um auf entfernte Dienste zuzugreifen die nicht für den Service vorgesehen waren.
  • Anwendung Schlüssel basierte Beschränkung
    Als Beispiel werden hier die angebotenen Services von Yahoo! erwähnt. Yahoo! erlaubt nur einen Zugriff wenn man sich vorher registriert hat und den erworbenen Schlüssel bei einer Anfrage immer mitliefert. Mit einem Schlüssel können die Anfragen verfolgt und eine Zweckentfremdung der Services aufgedeckt werden.
  • URL basierte Beschränkung
    Die URL basierte Beschränkung wird bei Google Maps angewand. Es ist nur nach einer Registrierung mit einer URL, auf der dieser Service genutzt werden möchte, möglich Google Maps in seine Seite unter dieser URL einzubinden. Wird eine andere URL benutzt ist der erworbene Schlüssel nicht brauchbar und eine Fehlermeldung erscheint.
  • Session basierte Beschränkung
    Diese Beschränkung bezieht sich auf das korrekte Erstellen einer HTTP Session. Bei manchen Zugrifsstechniken auf einen Ajax Service und wenn die Anfrage von einer anderen Domain kommt wird keine HTTP Session erzeugt. Wenn keine Session vorhanden ist wird die Anfrage zurückgewiesen. So kann man verhindern, dass Applikationen auf anderen Domains den eigenen Ajax Service nutzen.
  • Content-Type Beschränkung
    Eine Möglichkeit eine falsche Anwendung zu Unterbinden ist, nur einen bestimmten zurückgelieferten Content-Type anzubieten. Es ist möglich zum Beispiel nur XML als Daten zurück zu geben anstatt JSON Objekte. So muss direkt dieser Content-Type angefordert werden ansonsten erhählt man kein Ergebnis.
  • Authentifizierung basierte Beschränkung
    Die letzte Möglichkeit ist die aus herkömmlichen Webanwendungen bekannteste. Ein User muss sich bei einer Frage erst authentifizieren befor die Anfrage ausgeführt wird.

Die aufgezählten Möglichkeiten zeigen kurz auf, wie man seine Ajax Services einfach schützen kann. Sobald man Services anbietet ist man auch vor einer Zweckentfremdeten Nutzung seines Services nicht geschützt. Daher sollte man sich vorher Gedanken machen wie und wo man eines der oben beschriebenen Verfahren gut einsetzen könnte.

Ähnliche Artikel, die dich interessieren könnten:

    None Found

6 Kommentare zu 'Zugriff auf Ajax Services sichern' »»


Kommentare

  1. Kommentar by Christoph | 07.08.2006 at 23:15:31

    “fünf Möglichkeiten” – ich zähle bei dir aber sechs :p Aber besser mehr als zu wenig ;) Ich würde (BTW) Methode Nummer zwei vorziehen, die scheint mir am meisten Kontrolle über das Geschehen zu geben. Methode Nummer 5 (mit dem Content-Type) halte ich für absolut unsinnig, da es einem Fremd-Zugreifer ohne weiteres gelingen sollte, die original-Anforderung zu sniffen und sich daran anzupassen. Ohne habe ich da was falsch verstanden?

  2. Kommentar by Christoph | 08.08.2006 at 12:00:54

    Nanu? ich dachte eigetlich, ich hätte hier gestern einen Kommentar hinterlassen?

  3. Kommentar by Markus | 08.08.2006 at 13:36:52

    Der Kommentar war da aber wurde als Spam erkannt – ‘tschuldigung. Aber jetzt isser da der Kommentar.

    Ich denke, dass einige Methoden für die Beschränkung gut funktionieren. Hauptsächlich geht es darum solche “offenen” Services, die evtl. sogar nur für die eigene Seite genutzt werden sollen vor Missbrauch zu schützen. Da ist es generell einfach mal interessant welche Möglichkeiten bestehen.
    Die erste Methodik z.b. dient sehr gut für das Proxy Pattern bei dem man dennoch die angebotenen Seiten auf die man durch den Proxy zugreifen möchte definiert. Das Proxy Pattern allein würde sonst einfach nur eine offene Tür für jeden sein.
    Oder die Authentifzierung – man muss sich registrieren. Das lohnt sich nur wenn man einen öffentlichen Service anbietet und sich die Leute auch für den Service registrieren würden.

    Das mit der Content-Type Beschränkung bezieht sich auf bestimmte Content-Typen mit denen ein Missbrauch vorgekommen ist oder ein bestimmter Content-Type einfach falsch angewendet wird. Greg Murray beschreibt für diesen Fall die JSONP Variante die bei einem Ajax Service von Yahoo! die falsch angewendet wurde. Yahoo! hat sich dann entschieden als Content-Type nur noch XML anzubieten. In dieser Form ist diese Variante der Beschränkung des Content-Types auch eine Möglichkeit eine falsche Anwendung oder einen Missbrauch zu unterbinden.
    Habe diese Variante wohl ein wenig zu knapp wiedergegeben.

  4. Kommentar by Christoph | 08.08.2006 at 13:54:44

    Ich bin ganz stolz, dass mein Blog nicht zugespamt wird, obwohl kein Schutzmechanismus eingebaut ist ;)

  5. Kommentar by Markus | 08.08.2006 at 14:20:16

    Ich hatte am Anfang auch keinen Spam Schutz bis dann der erste Spam aufgetreten ist.. mittlerweile erhalte ich regelmäßig Spam. Von daher freu dich nicht zu früh ;)

  6. Kommentar by Christoph | 08.08.2006 at 19:16:00

    Ach, so lange meine Besucherzahlen weiter auf dem Sinkflug sind und die 100er Marke kaum noch übertreten (2 std. Reloadsperre), mach ich mir da keine Sorgen. Und wenn, dann kommentier ich das Captcha wieder ein ;)


Hinterlasse ein Kommentar »»

Bad Behavior has blocked 3873 access attempts in the last 7 days.