Meine Kollegen behaupten, dass XSS eine Sicherheitslücke auf der Serverseite ist. Ich habe immer gedacht, dass dies eine clientseitige Sicherheitslücke ist. Wer von uns ist richtig und warum?
Bei einem Cross-Site-Scripting-Angriff wird das schädliche Skript auf dem Client ausgeführt, der eigentliche Fehler liegt jedoch in der Anwendung. Dies bedeutet nicht unbedingt, dass es sich um eine streng serverseitige Sicherheitsanfälligkeit handelt, da der Fehler im JavaScript der Anwendung liegen kann. Im Allgemeinen handelt es sich jedoch tatsächlich um serverseitigen Code und immer um Code, der vom Server bereitgestellt wird.
Es gibt clientseitige Abhilfemaßnahmen, z. B. den XSS-Schutz, der jetzt in den wichtigsten Browsern integriert ist, oder Plugins, die die Ausführung von JavaScript verhindern. Letztendlich ist XSS jedoch eine Sicherheitsanfälligkeit für Webanwendungen und muss dies auch sein von den Anwendungsentwicklern behoben.
Ich sollte erwähnen, dass es eine andere Form von XSS gibt, die weder Fehler im Client (dem Browser) noch Fehler im Server (der Anwendung) ausnutzt, sondern Fehler im Benutzer. Dies wird oft als Self-XSS bezeichnet und nutzt die Bereitschaft eines unfähigen Benutzers aus, JavaScript auszuführen, das er aus dem Internet in die Entwicklertools-Konsole seines Browsers kopiert und eingefügt hat, und zwar ausschließlich auf der Grundlage des Versprechens, dass dies trotz aller Hoffnung auf magische Weise möglich ist er soll die Facebook-Beiträge seiner Ex-Freundin lesen, obwohl sie ihn nicht befreundet und blockiert hat.
Es manifestiert sich auf der Clientseite, aber das liegt daran, dass die Webanwendung dies zulässt. Die Anwendung überprüft den Code, den sie an den Browser zurücksendet, nicht. Und deshalb handelt es sich um eine serverseitige Sicherheitslücke. Denken Sie so darüber nach. Was würden Sie tun, um das Problem mit XSS zu beheben? Den serverseitigen Code korrigieren oder den Browser reparieren?
XSS-Angriffe (Cross-Site Scripting) können im Allgemeinen als eine der folgenden Kategorien eingestuft werden:
Der Angriff selbst findet auf dem Client statt. Alle drei Angriffstypen können sich bei einer einzelnen Seite oder einer Offline-Anwendung vollständig im Browser selbst manifestieren. Wenn die Daten jedoch auf dem Server gespeichert sind oder vom Server reflektiert werden, hilft der Server bei der Sicherheitsanfälligkeit.
IE8 führte X-XSS-Schutz ein, wodurch es schwieriger wurde, reflektierte Angriffe auszunutzen.
Die Terminologie ist etwas rutschig, aber normalerweise ist ein "XSS-Fehler" ein clientseitiger Exploit einer serverseitigen Sicherheitsanfälligkeit .
Cross-Site Skripterstellung ist an und für sich kein Sicherheitsproblem . Das Problem ist, dass dies ohne Wissen des Endbenutzers geschehen kann. Die meisten Websites sind natürlich nicht dafür codiert: Entweder verwenden sie überhaupt kein Cross-Site-Scripting, oder sie machen deutlich, dass sie dies tun. Wenn Benutzer jedoch ihre eigenen Inhalte veröffentlichen können, müssen Sie sie davon abhalten, den Seiten beliebige Skript-Tags hinzuzufügen. Andernfalls könnten sie Inhalte in die Seite einfügen, die Daten an wen sendet, der weiß, wo.
Um dies zu verhindern, müssen Sie den vom Benutzer erstellten Inhalt analysieren und dann "sauberes" HTML für generieren Anzeige ohne die Tags, die Sie nicht möchten (z. B. Skript-Tags). Einige Websites nutzen diese Möglichkeit, damit Benutzer ihren Inhalt in einer Sprache erstellen, die nicht HTML ist: Stack Exchange verwendet Markdown. Aber solange Sie den Inhalt noch richtig analysieren , können Sie auch HTML als Eingabesprache verwenden. Es gibt keinen Leistungsvorteil, wenn HTML-zu-HTML ordnungsgemäß ausgeführt wird, da es dieselbe Art von Analyse- / Generierungszyklus durchläuft wie andere Sprachen, aber es ist eine Sprache weniger, die Entwickler (und möglicherweise Benutzer) lernen müssen. Sie müssen jedoch der Versuchung widerstehen, den HTML-Inhalt unverändert wiederzuverwenden oder anstelle eines Analyse- / Generierungszyklus einige Light-String-Ersetzungen vorzunehmen.
Ein "XSS-Fehler" tritt auf, wenn Benutzer herausfinden, wie beliebiges HTML auf der Site veröffentlicht werden soll . Normalerweise geschieht dies, wenn Entwickler HTML-Eingaben direkt verwenden, ohne den Analyse- / Generierungszyklus zu durchlaufen, aber manchmal findet jemand einen Weg, den Generator der Site dazu zu bringen, ihnen HTML zu geben, für das er nicht entwickelt wurde. In beiden Fällen ist das Endergebnis dasselbe: Sobald ein Benutzer beliebiges HTML veröffentlichen kann, kann er damit Cross-Site-Scripting durchführen. Deshalb nennen wir es einen XSS-Fehler. Der Fehler liegt jedoch nicht im XSS selbst, sondern im serverseitigen Code, mit dem zunächst beliebige Skripts veröffentlicht werden konnten.
Es wird im Allgemeinen empfohlen, so viele Dinge wie möglich auf der Serverseite und nicht auf der Clientgröße aus folgenden Gründen zu filtern:
Ein XSS-Angriff unterscheidet sich nicht wesentlich von einer SQL-Injection. Beides wird dadurch verursacht, dass Benutzereingaben nicht richtig gesteuert werden. XSS-Angriffe werden im Allgemeinen in Ihrer Datenbank gespeichert und über Ihr System an Ihre Clients verteilt.
Das Filtern nach XSS-Angriffen sollte nach Benutzereingaben erfolgen. Sie sollten im Allgemeinen keine Javascript-Eingaben akzeptieren. Wenn Sie unbedingt benötigen, dass Ihre Clients Javascript eingeben können, z. B. bei Programmierseiten, sollten Sie es zuerst maskieren.
Ich hoffe, es hat geholfen. Ich empfehle diese Lektüre für weitere Informationen: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Ich habe einige Leute gelesen, denen es wichtig ist, die URL oder was auch immer nicht zum Laden anderer Benutzerinformationen oder was auch immer zu verwenden (wie einige hier in Googles Tutorial - https://xss-game.appspot.com/)
Das ist zwar schön zu wissen, aber Sie müssen sich daran erinnern, dass jede einzelne Funktion und jeder einzelne Code auf der Clientseite willkürlich ausgeführt werden kann. Die Validierung und der Schutz für XSS erfolgen vom Server. Ich meine, denken Sie darüber nach, Sie können die Konsole selbst öffnen.
Die Idee ist die Injektion von bösartigem Code vom Client, der letztendlich eine Sicherheitslücke auf dem Server darstellt. Dies kann dazu führen, dass die anderen Clients Webseiten mit darin eingebetteten beschissenen Skripten erhalten. Stellen Sie sich ein Forum vor - wenn Sie nur Tags in diesem Beitrag gespeichert und gerendert haben, den jemand erstellt hat, können Sie möglicherweise Code für jeden ausführen, der diesen Forumbeitrag anzeigt.
Wenn beispielsweise der Stapelüberlauf nicht ordnungsgemäß maskiert wurde Sie wären wahrscheinlich zu google.com mit dem folgenden
window.location.href = ' http://google.com' weitergeleitet worden (stellen Sie sich vor, dies wäre umgeben von Skript-Tags, SE formatiert sie aus und ist zu faul, um ihnen zu entkommen)
Es handelt sich um eine serverseitige Sicherheitsanfälligkeit, die über clientseitige Anwendungen ausgenutzt werden kann.
"Grundsätzlich kann ein Angreifer durch Erstellen einer speziell formatierten E-Mail JavaScript einbetten, sodass das Skript im Browser des Opfers ausgeführt wird, wenn die E-Mail auf Yahoo Mail angezeigt wird", sagte Pynnonen in einer E-Mail an Threatpost. "Der Angreifer benötigte keinen speziellen Zugriff. Tatsächlich kann der Angriff ausgeführt werden, ohne sich bei Yahoo Mail zu registrieren. Es wird nur die Yahoo-E-Mail-Adresse des Opfers benötigt. “
In einer Beschreibung der am Donnerstag veröffentlichten Sicherheitsanfälligkeit erklärte Pynnonen, wie er eine E-Mail mit böswilligen Daten- * Attributen formatieren kann, die böswilliges JavaScript an den ausgeführten Yahoo-Filtern vorbeischleichen durch Missbrauch der Art und Weise, wie Yahoo Mail Links zu Websites auf der Whitelist wie YouTube anzeigt. [hier vorformatierten Text eingeben] [1]
Im Gegensatz zu dem, was viele andere glauben, ist xss sowohl clientseitig als auch serverseitig.
Ein persistentes xss ist serverseitig, da der Server den Code ausführt, der im Client ausgeführt werden soll. Wenn es nicht persistent ist, wird es als clientseitig betrachtet, da der Client das Ergebnis nur über diese Eingabe erhalten kann.
Sinnvoll?