1. CFL Conditions:

You must submit your level to one of the four categories (see below). Your level must be completely new, which means they cannot have been used in other competitions, or have any writeup presently available on the internet. This will be verified by the volunteers. Your challenge must fit the other specifications mentioned below; including other specifications mentioned below, including the uniform flag format, in a CTFd format, and have a write-up in English.

Categories:

1. WEB:

This category should consist of web (HTTP) vulnerabilities (CSRF, XSS, SQLi, SSRF, etc.). The players should NOT be able to find the vulnerability through the use of scanners. If a vulnerability could be found by a scanner, it should be provided in the challenge description. Challenges should be self-contained by infrastructure.

2. SECURE CODING PRACTICES:

This category should be based on either teaching or implementing secure coding practices. Developers should create insecure pieces of code for players to either correct, or learn about a specific secure coding practice, and then best select an answer that best fits that definition. This can be done in many ways, and this new category will leave the creative freedom of that up to the developers. CTFd allows for users to submit code in a language of the CTF designer’s choice OR select multiple-choice options. This category allows the designers the freedom to have users implement a CTF that can either

1.  Teach about secure coding practices in a way you find both unique, and viable.
2.  Correct insecure code in order to retrieve a flag. For example, you have a piece of PHP that allows for SQL injection, and the player must correct that code to prevent an SQL injection.

3. CRYPTO:

This category should consist of either a file or one or more online services (TCP or HTTP) implementing a crypto protocol or weakness that players must exploit by solving a cryptographic challenge. If players simply need to reverse engineer the protocol or algorithm used, the challenge must be submitted to reversing instead.

4. REVERSING:

This category should consist of either a file or one or more online services on which players must reverse engineer a system or binary to discover a flag. This category is not steganography related and does not exploit a vulnerability. Players should be able to extract or deduce the flag without depending on luck. Challenges must test skills related to application security.

Reverse Engineering is a crucial component of most vulnerability research, and tasks in this category should test skills that could be useful in application security. Examples of this include, but are not limited to the type of deo-bfuscation needed when looking for vulnerabilities in closed-source code, working on top of niche or old architectures when doing security research, hardware security research, or even debugging the communication protocol between a JavaScript web application and the server. Note that challenges in this category should not exploit a vulnerability themselves, and are just meant to test the skills of the reverse engineering stage of vulnerability research.

Challenge Submission

• Third-party dependencies should be clearly marked!
• Must be completely novel and never seen before
• Must follow the infrastructure specifications
• Must meet the criteria for one of the 4 categories (web, reversing, secure coding practices, and crypto)
• Must include a README.md file that includes (in English) three sections:        
• Public Challenge Description. What players will see, including hints (if any).
• Secret Design Specification. You may use a slide deck, design document, or similar.
• Full Solution Explanation. Full solution explanation in the form of a CTF write-up.

1. The criteria above will be what the judging panel will use to score the challenge.
2. Must include an exploit and solver that works out of the box
3. Challenge must be solvable in less than 2 days (the CTF lasts longer, but challenges shouldn't take longer than 2 days to solve)

Flag format is ASV{ }. The format within should be strong, often including a mix of letters, numbers, and special characters. An example could be: ASV{Fr0m_3D3N} or ASV{4PP_53C_1s_fun!}, however, the strings can also be random. ASV{452qdT5f^j80pG6}, what is absolutely mandatory is the prefix ASV and the curly brackets { } at the beginning and end.

Must be submitted before the HARD DEADLINE of JULY 19, 2023!