AJAX Benutzer authentifizieren

Ich möchte in meinem neuen Projekt AJAX nutzen. Nun habe ich das Problem, dass ich nicht genau weiss, wie ich dn Benutzer authentifizieren soll.
Normalerweise läuft das bei mir über die Session, die auch immer schön brav gegengecheked wird.
Allerdings kann ich (ka, wie PHP sessions intern handelt - ob als Cookie, Servervat etc.) im aufgerufenen Script nicht auf $_SESSION referenzieren.
Nun wollte ich mich mal umhören, was es für probate methoden gibt und den User trotzdem zu authentifizieren.
Spontan fiele mir ein:
ne HEAP-Tabelle in der beim Seitenaufruf nen token geballert wird (vorzugsweise lang und zufällig). Ich hatte mir schon überlegt, wie man sowas sicher machen kann. Man nehme zum Bleistift die Milisekunden der CPU, ne große Zufallszahl, den unix-timestamp, nen paar user-eckdaten etc. pp. mixe ales gut durch und voila..
Auch läuft so ein code nach spätestens x min ab.
Allerdings hatte ich mich gefragt, ob es nicht bessere/schnellere Wege gibt. Denn grade, wenn ich nur nen paar daten abfragen will ist das doof.
Wie sieht es auch weiter mit dem Hijacking aus? Kann z.B. ein anderer User durch irgendwelche JavaScripte oder sonstige Manipulationen sich in den Account eines anderen schleichen? Besonders, wenn man bedenkt, dass ich die Javascripte mit ins Grafikpaket auslagern will..
Andere Sache: Wie sieht das mit Werbung aus? Ich kenne mich in dem Bereich zwar nur wenig aus - aber das erste, was ich bei meinem AD-Blocker immer einstelle ist, dass er Werbe-JS deaktivieren soll. Demnach könnte (sofern ich Werbung einbinde) von dem Werbenden ein JS auf dem Client ausgeführt werden. In wieweit können Dritte nun über "übliche" Werbemethoden (Google Ads, Layer-Ads,...) selbst JS einschleusen und so Ingame-Benutzerdaten ausspähen?
Alternativ: Ist es aufwendig ne HTTPS-Verbindung zum user aufzubauen und diese so sicher zu machen, dass zumindest für die dauer der Session sniffing, man-in-the-middle-attacks und was man sonst noch alles so in (halb-)öffentlichen (W-)LANs machen kann auszuschließen? Gerade, weil viele in der Schule spielen ist doch - WLAN sei dank - mitsniffen nicht mehr so das Problem.. Und da hilft dann auch kein 32-Stelliges Passwort mit sämtlichen Chinesischen Sonderzeichen...

Du kannst trotzdem ganz normal die PHP-Sessions verwenden. Die basieren auf Keksen und können auch bei Ajax eingesetzt werden, da du ja eben nur einen normalen HTTP-Request absetzt.
Sicherheitsmäßig hab ich da keine Bedenken.
XSS über Banner kann man eigentlich auch ausschließen, da das referenzierte JS von einem anderen Server kommt und damit nicht auf die Elemente deiner Seite zugreifen kann (soweit ich weiß, müsste man austesten)

ich habs grad nochmal probiert .. über $_SESSION bekomme ich nur ein "undefined" zurück ...
muss ich bei ajax per hand nen keks senden?
wenns per session ginge wärs ja top .. :/

Also bei uns geht das.
Haste auch ein session_start() gemacht?
Weil $_SESSION ist ja immer da, wenn session_start() gemacht wird, selbst wenn noch keine Session gestartet wurde (also noch nix in die Session reingeschrieben).

Ich werd noch nal nen bissl draan fummeln ..
Vielleicht klappt es nachher

Ich benutze das prototype.js Framework und damit gibt es auch keine Probleme mit $_SESSION, wobei ich eine Datenbankgebundene Session benutze!
Gruß
Moo

steinigt mich .. ich bin doof ..
hab das session_start(); vergessen...
das macht normalerweise meine benutzer-klasse.. die hatte ich aber bei ersten testzwecken nicht eingebunden und daher fehlte sie auch jetzt .. ist ja kein wunder, dass das nicht geklappt hat .. *grml*
und ich zermater mir das hirn, was man statdessen als auth machen könnte .. *grml*
Danke für die Hilfe

