Blog de Zscaler
Reciba en su bandeja de entrada las últimas actualizaciones del blog de Zscaler
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.
¿Este post ha sido útil?
Exención de responsabilidad: Este blog post ha sido creado por Zscaler con fines informativos exclusivamente y se ofrece "como es" sin ninguna garantía de precisión, integridad o fiabilidad. Zscaler no asume responsabilidad alguna por cualesquiera errores u omisiones ni por ninguna acción emprendida en base a la información suministrada. Cualesquiera sitios web de terceros o recursos vinculados a este blog se suministran exclusivamente por conveniencia y Zscaler no se hace responsable de su contenido o sus prácticas. Todo el contenido es susceptible a cambio sin previo aviso. Al acceder a este blog, usted acepta estas condiciones y reconoce su responsabilidad exclusiva de verificar y utilizar la información según sea precisa para sus necesidades.
Reciba en su bandeja de entrada las últimas actualizaciones del blog de Zscaler
Al enviar el formulario, acepta nuestra política de privacidad.








