Micro-CMS v1
The challenge consistes of a simple markdown-based CMS, with the functionality to create and edit markdown files. When opening a page, the first thing of note is that the URL syntax is along the lines of /page/1, where 1 is the ID of the page. This is a good indication that the pages are stored in a database, and that the ID is the primary key.
The two pre-populated pages are 1 and 2, but the first page I created had the ID of 9. Exploring the numbers in-between, I found that most pages gave the standard openresty/1.21.4.1 404 response, but page 7 gave a 403 forbidden response. This indicates that there is likely some form of user-based access control in place, although with no obvious method of discerning users I'm not sure how this would be the case.
The /page route is not a file, so it simply returns a 404 error. WHen editing a page, the URL path is like /page/edit/1, and the edit route is also unavailable. When submitting from the edit page, a POST request is sent to the same endpoint on the server containing the contents of the form (with a 302 response), then another GET request is sent for the contents of the page. The POST request has title and body fields in the payload, which are just the serialized contents of the form. I'm guessing that these are written to a file, and then the page is rendered from the file.
Maybe if we intercept the POST request to the server and change the endpoint to 7 we will be able to view the 7 page; however, this could have the adverse side effect of possibly overwriting the contents of the file, which would not be good because that is likely where the flag is stored. This was actually overkill, and once I did it I realized that I can accesss the page via the /page/edit/7 route.
The contents were as follows:
My secret is ^FLAG^a5e96d719c80f33351442cb984c506299e5d013d7501c8a70d9ca81a628f5794$FLAG$
This was the first of four flags.