Zscaler Blog
Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang
Spotting Malicious JavaScript in a Page
Source
Most malicious JavaScript is pulled from a different domain other than the hijacked page. One of the first things I look for is the list of JavaScript files pulled from external domains. For example, hxxp://kelly-monaco.org/ contained a script pulled from inforaf.vot.pl that turned out to be malicious.
![]() |
| Malicious external JavaScript |
Location
Another good clue is the location of the script tag on the page. The attackers might be lazy and put the script tag at the very top or very bottom of the page. Always look at scripts placed before the opening HTML tag, or after the ending BODY tag.
![]() |
| http://www.china-crb.cn/ |
Coding Style
When I analyze a page, I also look for different coding styles. For example, if a webmaster uses double quotes around tag attributes, I would then look for a SCRIPT tag with single quotes, or no quotes at all. Similarly, the webmaster might use the type and language attributes. Any SCRIPT tag that uses a different coding style would raise a red flag.
Well hidden
Here are some examples of very well hidden pieces of JavaScript that I've encountered. In the first example, the website is using vBulletin, an open-source forum application. All vBulletin pages contain inline JavaScript to call vBulletin_init(). The attacker inserted his JavaScript between the original JavaScript command, and the function call:
![]() |
| http://theexerciseblog.com/ |
![]() |
| Malicious code appended to AC_RunActiveContent.js |
An even more tricky spot to identify, but one more rarely used, is the insertion of malicious JavaScript inside a CSS style using expression():
![]() |
| Malicious JavaScript in a style-sheet |
These techniques are even combined with other tricks to deliver code directed only at specific users, such as IP denylisting to block security scanners, cookies to prevent viewing the page twice, looking at the Referer tag to show the malicious code to users from specific sites, etc. The same page often has to be accessed in many different ways by security scanners to ensure that it is safe.
War dieser Beitrag nützlich?
Haftungsausschluss: Dieser Blog-Beitrag wurde von Zscaler ausschließlich zu Informationszwecken erstellt und wird ohne jegliche Garantie für Richtigkeit, Vollständigkeit oder Zuverlässigkeit zur Verfügung gestellt. Zscaler übernimmt keine Verantwortung für etwaige Fehler oder Auslassungen oder für Handlungen, die auf der Grundlage der bereitgestellten Informationen vorgenommen werden. Alle in diesem Blog-Beitrag verlinkten Websites oder Ressourcen Dritter werden nur zu Ihrer Information zur Verfügung gestellt, und Zscaler ist nicht für deren Inhalte oder Datenschutzmaßnahmen verantwortlich. Alle Inhalte können ohne vorherige Ankündigung geändert werden. Mit dem Zugriff auf diesen Blog-Beitrag erklären Sie sich mit diesen Bedingungen einverstanden und nehmen zur Kenntnis, dass es in Ihrer Verantwortung liegt, die Informationen zu überprüfen und in einer Ihren Bedürfnissen angemessenen Weise zu nutzen.
Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang
Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.








