Ich denke, der Name „Cross-Site“ ist verwirrend. Man hört das leicht und denkt, es gehe darum, dass Code auf einer Website Code auf einer anderen Website angreift. Das ist es nicht. Ganz zu schweigen von der unglücklichen „wahren“ Abkürzung.
Es bedeutet einfach: **Ausführung von beliebigem JavaScript-Code auf der Seite.**
Dies kann JavaScript sein, das in die URL eingefügt wird oder durch Formularübermittlungen. Wenn eine dieser Möglichkeiten, Informationen zu akzeptieren, die erhaltenen Informationen nicht „bereinigt“, bevor sie wieder auf der Seite ausgegeben werden, dann kann beliebiger JavaScript-Code auf dieser Seite ausgeführt werden und das ist eine XSS-Schwachstelle.
Wenn JavaScript auf der Seite ausgeführt werden kann, dann kann es auf Cookies zugreifen.
Wenn es auf Cookies zugreifen kann, dann kann es auf aktive Sitzungen zugreifen.
Wenn es auf aktive Sitzungen zugreifen kann, kann es sich bei Websites, bei denen Sie angemeldet sind, als Sie anmelden, zumindest lange genug, um Passwörter oder andere Verwüstungen zu ändern.
Symantec hat gesagt, dass 80 % der Internet-Schwachstellen auf XSS zurückzuführen sind.
XSS unterscheidet sich von, ist aber im Geiste ähnlich wie SQL-Injection. SQL-Injection ist, wenn SQL-Befehle nicht aus Eingaben bereinigt werden und somit bösartige Dinge mit einer Datenbank anstellen können. Die Verwendung von HTTPS kann weder bei XSS noch bei SQL-Injection helfen. HTTPS schützt nur Daten während der Übertragung über Netzwerke.
Ich bin kein Sicherheitsexperte, ich verbreite nur die Botschaft: Lasst uns diese Eingaben bereinigen, Leute! Hier ist ein Anfang.
Wenn Sie noch etwas hinzuzufügen haben oder denken, ich liege komplett falsch, dann legen Sie los!
Hier ist eine Beschreibung und ein Beispiel für einen XSS-Angriff
Ich schätze es sehr, dass das so verständlich erklärt wurde! Ich fand den Begriff definitiv verwirrend und gehörte zu denen, die dachten, XSS sei eine Art böse Website, die Daten an eine andere Website sendet oder so etwas.
Juhu, ich habe etwas gelernt! :)
Dies war eine gute Einführung für mich
Sehr informativ, danke Chris!
Das ist der Hauptgrund, warum ich ein PHP-Framework verwende, anstatt selbst eines zu erstellen (harte Arbeit! :|). Sie bieten zusätzliche Sicherheit, um Daten zu bereinigen und XSS- und SQL-Injection-Angriffe zu verhindern.
Man muss trotzdem vorsichtig sein, welches man wählt – nur weil es veröffentlicht (oder sogar gekauft) ist, heißt das nicht, dass es sicher ist.
Da ich kein PHP-Entwickler bin, interessiert mich diese Aussage. Sicherlich liegt das daran, wie Methoden erstellt werden und wie HTML-Eingaben/versteckte Werte/Abfragestrings vom Entwickler behandelt werden und nicht am PHP-Framework selbst?
Letztendlich wird der Code des Entwicklers die Dinge „machen oder brechen“, ja.
Aber das Framework wurde auch von jemandem entwickelt. Einige wurden von Leuten entwickelt, die wirklich wissen, was sie tun, und einige wurden von Leuten geschrieben, die nur dachten, sie wüssten es.
Viele Leute, die sie verwenden, wissen nicht genug über Sicherheitsbedenken oder können den Code nicht wirklich prüfen, um selbst festzustellen, wie „narrensicher“ das Framework ist. Mein Punkt ist, dass man nicht einfach davon ausgehen kann, dass etwas funktioniert, nur weil es zum Download verfügbar ist und das zu tun scheint, was man will.
@Traq: Ja, da stimme ich Ihnen vollkommen zu. Mit meinem Kommentar meinte ich nicht, dass man bestehenden PHP-Frameworks blind vertrauen sollte. Mein Punkt war, dass es für mich auf meinem aktuellen Erfahrungsniveau besser wäre, ein Framework zu verwenden, da es mir eine „bessere“ Sicherheit bietet, als von Grund auf neu zu beginnen.
@Philp: Alles hängt von den Methoden und der Art und Weise ab, wie Sie die Objekte manipulieren. Aber PHP-Frameworks bieten vorgefertigte Methoden, die Ihnen helfen, Eingaben zu desinfizieren. Wenn Sie von Grund auf neu beginnen, müssen Sie all das schreiben und haben auch immense Kenntnisse über Websicherheit, um überhaupt erst anzufangen. Aber wie von Traq gesagt, man sollte Frameworks nicht blind vertrauen und über Websicherheit lernen. :)
Ich glaube auch, dass man, wenn man bei einem persönlichen Projekt von Grund auf anfängt, in diesem gesamten Prozess viel lernen kann.
Einfacher String-Ersatz ist bei weitem nicht gut genug, er ist ziemlich leicht zu umgehen. Mein bevorzugter Input-Cleaner ist htmlpurifier: http://htmlpurifier.org/ Eine gute Referenz für die Art von Dingen, die Leute versuchen könnten, ist http://ha.ckers.org/xss.html
Danke Chris. Das war ein wirklich guter Hinweis!
Hallo,
Sie liegen größtenteils richtig und es ist großartig, so etwas auf einer Nicht-Sicherheits-Website zu sehen.
Wie Sie jedoch erwähnen, ist XSS eine Möglichkeit, beliebigen Code auf einer Website einzubetten. Es könnte JEDER Code sein, um als XSS klassifiziert zu werden. Es könnte so harmlos sein wie die Änderung des Hintergrunds in etwas, das der ursprüngliche Besitzer nicht unbedingt wünscht, bis hin zu Dingen. Viel XSS-Code wird verwendet, um gefälschte Klicks auf Werbung, Weiterleitungen und sogar „böswillige“ Suchmaschinenoptimierung (SEO) zu erstellen.
Der zweite Teil Ihres Artikels ist eigentlich eine spezifische Art von XSS, die als Cross-Site Request Forgery (CSRF) bezeichnet wird, was ebenfalls ein dummer Name ist und im Grunde nur die eingeschleuste JavaScript (oder in seltenen Fällen eine andere bösartige Methode) verwendet, um Cookies zu stehlen und Sitzungen zu kapern.
Grundsätzlich verhindert die Nichtzulassung einer dritten Partei, Code auf Ihrer Seite einzubauen, den ersten Angriff und schränkt den zweiten ein.
Hey Allen, CSRF hat nicht genau mit XSS zu tun. Sie können immer noch anfällig für CSRF sein, auch wenn Sie keine XSS-Schwachstellen haben. Und es erfordert auch kein JavaScript. Wenn die Schwachstelle über HTTP GET ausgenutzt wird, kann eine einfache Bild-/CSS-/iframe-Anfrage (oder eine Reihe davon) sie ausnutzen.
CSRF nutzt im Grunde die Wahrscheinlichkeit aus, dass ein Benutzer bereits bei einer Zielseite autorisiert ist und Aktionen auf dieser Seite gegen das Wissen des Benutzers ausführt. Ich glaube, Twitter wurde kürzlich davon getroffen (google: csrf twitter goats).
—
In Bezug auf XSS sollten Sie idealerweise Ihre Eingaben validieren (aber nicht „bereinigen“ – ungültige Eingaben sollten überhaupt nicht akzeptiert werden). Stattdessen sollten alle Daten (vom Benutzer generiert oder anderweitig) immer, wenn sie ausgegeben werden, escaped werden.
Ich mag die Bereinigung von Eingaben nicht, da dies Daten verzerrt, und außerdem sollte ein gut entwickeltes System, das Freitext-Eingaben unterstützt, in der Lage sein, jede Eingabe zu unterstützen.
@Lee…
Das ist tatsächlich mein Punkt. Der Artikel (der verdammt gut ist) irrt, wenn er die beiden vermischt. Sie gehen normalerweise Hand in Hand, aber wie Sie erwähnen, kann CSRF ohne JavaScript oder XSS überhaupt erreicht werden.
Escaping ist eine Verteidigung, aber man muss sicher sein, dass die Eingabe nicht irgendwo im Prozess „de-escaped“ wird.
Vielen Dank, dass Sie diesen Aspekt der Sicherheit behandeln! Was ist mit AJAX-Anfragen in WordPress? Ich meine, die Anfragen vom Frontend? Ich habe kürzlich ein schlankes Plugin entwickelt, bei dem Benutzer einen Artikel per AJAX in einen Warenkorb legen, um in eine Sitzung zu schreiben. Weiß jemand etwas über diese Sicherheitsprobleme?
Ich stelle mir vor, dass Sie eine Art von „Tokens“ verwenden könnten (ähnlich wie bei Formularübermittlungen), um zu überprüfen, ob die AJAX-Anfrage von einer gültigen (und aktuellen) Sitzung stammt.
Ich weiß nichts über WP speziell, aber ich entwickle gerade eine Website, die viel AJAX verwenden wird, um auf PHP-Funktionsaufrufe zuzugreifen, also ist das ein Problem, das ich angehen muss.
Vor ein paar Monaten habe ich recherchiert, um SQL- und XSS-Injections zu beheben, und diese einfache Methode mit .htaccess gefunden
Ich glaube, es funktioniert, oder?
Ich empfehle dringend, den folgenden Artikel zu lesen und sich auf der Website Open Web Application Security Project umzusehen.
http://owasp.blogspot.com/2010/11/preventing-xss-with-content-security.html
:)
Schöne Erklärung, und es ist immer gut, den Code so gut wie möglich zu bereinigen, besonders wenn er die Sicherheit der Website verbessert. LT
Ist XSS auch Teil von HTML5?
Es ist immer noch ein Risiko, ja.
Letztendlich kommt das Risiko meist von den Benutzern (Codern) und nicht von der Sprache (Code) selbst. Es ist relativ einfach, etwas zu erstellen, das „funktioniert“, aber schwieriger sicherzustellen, dass es nicht missbraucht wird. Manchmal vergessen die Leute den zweiten Teil.
Danke für den Beitrag, aber müssen Webdesigner das wirklich lernen? Angenommen, sie kennen kein PHP?
(PS – Ich bin ein PHP-Entwickler, der lernt zu designen, und deshalb bin ich hier)
Schöner Beitrag. Webdesigner sollten dies bei der Gestaltung von Webanwendungen berücksichtigen.
Lernen Sie SQL-Injection mit Beispiel.