Challenge Task 2024

Like the previous semester, this semester's Challenge Task (CT) will happen in three stages. 

In the first stage, each group must design and implement an calendar application containing a service that may store user credentials (calendar users) and service-related data. The calendar application should allow you to add new events, edit entries, share events with others and receive notifications. The specific design is free of choice, and simplicity should be a principle to be followed to allow portability using Docker containers.

In the second stage, each group will design and implement security policies and services 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. Security services that impair portability must be avoided (e.g., 2FA).

In the third stage, 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 (at least 8 pages disclosing the defensive and offensive measures - 4 pages each).

This section will be constantly updated with news/reminders throughout the semester.

• XSS Attack slides (PDF, 613 KB)
• DoS Attack slides (PDF, 583 KB)
• SQL Injection slides (PDF, 509 KB)
• Overleaf template (ZIP, 598 KB) for the CT report (intermediate and final) 

Presentation order:

Presentation instructions:

• All groups will present on the 18th/19th of December 2024. Presence is mandatory (CT is an evaluation).
• The target presentation time is 10 minutes per group (5 mins attack, 5 mins defense) and 5 mins Q&A. 
• Organize so each person in the group should present.
• Have your slides ready; we will be switching laptops.

Mutual source code exchange:

The learning objective of this CT is to allow students to 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 CT format fosters students' creativity and ability to use adequate defense and offensive techniques and mechanisms in different environments (Web services) selected by the groups. 

The groups shall inform the teaching assistants on the topic and discuss the proposal's feasibility. 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 complete the CT, assumptions, libraries, tools, and impact on the grade are detailed in the following sections.

A group will have a maximum of 2 (exceptionally 3) 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):

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

• The application must have a frontend, backend, and database. It is possible to use the code of an existing application or build one combining different services. To ensure portability, the core functionality must be implemented and executed entirely in a docker-compose file. 
• 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. The portability of the application should be a top priority.
• The application, all additional security services, and associated configuration files should be executed within the same docker-compose file. Any other configuration file should be automated to ease its deployment.
• Each group will do a penetration test on the application provided by another group. The penetration test should provide documentation specifying its methods, tools, and found vulnerabilities. Groups will be arranged to ensure that all developed Web services have their security mechanisms tested, i.e., all groups will perform attack and defense roles.
• Each group will provide a report of at least 8 pages disclosing its (1) application and security mechanisms and (2) penetration test in another Web service application. Thus, at least 4 pages for (1) and 4 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.
• Each group will provide two talks. One presents its application and security mechanisms, and the second talk presents 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.

This year's CT will be executed in three main stages and different tasks within each stage. The first stage concerns defining and implementing 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.

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] Groups defined: CT 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). 
  • TL;DR: groups defined until  25.09.2024
• [R2] Define application: Groups will define their Calendar application details until the third exercise class (E03). It is possible to either use existing ones or implement the desired service.  
  • TL;DR: application defined until  02.10.2024
• [R3] Application implemented: The Calendar is shown as operational in the fourth exercise class (E04). This deadline is relatively short, considering existing open-source platforms are available and are recommended to be used (see "Starting Points").
  • TL;DR: application implemented/operational until  09.10.2024

Stage 2 - "The Defense"

• [R4] Security services implemented: At 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).
  • TL;DR: security services implemented until 13.11.2024
• [R5] Intermediate report delivered: An intermediate report of 4 pages minimum, including a short description of the Calendar and covering the technical details of the security services, must be delivered by E09. It should also include instructions on deploying the service (i.e., guiding another group in its deployment).
  • TL;DR: intermediate report delivered until 13.11.2024 at 23:59
• [R6] Source-code exchanged: The 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 deploying/operating the received Web service. Confirmation of whether the received service is operational as delivered must be sent until E10 by each group.
  • TL;DR: source-code exchange sorted at 13.11.2024, confirmation sent until E10 20.11.2024.

Stage 3 - "The Offense" 

• [R7] Offensive analysis performed (static and dynamic): The test must be based on a methodology and use offensive tools as presented in L07. The deadline is E13.
  • TL;DR: findings of the security analysis sent until  11.12.2024.
• [R8] Final report delivered: includes the intermediate report and must have a minimum of 8 pages. The final report should also include the findings of the offensive analysis extending the intermediate report. Must be sent until E13.
  • TL;DR: final report, at least 8 pages, by 11.12.2024 at 23:59
• [R9] Talks presented: Two talks must be given. One presents the application and its security mechanisms, and one on the security findings. Talks will be organized so that their overview, defense, and offense are presented in sequence. The deadline is until E13. Presentation dates are in L14 and E14.
  • TL;DR: deadline for the talks is L14. Presentations will happen in E14 (18.12) and L14 (19.12).

The CT's grading will be based on 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. Discussions 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.

If all the requirements above 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 web application should be exposed at ports 80/443 (self-signed certificates) in the localhost. As mentioned, 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 essential 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).

Figure 1 -  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 on 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)

Keywords: self-hosted, open-source, calendar

[1] https://docs.docker.com/get-started/02_our_app/
[2]https://docs.docker.com/get-started/workshop/02_our_app/
[3] https://dockerbyexample.dev/

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