Challenge Task 2022


- CT presentation schedule (R6), to be defined. Five groups will present on day 1 (L14, 21.12), and two will present on day 2 (E14, 22.12).

# Group Day 
1 //TODO: Implement Security  
2 Group 9'; DROP TABLE USERS; --  
3 New security engineers here!  
4 rm -rf malware/  
5 Anonymous  
6 Still in progress  
7 Name_of_your_group 21.12

- Confirm whether the received source-code works. Via e-mail until E10, 24.11.2022.
- Template for the challenge task report is available here (ZIP, 590 KB) (.ZIP file). You can upload it directly to Overleaf.
- Stage 3 - "The Offense": Exchange of source code as in the Table below:

# Group Receive code from
1 //TODO: Implement Security 4 - confirmed
2 Group 9'; DROP TABLE USERS; -- 6 - confirmed
3 New security engineers here! 2 - confirmed
4 rm -rf malware/ 3 - confirmed
5 Anonymous 7 - confirmed
6 Still in progress 1 - confirmed
7 Name_of_your_group 5 - confirmed



This semester's Challenge Task (CT) will happen in three stages. 

In the first stage, each group will have to prepare a simple Web application containing a service that may store user credentials and service-related data. The application will be a Web-based TODO list in which users can define tasks at a future date/time defined by the user interacting with the front end. All data should be stored in a database at the backend, and a user may also be able to retrieve certain tasks that happened in the past. Since the developed application should be straightforward to deploy and operate, groups strongly recommend using Docker and docker-compose to implement the application. 

Example of a simple Web-based TODO list
Example of a simple Web-based TODO list

In the second stage, each group will design and implement security policies and services they deem necessary to protect the application and its users' data. Once again, it is a key requirement that all security services and measures are deployed within the same docker-compose file. 

In the third stage, the groups will exchange their source codes and perform a penetration test on the application to assess the application and data security. Two talks (offensive/defensive) should be presented, and a report should be delivered (6 pages disclosing the defensive and offensive measures - 3 pages each).

The full CT's description is also available in PDF (PDF, 405 KB).

Learning Objectives

The learning objective of this CT is to have students discuss and decide in small groups which theoretical concepts to use in practice, exercising the different aspects of network security (i.e., offensive and defensive security). Thus, this exercise is expected to foster the creativity and ability of students in the use of adequate defense and offensive techniques and mechanisms in different environments (Web services) selected by the groups themselves. 

The groups shall inform the teaching assistants on the topic and discuss the feasibility of the proposal. Each group must hand in their proposal until E03 via e-mail. Even though the groups are free to choose the application to be implemented, all groups must ensure that all requirements are met and follow the defined deadlines. The necessary information to fully accomplish the CT, assumptions, libraries, tools and impact on the grade are detailed in the next sections.


A group will have a maximum of three two participants. Any special cases/requests should be agreed upon with the TA. During the challenge task, each group will be able to ask questions and get support from their supervisor(s):

  • Temporary link to form groups: docs
# Group Name Participants R1.1 R1.2 R3.1 R2 R5.1 R3.2 R4 R5.2 R6

//TODO: Implement Security

Oliver Kamer

Bulin Shaqiri

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      

Group 9'; DROP TABLE USERS; --

Kyrill Hux

Jan Willi

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      

New security engineers here!

Zeen Wang

Stefano Anzolut

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      

rm -rf malware/

Nicolas Huber

Anton Ivashkevich

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      


Ahmad Eynawi

Valery Cortez

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      

Still in progress

Andrea Yachaya

Tobias Frauenfelder

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      


Reto Odoni

Iulia Prozorova

✔️ ✔️ ✔️ ✔️ ✔️ ✔️      