Naja, ich habe mir über folgendes bei der Umstellung auf Ajax den Kopf zermattert. Vielleicht hilft dir der Hinweis ja:
-> Nachladen von Javascript funktionierte nur eingeschränkt, d.h. ich musste mein Javascript so umbauen, dass es bei ersten Laden der Seite eingeladen wird
-> Wenn ich eine Seite in einem Div nachlade und dann dort eine Funktion aufrufe, musste ich, wenn die Funktion z.B. ein SetTimeout oder setInterval war, diese zuerst erneut stoppen.
-> Ich wollte die Formularfelder nicht alle von Hand als Parameter angeben, und habe stattdessen: parameters:Form.serialize(this) alle Felder direkt eingeschlossen
Trotzdem kann ich prototype wirklich empfehlen, es enthält viele nützliche Funktionen.
Gruß
Moo

Naja.. $_SESSION hat nur mit JS oder sogar Prototype nicht wirklich etwas zu tun
Der Aufruf ist ein ganz normaler, nur das er nicht über das Benutzerinterface, sondern über das HttpRequest-Model initiiert wird.
Das ist ja auch das große "Geheimnis" an dem ganzen Hype

Mein Post sollte nur mein sonstige Erfahrung wiedergeben und war eigentlich wirklich am Thema vorbei

Was passiert aber, wenn Cookies deaktiviert sind? Ist es trotzdem dann noch möglich, dass die SessionID automatisch an die URL angehängt wird?

du machst dir gedanken das JS eigeschmuggelt werden kann?
de.wikipedia.org/wiki/Greasemonkey
userjs.org/
wer will, der kann. ohne probleme.
was glaubst du, wie bots für browsergames geschrieben werden?

Original von zufall_
was glaubst du, wie bots für browsergames geschrieben werden?

Bots im klassischen Sinne werden sicher nicht über JS oder derjenige sollte sich ernsthaft mal in therapie begeben ob er nicht masochistisch veranlagt ist
und es geht nicht darum ob JS vom user eingeschleust werden kann, denn das kann er immer und überall (und auch manipuliert), sondern ob dies ein verlinkter externer anbieter könnte. Ich weiß zwar noch nicht warum er dies tuen sollte, aber prinzipiell ne interessante frage

ein kleiner bot, der in unregelmässigen abständen aktualisiert (verhindern einer statistischen auswertung) und bei einem angriff savet ist in ca. 15-30min mit JS geschrieben. das hat nichts mit masochismus zu tun.
ich muss dir aber absolut recht geben, einen "professionellen" bot wird man in einer anderen sprache realisieren. eine diskusion über bots wär hier aber offtopic, ich wollte nur daran erinnern, daß immer die möglichkeit besteht, das JS zu manipulieren. dies sollte man beachten, damit es nicht zur gefahr werden kann.

Original von Sarge

Original von zufall_
was glaubst du, wie bots für browsergames geschrieben werden?

Bots im klassischen Sinne werden sicher nicht über JS oder derjenige sollte sich ernsthaft mal in therapie begeben ob er nicht masochistisch veranlagt ist
Hast du ne Ahnung.. sofern ein Bot Sinn macht, kann man wunderschöne Ajax-Bots bauen. Ich will das Thema aber ungern weiter im Detail fortführen, sonst bringt man Leute noch auf schlechte Ideen..

JS untersützt ja auch Regex und kann - wie ich das verstanden habe - mit den gezeigten Tools auf alle Elemente der Seite zugreifen.
Mich würden jetzt aber 2 Fragen interessieren, die mehr mit dem Thema zusammenhängen.
1. Inwiefern kann der User üben die eben besprochene Methode Schaden anrichten? Wenn er irgendwas am Skript manipuliert und ich sowieso alle Usereingaben Serverseitig prüfe sollte doch kein Grund zur Panik existieren.
2. Siehe die oben gestellte Frage.

Die Sache auf die ich mehr hinaus wollte:
In meinem Spiel sind Informationen wichtig. So bekommt man nur ungefähre angaben über Flotten etc.
Auch Fallen, Hinterhalte(?), etc. pp. sind möglich.
Mir gehts es nciht um die Bots. Die kann man eh nicth aufhalten.
Bots entstehen nur da, wo aktionen wiedholt ausgeführt werden müssen (bau, raid, handel, ..) - bei mir sind die schon im spiel integriert (oder werden noch programmiert)...
Mir geht es darum: Kann jemand drittes per "Werbung" (iframe, layer, bannertausch, weissdergeier) JS von einem dritten Server laden und ausführen um somit von ahnungslosen Spielern Daten auslesen (cookies, accdaten, ...) oder sogar verändern, dass man (nachdem man sich eingeschleust hat und die session gehijackt hat) z.B. ausbauten des Feindes stoppt, seine Flotten ins nirgendwo schickt (geht ja per ajax) etc.
und das alles nur, weil irgendwo irgendwelche Werbung komprommitiert wurde und böses(tm) Javascript eingeschleust hat? Oder weil der User es gewagt hat Werbung anzusehen, die von seinem AdBlocker nicht geblockt wurde?
DAS ist das, was mir sorgen macht.

