![Hands-On Bug Hunting for Penetration Testers](https://wfqqreader-1252317822.image.myqcloud.com/cover/440/36699440/b_36699440.jpg)
Putting It All Together
So what does it look like when we put it all together? It's simple – we can construct a one-liner to scan the JavaScript of a target site just by passing the right directory references:
grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs
Keep in mind we've already symlinked these scripts to our /usr/local/bin and changed their permissions using chmod u+x to make them executable and accessible from our path. With this command, we're telling our CL to download the JavaScript from http://target.site to the sourcejs directory, then scan that directory, create an output.json representation of the data, and finally format everything as a plain-text report.
As a means of testing the command, I recently read a blog decrying the fact that jQuery, responsible for a large chunk of the web's client-side code, was running an out-of-date WordPress version on http://jquery.com/, so I decided to see whether their JavaScript had any issues:
grabjs https://jquery.com sourcejs; scanjs sourcejs output.json | formatjs
![](https://epubservercos.yuewen.com/89F73A/19470388701539106/epubprivate/OEBPS/Images/b5b352c7-9a2d-4917-b3cf-6d27dc6f2207.png?sign=1738891325-6yOPMS3dC2oRknFEcRgMaboty0em2hbG-0-e136353e82219a0e4aacf6f71a4d4154)
The fact that http://jquery.com/ has a few issues is nothing huge, but still surprising! Known component vulnerabilities in JavaScript are a widespread issue, affecting a sizable portion of sites (different methodologies put the number of affected sites at between one-third and three-quarters of the entire web).