Portability is a key characteristic that must be ensured in all stages of the CT, meaning that the Web-based TODO-list application should be easily deployed and operated on different machines. However, for each CT group, the following key requirements need to be met:

  • [R1] The application must have a frontend, backend, and database. It is possible to use the code of an existing TODO-list application or build one combining different services. The core functionality must be implemented and executed entirely in a docker-compose file to ensure portability. 
  • [R2] At least one security feature should be designed and deployed to protect the application. There is no upper limit on the number of security mechanisms deployed by each group. Important to notice that, due to requirement 4, the portability of the application should be a top priority.
  • [R3] The application, all additional security services, and associated configuration files should be executed within the same docker-compose file. Any additional configuration file should be automated to ease its deployment.
  • [R4] Each group will do a penetration test on the application provided by another group. The penetration test should follow provide documentation specifying its methods, tools, and found vulnerabilities. Groups will be arranged to ensure that all developed Web services will have their security mechanisms tested, i.e., all groups will perform the roles of attack and defense.
  • [R5] Each group will provide a single report of a minimum of 6 pages disclosing its (1) application and security mechanisms and (2) penetration test in another Web service application. Thus, a minimum of 3 pages for (1) and 3 pages for (2). An intermediate report for (1) should be delivered on the date specified below, and the complete report at the final deadline on the presentation date.
  • [R6] Each group will provide two talks. One presenting its application and security mechanisms, and a second talk presenting the penetration test. Talks will be organized by Web application, i.e., Group A: Application 1 functioning and security mechanisms, Group B: Application 1 penetration test. Group B: Application 2 functioning and security mechanisms, Group A: Application 2 penetration test.

Organization and Deadlines

This year's CT will be executed in three main stages and different tasks within each stage. The first stage concerns the definition and implementation of a Web service; stage 2 is the addition of protection services, mechanisms, and policies; and stage 3 is the penetration test. Figure 2 illustrates the main stages.

CT Stages
Figure 2 - Challenge Task Stages

