The Postbook Capture The Flag (CTF) is a great security testing exercise. It's an easy level exercise with 7 flags to be found in-order to complete the exercise. Working on this exercise is a good way to learn more about vulnerability exploits and if you get stuck, there are hints on the website to help guide you and should that not suffice, there are also many articles online with pointers on how to find each flag. While working on this exercise I noticed an exploit that was not included but would be fun to add to the flags. Since there are other resources that one could use to find the flags of this exercise, I will not be including the flags but will only focus on the extra exploit in this article found during the testing.
This exploit can be found on the view.php page but to get to it, the exploit will have to be created on the settings page of the application. This is because the settings page of the application is vulnerable to cross site scripting (XSS) attack. So a user of the application can enter javascript code into the username field and this code can be used to exploit a loophole within the application. Specifically, the code can be used to get the login information of other users on the application. To show this exploit, first the basic/simplest test for of XSS will be shown and then that will be built on to create the payload for the extra vulnerability.
So, the first step will be to sign-up on the application and subsequently update the username with an XSS code "<script>alert('Hello')</script>" and save it.
The javascript code in green is the precise code for the exploit but if used only it would not work but the user will get an error message of "Reference Error: $ not defined". To fix this error, a jquery.min.js (the version used for this testing is 2.1.3) will need to be added to resolve this error and let the postbook application understand and render the javascript code. So, once again, we navigate to the settings page and update the username with the new payload. The code saves successfully and payload has been created and inserted into the application.
Now navigate to the home page and click on the post created by the user and observe the alert notification.
To test the effectiveness of this exploit is by verifying that other users of the application will also see the alert popup of the XSS when they login to their own accounts and interact with the post created by this user. Now log-out of the account and create another user and login with that newly created users information to see if the user will see the exploit. The new users information for this test case will be "testing"
On the home page after logging-in to the application, click on the post created by the user with no name in the author area. This is the post created by the user with the javascript exploit as the username of the user. This will be the test to confirm if the XSS work. The confirmation will be the appearing of an alert popup with the page information. True to the hypothesis, clicking on the post shows the alert popup and this confirms that the page is susceptible to the exploit.
This is a cool exploit in the postbook exercise and it will be fun for the testers to go through the process of finding it out. I think the hacker101 site should include this exploit as one of the flags to be found in the exercise. It a nice way to introduce a beginning/learning security engineer the effects of XSS which will in-turn make them better engineers and motivate them to work diligently to prevent XSS vulnerability in their applications. Alright, 'nough said. Back to testing.
