Approaches to test a “hackable website”
Testing how obvious it is that the user should attempt to hack the site: Testing how much of a push in the right direction a player needs to have in order to realize they’re supposed to try to ‘hack’ the website.
Without telling them what the website is, have the players visit the ‘hackable’ test sites in the order of what I believe to be the least obvious to the most obvious. This can be done by just asking the test players to explore the sites.
The order would be something like:
1. Extremely obscure: Seemingly normal autobiographical page of a ‘researcher’ at MIT (completely fictitious but high-fidelity). Have a hidden link be one of the links on the page with a username and password dialogue box appear when they click it. (The means of actually hacking the site can simply be looking at the source code where a plain text reference to the password appears. Since the test is for finding if the user will actually attempt to hack, the difficulty is less important.)
2. Obscure: Seemingly normal autobiographical page of a ‘researcher’ at MIT (completely fictitious but high-fidelity). Have an “administration” link be one of the links on the page with a username and password dialogue box appear when they click it.
3. Moderate: Seemingly normal autobiographical page of a ‘researcher’ at MIT. The researcher writes on the page somewhere that somebody has been changing his page somehow and would be very grateful to find out how they’re doing it.
4. A bit obvious: The researcher explicitly mentions that there are secrets to the website that can be unlocked if the player is good enough to break through the dialogue box.
5. Extremely obvious: The researcher’s page loads as normal, but then changes to appear to be hacked. The ‘hacked’ page then says they’ve found an exploit and intend to discredit the researcher shortly. The researcher pleads for help on any part of the site that he still has control over.
Testing the difficulty of the hacks
Let the players know that the goal is to hack each site. Use a background timer that records how fast they solve each exploit.
Ideas for hacks:
· Javascript password box. The password is somewhere in the source code.
· HTML password box. The password is never set, however, so the password is then just blank. The user hits submit and they can continue.
· HTML password box. Compares the input to a text file somewhere on the server. The user opens the text file and finds the password.
· Include a “Forgot Your Password” link. This should have a hard-coded e-mail that it sends in. The player should download the source code, change the e-mail address, then visit their local file so that the e-mail is sent to their e-mail address.
· Same as before, however check the referrer page so the same trick doesn’t work. Instead the player must use a javascript injection by changing the value of the form using javascript. (This can be done via the address bar or using the Firefox extension: Firebug
· Javascript password dialogue box. The password is in an obscurely named text file on the server. The user then has to use code injection in order to find out the filename.
· Same as before except with PHP.
· Use a cookies exploit. (Change from unauthorized to authorized)