Clarification: Deadlines consider until 23:59 of the day given in the description (and not the day before. Thus, it is possible to use exercise lectures to discuss (and remind) the necessary details.

Stage 1 - "The Service"

  • R1.1 - Groups definedCT will be presented in the first exercise class (E01) and students will have to form groups (limited to a maximum of three participants) sending a confirmation via e-mail until the second exercise class (E02). Special cases or requests should be confirmed with the TA. 
    • Note: The number of students in each group will be defined based on the number of students enrolled in the course, being released in E01.
    • Deadline: until E02, 29.09.2022.
  • R1.2 - Define Web servicegroups will define the details of their Web TODO-list application until the third exercise class (E03). It is possible to either use existing ones or implement the desired service. 
    • Note: The choice of additional services will be checked by the TA to avoid the use of an application that already has security features ``out-of-the-box", thus, defeating the purpose of the CT. 
    • Deadline: until E03, 06.10.2022. 
  • R3.1 - Application implementedservice is shown operational until/at the fourth exercise class (E04).
    • Note: Considering that basic already available TODO-list applications can (and are recommended) be used, the deadline is relatively short. Exceptions can be discussed with the TA. 
    • Deadline: until/at E04, 13.10.2022.

Stage 2 - "The Defense"

  • R2 - Security services implementedat least one additional security service(s), mechanism(s), and/or policy(-ies) are added to the Web service. Hand-in of the prototype until the ninth exercise class (E09).
    • Deadline: until E09, 17.11.2022.
  • R5.1 - Intermediate report delivered: an intermediate report of 3 pages minimum including a short description of the Web service and covering the technical details of the security services must be delivered until E08. It should also include instructions on how to deploy the service (i.e., guiding another group in its deployment).
    • Deadline: until E09, 17.11.2022.
  • R3.2 - Web service exchangedthe exchange (i.e., defining which group will analyze which Web service) will be done by the TA at E09.
    • Note: Groups will have one week to report any issue in deploying/operating the received Web service. Confirmation of whether the received service is operational as delivered must be sent until E09 by each group.
    • Deadline: exchange at E09 17.11.2022. Confirmation sent until E10, 24.11.2022.

Stage 3 - "The Offense" 

  • R4 - Penetration test performedthe test must be based on a methodology and make use of offensive tools as presented in L07. 
    • Deadline: until E13, 15.12.2022.
  • R5.2 - Final report delivered: includes the intermediate report and must have a minimum of 6 pages. The final report should also include the findings of the penetration test.
    • Deadline: until E13, 15.12.2022.
  • R6 - Talks presentedtwo talks must be given. One presents the Web service and its security, and one on the penetration test findings. Talks will be organized per Web service in a way that their overview, defense, and offense are presented together.
    • Note: There will be two presentation dates: L14 (21.12.2022) and E14 (22.12.2022).
    • Deadline: until or at E14, 22.12.2022.

Deadlines and Grading Criteria

The CT's grading will be based on a combination of objective and subjective criteria. While objective criteria are the basis to check whether groups have achieved or not the minimum requirements (and within their deadlines), subjective criteria are used to assess how well these requirements have been implemented. A discussion between the professor and TAs will define the subjective criteria based on a qualitative assessment of the group's work based on the produced/delivered code, reports, and talks. Deadlines are based on exercise classes (e.g., E02, E03, check here), and involve the requirements defined in Sections 3 and 4. Deadlines for the minimum requirements are defined as follows (cf., Figure 3):

Challenge Task Deadlines
Figure 3 - Challenge Task Deadlines
  • E02: 29.09.2022. Requirement R1.1 must be delivered until E02.
  • E03: 06.10.2022. Requirement R1.2 must be delivered until E03.
  • E04: 13.10.2022. Requirement R3.1 must be until or at E04.
  • E09: 17.11.2022. Requirements R2, R5.1, and R3.2, in which both R2 and R5.1 must be delivered until E09.
  • E10: 24.11.2022. Confirmation for requirement R3.2 is needed until E10.
  • E13: 15.12.2022. Requirements R4 and R5.2. Both R4 and R5.2 must be delivered until E13.
  • E14: 22.12.2022. Requirement R6 must be delivered until or at E14.

Thus, if all the aforementioned requirements are met on their specified deadlines, a group is approved with a minimum grade on the CT (i.e., 4.0). A subjective evaluation by the course TAs and professor will adjust the grading based on the quality of the code, report, and talks.

Reference Architecture 

An overview of architectural components is given in Figure 1. The application should be exposed at ports 80 (443 preferably) in the localhost. As mentioned in the requirements, it is possible and recommended to use existing applications as a basis to develop and deploy its security mechanisms. That would allow groups to get familiar with the syntax and functioning of the application.

Additional security services and mechanisms can be freely chosen and adapted to application design. For example, it is possible to harden the security of a backend/frontend while adding additional security services (i.e., containers) such as firewall, authentication, intrusion detection system, and others. It is important that all security services are declared within the same docker-compose file and any additional configuration file shared between the localhost and containers, is also provided. Figure 1 shows a basic reference configuration serving as a starting point for each group to implement its own Web service and security mechanism(s).

Web service reference architecture
Figure 1 - TODO-list Webservice - Reference Architecture

It is also important to note that security should be improved as much as possible without sacrificing portability. The use of any additional security service that impairs its straightforward deployment and operation should be avoided. For example, adding a two-factor authentication that requires the use of external tokens or sending SMS. Given the CT goals where each group should play both the defensive and offensive roles, it is key that the developed application can be easily deployed in different machines. As such, any additional configuration should be automated (e.g., Python/bash script).


I found a mistake in the description, what should I do?

  • Please, get in contact with the TA as soon as possible. Although the TA improved over time, this description may contain inconsistencies.

How many participants are allowed in a group?

  • Help me to help you, read the description. Anyhow, the maximum defined (HS22) is 3 participants. 

Is it possible to use a different platform rather than Docker?

  • It is key for the CT to have easy portable/deployable Web services (prototypes will be exchanged between groups). If this requirement can be maintained in your proposal, please contact the TA to discuss the proposal.

Should we contact a TA only during exercise classes in case we need assistance?

  • Nope, send an e-mail as soon as possible. If the question cannot be answered via e-mail, it is possible to schedule a meeting online/on-site.

Is it possible to reuse code for my application or security mechanisms?

  • Not only possible but recommended. Do note that it may not be allowed to use an application already containing several security mechanisms/protections (as this will defeat the purpose of the CT).

Our code requires additional/external configuration files, what should we do?

  • Automate the application configuration using scripts. These scripts should be provided with instructions to execute along the source code. Remember that another group will deploy your code and it is key that it works.

Can we use the time allocated to exercise classes for implementing the CT?

  • Yes, whenever it is possible, i.e., assuming there is available time after exercise solutions are discussed. Otherwise, it is recommended to use homework times to work on the CT.

We are lost, what should we do/ask? 

  • First, discuss within your group what are the possibilities, scenarios, outcomes, risks, benefits, externalities, and whatnot. If this is not helpful, ask the TA for directions. Second, thinking "what should we do/ask?" is already a question, so that is something positive to remember. The third point and perhaps the most helpful one, a "starting point" is available below. Remember that the CT goal is to practice "defensive" and "offensive" security and not to provide a "product-level" application. Have fun!

Starting point(s)


Reminder: always be extra careful with running non-verified third-party code (such as the application developed by another CT group).