sopel / ctf-in-a-box Goto Github PK

This task details #2.

This task details #1; the README should explain the origin, vision and goals of this project, crediting Stripe for their great competition and especially the levels provided, yet clarify/distinguish the restricted use case at hand.

The current level design adjustments gravitate towards an explicit or implicit API for seeding the secret after deployment. All levels other than the PHP based ones 1 and 2 are already or going to be accepting a POST payload content-type application/json for this purpose. To provide/promote a respectively consistent user experience and level design, handling these ubiquitous JSON payloads should be added to the PHP levels as well accordingly (likely the HTML form should be dropped thereafter, as there doesn't seem to be a point maintaining an in place UI for standalone level usage).

Given levels 1 and 2 can be seeded just fine with a POST payload content-type application/x-www-form-urlencoded already, this is of low priority only.

This task details #2.

This task details #2.

This story details #1; it covers any adjustments to allow hosting each level as a Cloud Foundry app ideally; whether this will actually be possible remains to be seen, but an initial analysis yields positive expectations.

Every level is going to be handled via a dedicated issue to allow collaboration via the respective pull request.

The required steps per level are:

1. Make it run on Cloud Foundry (covers the technical aspects of the hosting environment)
2. Make it functional and secure on Cloud Foundry (covers the aspect of being exploitable in the desired way, and not via other means; obviously this doesn't need to be handled too strict given the restricted use case, i.e. any other exploit discovered by participants might actually yield a new level ;)
3. Make it customizable per user (covers injecting the secret per level, but not the provisioning of a level ensemble)

This task details #2; given the restricted use case, the minimum viable solution requires just each level to be deployable as an app to Cloud Foundry by each participant on its own, which could be orchestrated via a wiki based walk through the story and the levels.

Given the exploits are detailed on various sites all over the web already, they might as well be summarized here as well, be it directly or via respective references. Obviously some smarts should be applied to keep people from spoiling the experience too easily.

This task details #2.

This task details #2.

This task details #2.

This story details #1 and depends on #3; it covers an increased user experience by providing a fancy UI for orchestrating the levels in order to provide a more engaging user experience. The Stripe CTF incarnation has been very appealing, which certainly helped to make their competition such a great success.

This story does not cover a leaderboard though, which would add a completely new tier to this otherwise self contained hosting approach and will be handled via a separate issue in case.

This task details #2.

This epic covers the envisioned use case and mid term goal; more details and a specification are going to be added via subsequent issues.

This story details #1; it covers provisioning an ensemble of levels for a particular participant, i.e. providing the required coordinated set of secrets to proceed from level to level.

Accordingly the secrets are likely going to be created and managed implicitly via this app, a simple in memory key/value or JSON representation should be entirely sufficient for the use case at hand.

Ideally the subsequent levels can be provisioned on demand, i.e. the respective levels app deployed via this one as soon as the password is available, and the captured levels be stopped eventually.

This story does not cover a fancy UI though (if one at all).

This task details #2.

This task details #2.

All levels other than the PHP based ones 1 and 2 can conveniently be run standalone by means of the respective runtime's built-in web servers. Apparently PHP finally offers such a Built-in web server as well as of version 5.4 , which should be tested/integrated for a consistent user experience accordingly.

Given levels 1 and 2 are working as expected already and can be hosted via the usually available local LAMP stack as well, this is of low priority only.