HackerOne CTF Write-up: Micro-CMS v1

The challenge titled “Micro-CMS v1” is rated as easy difficulty and contains four flags. The challenge provides an introduction to an insecure indexing vulnerability, an (extremely) basic example of SQL injection, and a demonstration of two cross-site scripting vulnerabilities. This challenge helps to drive the point home that submitted forms are not the only user-modifiable fields that can pass data to a server.

At the start of the challenge, the home page contains three click able links. The “Testing” link and the “Markdown Test” link direct the user to /page/1 and /page/2, respectively. The “Create a new page” link directs the user to /page/create. The home page is shown in the image below.

Flag 0 is obtained through an insecure indexing vulnerability that can be discovered through the “Create a new page” functionality of the challenge home page. After following the “Create a new page” link, a new page can be created that shows up alongside the “Testing” page (located at /page/1) and the “Markdown Test” page (located at /page/2) on the home page.

After the first new page has been created, the newly created page is located at /page/7 instead of the more logical location of /page/3.

Because of this, it can be inferred that pages 3 through 6 may already exist on the webserver, but that they are not accessible in the same manner (e.g. by following a link) as pages 1 and 2.

Manually browsing to page indices 3, 4, and 6 return “Not Found” errors while index 5 (/page/5) returns a “Forbidden” error. This “Forbidden” error suggests that page 5 exists, but that the user does not have permission to access the file via /page/5.

Using the newly created page 7 as an example, following the “Edit this page” link directs the user to /page/edit/7. This suggests an alternative method of viewing the contents of any indexed page.

Manually browsing to /page/edit/5 reveals Flag 0.

Flag 1 is obtained after attempting SQL injection via a URL. The importance of this flag is the idea that data can be sent to a server in a variety of (sometimes unintended/unexpected) ways.

Using the “Edit this page” functionality present in the web application as an example, an application developer expects (and hopefully has prepared for) a wide variety of user input being passed to the web server through this form. Since the web developer knows that a user can place any text/characters here that they want, the developer has (once again, hopefully) implemented input sanitization on the contents passed to the web server through this form.

In this case, Flag 1 cannot be triggered through the “Edit this page” form. Perhaps, however, the web application developer has failed to consider that the “Edit this page” form is not the only place that needs its input sanitized.

Browsing to /page/edit/1' (or /page/edit/anything_else', for that matter) triggers Flag 1. The ' character used to trigger the flag could cause a SQL error under normal circumstances.

Flag 2 is obtained after triggering a cross-site scripting vulnerability. The concepts described earlier regarding input sanitization remain true for Flag 2 as the developer of the web application failed to consider all attack vectors.

After following the “Create a new page” link from the web application’s home page or after following the “Edit this page” link after browsing to any created and viewable page, it can be seen that the developer of the website boldly states:

Markdown is supported, but scripts are not

Simply put, script tags can be used in cross-site scripting attacks to execute arbitrary commands and display arbitrary content in a victim’s browser.

The devloper’s assertion is true when it comes to script tags that are included in the main input field of the “Create Page” or the “Edit Page” web pages. Entering <script>alert('XSS')</script> into the main input field of the “Create Page” web page or any “Edit Page” web page results in the <script> and </script> tags being filtered out.

If the script tags were not filtered out and a victim were to visit the newly created page, the JavaScript alert function would execute causing an alert window with the characters “XSS” to be displayed in the victim’s browser.

Another place where user input is dispalyed on the website is on the home page. Text that is included in the “Title” field located on the “Create Page” and the “Edit Page” web pages is displayed on the home page of the website. This means that if the contents of the “Title” field are not sanitized, then cross-site scripting can be achieved.

Flag 2 is displayed in the alert pop up upon visiting the home page.

I know you can see the full flag in the GIF, but whatever…

Flag 3 is obtained through another cross-site scripting vulnerability. This time, the vulnerability is a bit more difficult to find. Flag 3 once again exemplifies the importance of considering the wide variety of ways in which information (and code) can be sent from a browser (client) to a server.

For the previous flag, cross-site scripting was achieved through the classic script tag method which executes JavaScript in the victim’s browser. For Flag 3, the onclick event can be used to achieve this same goal.

Similar to the the way that script tags were used to execute the alert JavaScript function for Flag 2, the onclick event can be used to execute JavaScript when a button (or an image) on a web page is clicked.

The “Markdown Test” page located at /page/2 contains the “Some button” button. Clicking the button does nothing.

From this page, following the “Edit this page” link directs to the page with the Markdown and HTML contents shown in the image below:

Changing <button>Some button</button> to <button onclick=alert('XSS')>Some button</button>, saving the changes, and clicking the “Some button” button will result in a popup with the characters “XSS” being displayed within the browser.

Viewing the page source reveals Flag 3 in the HTML button tag.

This flag can be achieved in the same manner by including <img src='whatever' onclick=alert('XSS')> in the main input field while creating or editing a page, saving the changes, and clicking on the image.