Tonight we’ll be playing around with Vega, a web vulnerability scanner developed by an open security company named Subgraph.
Wait a minute… That logo — plagiarism?!
So getting Vega to work wasn’t quite so easy. There was a lot of guessing involved and it ended up taking much longer than I anticipated but in retrospect if I had just read the website’s documentation more extensively I would have had it going in no time at all.
Horrah! After getting the missing library that Subgraph.com so kindly told us to get, Vega is functioning as it should (or at least appears to be).
I think that reference (see the caption above) deserves a moment. So let’s take a moment before we move on.
Okay now that Vega is finally up and running we can finally use it to tear holes in the websites we love! Our target:
So apparently all we have to do is aim Vega at the desired site and press the button!
All we did was press “Start New Scan” and then pasted the URL of the desired site to be scanned. The way Vega works is this, it scans a page for potential input fields. In those fields Vega attempts to inject various codes so as to see if the field is vulnerable to any sort of attack. If so, it will be reported in the Scan Alert Summary. So the waiting game begins. But wait — already one bite!
Oh wait this is actually taking a while… Let’s find something else to do: anime with commentary à la David (start from the beginning of the slideshow for maximal pleasure).
Handy tip from David:
“Time flies when you watch anime.”
“Watch Pokémon. It’s quality of comedy has grown immensely. But I can only vouch for the subbed version.”
“Dubbed anime sucks.”
In the meantime it seems that our scan has completed!
So it appears that no XSS vulnerabilities were found which is both unfortunate and relieving because it’s always fun to break things but also: good job school! On the other hand there are these 3 SQL injection vulnerabilities. SQL injections are similar to XSS attacks except the code that is inputted into fields is SQL code (code for managing databases). These types of attacks would allow attackers to dump database contents to the attacker’s desired location. So it is somewhat worrying since who knows what sensitive data is on these servers.
And then there’s 1 “Page Fingerprint Differential Detected – Possible Local Files Include” which just means that there’s some place on the site where an attacker can include a file that is from the local server. The local file include (LFI) is different from a remote file include (RFI) in that one can essentially say that an RFI is the basis for XSS whereas a LFI can only use files that are local to the server (the locality of the file in an LFI is the crux of the difference).
And so I guess we can say that the Johns Hopkins Computer Science department’s website is fairly secure (at least against XSS)! Congratulations!