Häufige Sicherheitslücken in JavaScript und automatisierte Erkennungstechnologie

Vorwort

Mit der Entwicklung von Web2.0 und der Popularität des Ajax-Frameworks nehmen Rich-Client-Webanwendungen (Rich Internet Applications, RIA) von Tag zu Tag zu, und immer mehr Logik wird von der Serverseite auf übertragen Der Client verwendet normalerweise alle diese Logiken. Aber leider schenken Entwickler der Sicherheit von JavaScript-Code im Allgemeinen nicht viel Aufmerksamkeit. Laut dem mittelfristigen Trendbericht IBM X-Force 2011 weisen 40 % der Fortune-500-Websites und allgemein bekannter Websites JavaScript-Sicherheitslücken auf. Dieser Artikel zeigt den Lesern häufige Sicherheitslücken in JavaScript in Kombination mit Code auf und soll den Lesern dabei helfen, diese Sicherheitslücken bei der täglichen Codierungsarbeit zu vermeiden. Darüber hinaus unterscheiden sich die Prinzipien clientseitiger Sicherheitslücken in JavaScript geringfügig von denen serverseitiger Sicherheitslücken. Es gibt derzeit große technische Schwierigkeiten bei der automatischen Erkennung von Sicherheitslücken in JavaScript Neue Funktionen von IBM Rational AppScan Standard Edition V8.0 (JavaScript Security Analyzer (JSA)-Technologie erkennt automatisch JavaScript-Sicherheitslücken.

Häufige Sicherheitslücken in JavaScript

Im Dezember 2010 veröffentlichte IBM ein Whitepaper zu clientseitigen JavaScript-Sicherheitslücken in Webanwendungen, in dem die vom IBM Security Research Institute durchgeführte Umfrage zum JavaScript-Sicherheitsstatus vorgestellt wurde. Die Beispieldaten umfassen 675 Websites, darunter Websites von Fortune-500-Unternehmen, und weitere 175 bekannte Websites, darunter IT-Unternehmen, Unternehmen für Webanwendungssicherheitsdienste, Websites sozialer Netzwerke usw. Um den normalen Betrieb dieser Websites nicht zu beeinträchtigen, verwendeten die Forscher einen nicht-invasiven Crawler, der nur eine Teilmenge der Seiten scannte, auf die ohne Anmeldung zugegriffen werden konnte, also nicht mehr als 200 Seiten pro Website. Diese Seiten wurden gespeichert und die Forscher nutzten die JavaScript-Sicherheitsanalysetechnologie von IBM, um diese Seiten offline zu analysieren, wobei sie sich auf DOM-basierte Cross-Site-Scripting- und Umleitungsschwachstellen konzentrierten.

Die Testergebnisse sind erstaunlich. 14 % dieser bekannten Websites weisen schwerwiegende JavaScript-Sicherheitsprobleme auf. Hacker können diese Schwachstellen nutzen, um betrügerische Software einzuschleusen, Phishing-Seiten einzuschleusen und Benutzersitzungen zu kapern. Noch erstaunlicher ist, dass der X-Force-Bericht Mitte 2011 mit der Reife der JavaScript-Sicherheitsanalysetechnologie von IBM zeigte, dass IBM die oben genannten bekannten Websites erneut getestet und weitere Sicherheitslücken entdeckt hat. Etwa 40 % der Websites verfügen über JavaScript-Sicherheit Schwachstellen.

Java Enterprise-Level Universal Permission Security Framework Quellcode SpringMVC Mybatis oder Hibernate Ehcache Shiro Druid Bootstrap HTML5

Der folgende Artikel zeigt den Lesern diese häufigen Sicherheitslücken in JavaScript in Kombination mit Code auf, sodass Leser diese Sicherheitsprobleme während des eigentlichen Codierungsprozesses erkennen und diese Risiken so früh wie möglich vermeiden können.

DOM-basiertes Cross-Site-Scripting

Wir haben alle von XSS (Cross Site Script, auch bekannt als Cross-Site-Scripting-Angriff) gehört, bei dem es sich um einen Angreifer handelt, der bösartigen Skriptcode (normalerweise HTML-Code und JavaScript) in den Code legitimer Webseiten einfügt und diesen dann übermittelt Anfrage an den Server, und dann wird der Server-Antwortseite der bösartige Skriptcode des Angreifers implantiert. Der Angreifer kann diese bösartigen Skriptcodes verwenden, um Angriffe wie Session-Hijacking durchzuführen. Cross-Site-Scripting wird im Allgemeinen in reflektierende und persistente Typen unterteilt: Reflektives Cross-Site-Scripting tritt auf, wenn Anforderungsdaten unverschlüsselt und ungefiltert auf der Server-Antwortseite gerendert werden. Persistent bezieht sich auf Anforderungsdaten, die bösartigen Code enthalten. Sie werden auf dem Server des Servers gespeichert Webanwendung. Jedes Mal, wenn der Benutzer eine bestimmte Seite besucht, wird der Schadcode automatisch ausgeführt. Diese Art von Angriff kommt besonders häufig bei Social-Networking-Sites vom Typ Web 2.0 vor und die Bedrohung ist auch größer. Es gibt im Wesentlichen zwei Möglichkeiten, mit Cross-Site-Scripting umzugehen: erstens, keiner Benutzereingabe zu vertrauen und die Whitelist-Technologie zu verwenden, um Eingabeparameter zu überprüfen, zweitens, den vom Benutzer bereitgestellten Inhalt bei der Ausgabe zu maskieren;

Aber wenig bekannt ist, dass es eine dritte Art von Cross-Site-Scripting-Schwachstelle gibt. Im Jahr 2005 veröffentlichte Amit Klein das Whitepaper „DOM Based Cross Site Scripting or XSS of the Third Kind“, das DOM-basiertes Cross-Site-Scripting enthüllte Der Inhalt muss nicht auf serverseitige Antworten angewiesen sein. Wenn einige HTML-Seiten Attribute von DOM-Elementen wie document.location, document.URL oder document.referer verwenden, können Angreifer diese Attribute verwenden, um bösartige Skripte einzuschleusen, um DOM-Elemente zu implementieren. basierte Querverweise.

Im Folgenden demonstrieren wir das Prinzip des DOM-basierten Cross-Site-Scripting anhand einer sehr einfachen HTML-Seite. Angenommen, es gibt eine statische HTML-Seite (siehe Listing 1), die eine Meldung anzeigt, die den Benutzer zu einer erfolgreichen Anmeldung begrüßt.

Liste 1. HTML-Code mit DOM-basiertem XSS

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
 var pos=document.URL.indexOf("name=")+5;
 document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>

Nach dem Login kopieren

按照该页面 JavaScript 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息，如清单 2 所示：

清单 2. 正常情况下的访问 URL

http://www.vulnerable.site/welcome.html?name=Jeremy

但如果恶意攻击者输入类似如下的脚本，见清单 3，该页面则会执行被注入的 JavaScript 脚本。

清单 3. 访问 URL 中注入脚本

http://www.vulnerable.site/welcome.html?name=

Neueste Artikel des Autors