Also vorneweg: Der HttpRequest (das, was du jetzt Ajax nennst) ist auf den eigenen Domainbereich limitiert, d.h.: Wenn ein JS auf galaxy-news.de liegt, kann ein HttpRequest auch _nur_ auf diese Domain zugreifen. Damit ist ausgeschlossen, dass fremde Scripte andere Seiten nachladen. Ich würde, sofern du das wirklich groß aufziehen willst, eh OOP arbeiten, insofern was Javascript angeht, deine Datein schon mal zentral liegen. Dann müsste schon jemand die gleichen Namen verwenden, um überhaupt in die Nähe deiner Daten reinzukommen; einmal abgesehen, das ich nicht weiß, ob ein eingeladenes JS von Server A mit einem von Server B im gleichen Bereich liegt.. noch nicht getestet.
Ist dies der Fall, wäre man so oder so aber nicht sicher.. nicht zuletzt mit Greasemonky kann man eigene JS einladen.

ich glaube dass Drezil auf was anderes hinaus will:
Bei Werbung includet man meist ein fremdes JS per . Dieses wird vom Browser genauso behandelt wie wenn man ein eigenes script includet. Also kann das fremde Script auf dein eigenes Script sammt Variablen und Funktionen zugreifen, Cookies auslesen, zuweilen an GET/POST-Daten rankommen etc. etc.
Ich fürchte da kann man kaum was anderes machen als hoffen, dass der Werbeanbieter keinen Scheis baut... Gegen das simple Session-Hijacking hilft noch eine IP-Sperre, aber sonst hat man kaum ne Chance das abzuschotten. DU kannst höchstens ein Script bauen, das alle 30 Minuten das Script vom Werbeserver holt und es testet ob da Veränderungen drin sind.

Ich würde bei jedem Login die aktuelle IP-Adresse in der Session speichern und dann bei jeden folgenden Seitenaufruf schauen, ob die IP immer noch die gleiche ist. Wenn nicht, Session killen und neuen Login fordern.
Damit kann man zumindest die Session nicht so einfach übernehmen, man muss schon vom aktuellen PC des Users zugreifen...
Und ob ein Werbeanbieter sich überhaupt die Mühe macht, deinen Code zu durchschauen und ein Hijacking zu versuchen, ist eh fraglich...

Störti, Drezil hat Angst davor, dass der Werbeserver gehackt und dann Murks gemacht wird, um sich im Spiel Vorteile zu verschaffen.

Original von Kampfhoernchen
Sicherheitsmäßig hab ich da keine Bedenken.
XSS über Banner kann man eigentlich auch ausschließen, da das referenzierte JS von einem anderen Server kommt und damit nicht auf die Elemente deiner Seite zugreifen kann (soweit ich weiß, müsste man austesten)

Interessiert die Browser, die ich kenne nicht. Lediglich, von wo das HTML-Dokument geladen wurde ist da interessant. Die Script-Quellen können von was weiß ich wo kommen.

Original von mifritscher
Störti, Drezil hat Angst davor, dass der Werbeserver gehackt und dann Murks gemacht wird, um sich im Spiel Vorteile zu verschaffen.

Konnte man das nicht schon vorher?
Ich glaube ihr denkt, dass xhr soviel was anderes ist. Das ganze Phishing-Zeugs konnte man vor diesem Hype genauso fabrizieren. "man in the middle" ging vorher auch, als man die Daten noch per Formular abschickte (xhr kann auch mittels POST senden, wenn man es will )
Man sollte sicherlich jeden scheiss, der vom Clienten kommt nachchecken, ausser halt Username und PW. Das kann man meistens schlecht checken, da man vorm Login nichts nachzuweisen hat. Ich denke deswegen wird sich in der Sicherheit nicht wirklich viel ändern zu den alten Techniken. Das man natürlich trotzdem zb. den Weg der Einheit vom Server nachchecken lassen muss, sollte ja jedem klar sein.
PS.: Wer bitte schön hackt sich in nen Werbe-Server, um sich Vorteile bei einem Browsergame zu verschaffen? ^^

