Blog Zscaler
Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta
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.
Questo post è stato utile?
Esclusione di responsabilità: questo articolo del blog è stato creato da Zscaler esclusivamente a scopo informativo ed è fornito "così com'è", senza alcuna garanzia circa l'accuratezza, la completezza o l'affidabilità dei contenuti. Zscaler declina ogni responsabilità per eventuali errori o omissioni, così come per le eventuali azioni intraprese sulla base delle informazioni fornite. Eventuali link a siti web o risorse di terze parti sono offerti unicamente per praticità, e Zscaler non è responsabile del relativo contenuto, né delle pratiche adottate. Tutti i contenuti sono soggetti a modifiche senza preavviso. Accedendo a questo blog, l'utente accetta le presenti condizioni e riconosce di essere l'unico responsabile della verifica e dell'uso delle informazioni secondo quanto appropriato per rispondere alle proprie esigenze.
Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta
Inviando il modulo, si accetta la nostra Informativa sulla privacy.








