nicht angemeldet
Ajax Sicherheit
Moin,
da gibts so eine Seite, da kann man einen neuen Beitrag schreiben. Es gibt ein Feld da kann man aus diversen Kategorien eine auswählen. Da es ziemlich viele Kategorien sind ist ein kleines Javascript eingebaut, was ähnlich wie bei Google funktioniert. Man sieht je nach Eingabe Vorschläge für die Kategorien. Bei dem ganzen wird via Ajax eine Url angesprochen, welche ein JSON Objekt mit den Ergebnissen zurück liefert (soweit meine Firebug analyse). Das Javascript an sich ist nicht das Thema!
Es geht mir vielmehr um die Url die da angesprochen wird. Ruft man diese nämlich einfach so auf, wird man auf eine 404 Seite weitergeleitet.
Also denk ich mir wird der Referrer abgefragt. Also gehe ich wieder auf die Beitrag erfassen Seite, manipuliere via Firebug die Webseite, so dass ein Link zur JSON URl entsteht, klicke drauf und... 404. Oder hab ich an der Stelle einen denkfehler?
* Ich sehe gerade beim Request Header steht Accept auf text/javascript. Kann es sein, dass hier eine Prüfung durchgeführt wird? *
Deshalb wollte ich mal generell fragen wie man seine "Ajax - JSON zurückliefer Seiten" sicherer machen kann?
Gruß
Mr. Propper bevorzugender
T-Rex
-
Hi,
* Ich sehe gerade beim Request Header steht Accept auf text/javascript. Kann es sein, dass hier eine Prüfung durchgeführt wird? *
Irgendein Header der mitgesendet wird, wird wohl geprüft.
Häufig ist das auch "X-Requested-With":"XMLHttpRequest".Deshalb wollte ich mal generell fragen wie man seine "Ajax - JSON zurückliefer Seiten" sicherer machen kann?
Was verstehst du unter "sicherer"?
~dave
-
Was verstehst du unter "sicherer"?
Na ganz einfach. Stell dir vor irgendwo auf deiner Seite hast kannst du eine Nachricht an einen anderen User schreiben. Den Namen eines anderen Users musst du in ein entsprechendes Feld eingeben. Damit du dir nicht alle Namen auswendig merken musst gibt es die beschriebene ausfüll Hilfe mittels Ajax.
Ruft man diese Url einfach so auf und man baut keinerlei zusätzliche "Sicherheiten" ein, so kann man mit einfachsten Hilfsmittel wie dem Browser alle User aus dem System sehen. Dann nur noch ein kleines Script und schwups hat man eine Export möglichkeit für jederman geschaffen. Da kann man ja fast gleich die MySQL zugangsdaten auf die Startseite stellen.
Gruß
Sicherheitsbeamter
T-Rex-
Hallo,
Ruft man diese Url einfach so auf und man baut keinerlei zusätzliche "Sicherheiten" ein, so kann man mit einfachsten Hilfsmittel wie dem Browser alle User aus dem System sehen. Dann nur noch ein kleines Script und schwups hat man eine Export möglichkeit für jederman geschaffen. Da kann man ja fast gleich die MySQL zugangsdaten auf die Startseite stellen.
Aber dann gehört das doch in einen geschlossenen Bereich mit einem Login und entsprechenden User/Session-Handling. Die Ajax-Anfrage kann auch darauf geprüft werden, ob der User eingeloggt ist und ggf. die Auskunft verweigern.
Grüße
Siri-
Aber dann gehört das doch in einen geschlossenen Bereich mit einem Login und entsprechenden User/Session-Handling. Die Ajax-Anfrage kann auch darauf geprüft werden, ob der User eingeloggt ist und ggf. die Auskunft verweigern.
Na in meinem Beispiel muss man eben nicht eingeloggt sein sondern kann als normaler Gast auch Nachrichten an User schicken.
Die Frage ist ja ob man Ajax abfragen sicherer gestallten kann. Mein Wissensstand bis vor 2 Stunden war eine einfache url die man mittels Javascript angefrgat hat. Die konnte man aber auch im browser oder sonst wie ansprechen.
Mir würde eventuell noch ein Timestamp einfallen, so dass Requests nur Timestamp +- 6 Stunden gültig sind. Wobei das Timestamp dann eine von einer Serversprache übergebenen wert haben muss, da sonst der Client timestamp benutzt wird hmm....Gruß
hmm...
T-Rex-
Moin!
Na in meinem Beispiel muss man eben nicht eingeloggt sein sondern kann als normaler Gast auch Nachrichten an User schicken.
Die Frage ist ja ob man Ajax abfragen sicherer gestallten kann. Mein Wissensstand bis vor 2 Stunden war eine einfache url die man mittels Javascript angefrgat hat. Die konnte man aber auch im browser oder sonst wie ansprechen.
Mir würde eventuell noch ein Timestamp einfallen, so dass Requests nur Timestamp +- 6 Stunden gültig sind. Wobei das Timestamp dann eine von einer Serversprache übergebenen wert haben muss, da sonst der Client timestamp benutzt wird hmm....Bringt alles nix.
Diese Schnitstelle macht die Daten öffentlich, weil die uneingeloggte Öffentlichkeit auf die Seite gehen und die Daten sehen kann. Punkt.
Alle Einschränkungen hinsichtlich des Request-Systems müssen ja auch publiziert werden. Selbst wenn man sicherstellen könnte, dass nur Ajax-Requests dieser fraglichen Seite zugelassen wären, und die Information über das korrekte Zusammenstellen eines gültigen Requests nicht leicht ersichtlich wären, könnte man den Browser immer noch mit Selenium fernsteuern, dadurch User-Interaktion simulieren, und mit direktem DOM-Zugriff oder im Zweifel mit Bildschirmfotos die Daten nach und nach exportieren.
Es gibt an dieser Stelle einfach keine mögliche Sicherheit - die wurde per Designentscheidung für das Autocomplete unmöglich gemacht.
- Sven Rautenberg
-
Hmpf...
Ich will ja keine super dupa unknackbare Lösung. Wie schon gesagt vor ein paar Stunden war das ganze noch per browser einfach so erreichbar. JEtzt ist es schon schwerer an die Daten ran zu kommen. Eventuell gibt es noch weitere kniffe die Dinge schwerer zu machen. Und das Beispiel mit den Nachrichten ist rein fiktiv, also bitte nicht zu sehr darauf versteifen, bitte.
Gruß
der Vater sicherer Passwörter via Javascript
T-Rex-
Hi,
Ich will ja keine super dupa unknackbare Lösung. Wie schon gesagt vor ein paar Stunden war das ganze noch per browser einfach so erreichbar. JEtzt ist es schon schwerer an die Daten ran zu kommen.
Security through Obscurity bietet keine "Sicherheit".
Du könntest noch Captchas, Tokens, Timestamps etc. hinzufügen.
Wird es dadurch sicher? Nein."Sicher" ist Boolean. Entweder es ist sicher, oder nicht. Ein bisschen sicher gibt es nicht.
Dein Ansatz verweigert also Menschen die keine Ahnung von der verwendeten Technik haben (Javascript, HTTP, etc.) den einfachen Zugriff auf ggf. sensible Daten.
Ich behaupte, dass diejenigen die böses mit diesen Daten wollen, Kenntnisse in diesen Techniken haben. Was deine "Sicherheit" nutzlos macht.IMHO ist das Größte Problem bei Security through Obscurity dass es das Gefühl von Sicherheit vermittelt. Dadurch wird man fahrlässig.
Vielleicht haben wir nur unterschiedliche Definitionen von "sicher". Mit einem konkretem Fall kann man auch konkreter Argumentieren.
~dave
-
"Sicher" ist Boolean. Entweder es ist sicher, oder nicht. Ein bisschen sicher gibt es nicht.
Ich kann mich dave nur anschließen.
Ein bisschen sicher ist wie ein bisschen schwanger.
Du solltest die Sicherheitslücke da schließen, wo sie ist.-
Ich kann mich dave nur anschließen.
Ein bisschen sicher ist wie ein bisschen schwanger.
Du solltest die Sicherheitslücke da schließen, wo sie ist.Sorry aber das ist Haarspalterei. Eurer Argumentations zu folge gibt es keine Rechtevergabe. Den entweder hat jemand das Recht etwas zu tun oder nicht. Sicherheitsstufen wären demnach völlig absurd.
Nene das System ist sicherer. Und wenn euch das nicht gefällt dann eben "more saver". In letzter Zeit hab ich sowieso das Gefühl das alles mehr an wahrheit gewinnt wenn man es englisch ausspricht, aber das ist ein anderes Blatt.
Aber gut ok, dann drücke ich mich eben anders aus.
gibt es eine möglichkeit die Hürde an meine Daten zu kommen noch etwas höher zu legen, so das erst Entwickler mit dem Skillfaktor 12 auf die Daten zugreifen können?Und ja, hacken kann man alles... vor allem js Anwendungen.
Gruß
Master of the english Begriffe
T-Rex-
Hi,
Sorry aber das ist Haarspalterei. Eurer Argumentations zu folge gibt es keine Rechtevergabe. Den entweder hat jemand das Recht etwas zu tun oder nicht. Sicherheitsstufen wären demnach völlig absurd.
Nein, sind sie nicht.
Wenn jemand das Recht hat den Benutzernamen zu ändern, dann soll er das können.
Wenn jemand dieses Recht nicht hat, soll er das nicht können.Was du machst ist, dass jeder den Benutzernamen ändern kann, nur manche bekommen einen Button und manche müssen ihren Request selbst zusammenbauen.
Das hat nichts mit Sicherheit zu tun, sondern mit Usability :-P
gibt es eine möglichkeit die Hürde an meine Daten zu kommen noch etwas höher zu legen, so das erst Entwickler mit dem Skillfaktor 12 auf die Daten zugreifen können?
Wie angesprochen, Captchas und Tokens.
Du könntest sicher auch noch irgendwo mal was Hashen und Verschlüsseln.
Zudem das Javascript "uglify"en, und ein paar unnötige Requests machen, um vom wesentlichen abzulenken.Und ja, hacken kann man alles... vor allem js Anwendungen.
Ich finde diese Begründung irritierend.
Du lässt nämlich zu dass dein Server "gehackt" wird, unabhängig vom Javascript-Code auf dem Client.
Und mit dieser Begründung könnte man auch auf Sicherungsmaßnahmen gegen SQL-Injection o.ä. verzichten, weil "PHP hat ja sowieso irgendwo eine Sicherheitslücke die das zulässt".~dave
-
-
-
-
-
-
hi,
Na in meinem Beispiel muss man eben nicht eingeloggt sein sondern kann als normaler Gast auch Nachrichten an User schicken.
du möchstes anonymen, also nicht identifzierten und authorisierten Personen, die Möglichkeit bieten, angemeldeten Usern Botschaften zu übermitteln? Und darüberhinaus stellst du den nicht identifzierten und authorisierten Personen implizit auch noch eine Liste aller User zu Verfügung?
*** O M G ***
-
du möchstes anonymen, also nicht identifzierten und authorisierten Personen, die Möglichkeit bieten, angemeldeten Usern Botschaften zu übermitteln? Und darüberhinaus stellst du den nicht identifzierten und authorisierten Personen implizit auch noch eine Liste aller User zu Verfügung?
*** O M G ***
Lesen hilft.
-
hi,
Na in meinem Beispiel muss man eben nicht eingeloggt sein sondern kann als normaler Gast auch Nachrichten an User schicken.
du möchstes anonymen, also nicht identifzierten und authorisierten Personen, die Möglichkeit bieten, angemeldeten Usern Botschaften zu übermitteln? Und darüberhinaus stellst du den nicht identifzierten und authorisierten Personen implizit auch noch eine Liste aller User zu Verfügung?
*** O M G ***
Maybe i have to versuchen, all with english wörter, voll zu dumpen. Eventuell and maybe, werde ich than, correct understanding, you know?
But if you smile with me, its also ok.
Best regards
T-Rex
-
-
-
-
-
-
hi,
* Ich sehe gerade beim Request Header steht Accept auf text/javascript. Kann es sein, dass hier eine Prüfung durchgeführt wird? *
Na chiser!
Deshalb wollte ich mal generell fragen wie man seine "Ajax - JSON zurückliefer Seiten" sicherer machen kann?
Chiser ist der flasche Bgeriff. Aber wenn Du Langeweile hast, könntest Du was bauen, womit diejenige Ressource, wo die Ajaxresponsen rasufeuert, nur unter bestimmten Bedingungen gecallt werden kann, einen conditional request sozusagen. Und das geht so:
Bilde eine Checksumme aus allem, was der Browser so hergibt, also Datum, Bildschirmauflösung, Zeitzone, Browserversion usw. Dieser mdfive-Hugo geht zusammen mit dem window.location.pathname ab zum Server per ajax und wird in eine table eingetragen. Falls Du das nicht schon hast, das ist ein simpler counter, denn wolltest Du doch sowiso schlange mal porgammreiren.
Nochn Ajax, das autocomplete. Schicke denselben Hugo wieder mit und guck serverseitig, ob der mindestens einmal eingetragen ist. Dann kann die Response erfolgen, sonst nicht. Ein State 404 wäre zwar geschwindelt, aber wayne kümmerts. Wenn Du einen echten 404er machen möchtest, geht das über die beretis erwähnte Content-Negotiation, das XHR-Object muss dazu einen extra Request-Header mitsenden und die Responschee-Machine überlegt sich das.
Ho-Ch'ti