KoMtuR, leider gibt es solche kranken Leute, und teilweise wird es ihnen nur allzuleicht gemacht :-(
Jo, ich verstehe den ganzen AJAX-hype auch nicht, ich wette dass ähnliche Sachen schon vor einigen Jahren verwendet wurden...
Sicherheitstechnisch gesehen wird nur es nur unsicherer da die AJAX-Techniken JS benötigen, ohne dies die meisten XSS-Attacken nicht gehen. Aber wer hat heutzutage noch JS deaktiviert...

Nur nebenbei: Mit JS kann der Endbenutzer ziemlich viel rumpfuschen, so kann er z.B. die Werbebanner ganz gezielt blocken oder die hauseigenen Sktipe verfälschen.

Original von mifritscher
KoMtuR, leider gibt es solche kranken Leute, und teilweise wird es ihnen nur allzuleicht gemacht :-(
Jo, ich verstehe den ganzen AJAX-hype auch nicht, ich wette dass ähnliche Sachen schon vor einigen Jahren verwendet wurden...
Sicherheitstechnisch gesehen wird nur es nur unsicherer da die AJAX-Techniken JS benötigen, ohne dies die meisten XSS-Attacken nicht gehen. Aber wer hat heutzutage noch JS deaktiviert...

Der "AJAX-Hype" geht ja auch schon ein paar Jahre. Lediglich das Buzzword ist mehr oder weniger neu. Um ehrlich zu sein, erkenne ich aber keinen Hype. Sich neuer oder anderer Techniken zu bedienen ist nichts verwerfliches. Im Gegenteil.
Desweiteren: JavaScript per default zu deaktivieren mag zwar immer noch gang und gebe zu sein, halte ich allerdings für Schade. Grade auf dem Browsergamesektor halte ich JavaScript für ein mächtiges Werkzeug (die Browserinkompatibilitäten mal außen vor gelassen).
Durch intelligente Browser und PlugIns sollten JavaScript Neckereien auch grötenteils unterbunden werden. Und XSS Attacken darf man in keinem Fall JavaScript in die Schuhe schieben. Eher schlampig programmierten Seiten und ihren Entwicklern.
Allerdings, in einen Webserver über JS-XSS einzubrechen, ist eher schwierig bis unmöglich.

nu will ich mich auch mal wieder äussern..

Original von KoMtuR

"man in the middle" ging vorher auch, als man die Daten noch per Formular abschickte (xhr kann auch mittels POST senden, wenn man es will )
jo .. mit man in the middle kommste auch an bankdaten etc.. dagegen gibt es (zumindest solange wir keine quantencomputer haben, die die infos nach dem lesen zerstören) nichts, was man machen könnte..

Man sollte sicherlich jeden scheiss, der vom Clienten kommt nachchecken, ausser halt Username und PW. Das kann man meistens schlecht checken, da man vorm Login nichts nachzuweisen hat. Ich denke deswegen wird sich in der Sicherheit nicht wirklich viel ändern zu den alten Techniken. Das man natürlich trotzdem zb. den Weg der Einheit vom Server nachchecken lassen muss, sollte ja jedem klar sein.
ACK. mache ich auch.

PS.: Wer bitte schön hackt sich in nen Werbe-Server, um sich Vorteile bei einem Browsergame zu verschaffen? ^^
1. server direkt hacken hab ich schon öfters erlebt.
2. den werbe server brauch man nicht hacken ... man trägt sich eben in den werbe-dings ein (bannertausch, google,...) und wenn man dann das js eingeschleust hat is zu spät.
was meine ursprüngliche intention war:
ich hatte mich gefragt, ob jemand drittes (wie?) ein js einschleusen kann, welches dann ausgeführt wird und z.b. den link "gebäude ausbauen" per dom-manipulation in ein "gebäude abreissen" oder "account löschen" ändert.
der USER wird hiervon nichts merken .. (wie einfach solche änderungen sind, weiss jeder, der sich mal etwas mit dom beschäftigt hat).
es muss nichtmal nen einbguch "in" den server sein. es reicht ja vollkommen, wenn solche sachen, wie oben angesprochen möglich wären.