Hands-On Bug Hunting for Penetration Testers
上QQ阅读APP看书,第一时间看更新

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

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).