Navigation auf uzh.ch
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 e-commerce application containing a service that may store user credentials (seller or buyer) and service-related data. The e-commerce application should allow sellers to list products with a picture, description, and price. Buyers can then acquire listed products assuming honest or malicious behaviors. Note that no real money/payment service should be used. 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.
Presentation order:
Presentation instructions:
Source code exchange:
ID |
Group |
Sends code to |
1 |
AAAAAAAAA |
Ctrl-Alt-Defeat |
2 |
e10adc3949ba59abbe56e057f20f883e |
alias cd=’rm -rf’ |
3 |
CyberGuardians |
Impenetrable |
4 |
alias cd=’rm -rf’ |
e10adc3949ba59abbe56e057f20f883e |
5 |
Ctrl-Alt-Defeat |
AAAAAAAAA |
6 |
Impenetrable |
CyberGuardians |
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):
# | Group Name | Participants | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | AAAAAAAAA |
Maximilian Huwyler Ülkü Karagöz Vincent Stadler |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ||
2 | e10adc3949ba59abbe56e057f20f883e |
Adam Bauer Dominik Sarman Sandra Rosch |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ||
3 | CyberGuardians |
Han Yang Tomas Mendonca |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ||
4 | alias cd=’rm -rf’ |
Raphael Wäspi Layla Husselman |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ||
5 | Ctrl-Alt-Defeat |
Lucas Krauter Samuel Brügger |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ||
6 | Impenetrable |
Raphael Imfeld Jasmin Hochuli |
✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Portability is a key characteristic that must be ensured in all stages of the CT, meaning that the E-commerce application should be easily deployed and operated on different machines. However, for each CT group, the following key requirements need to be met:
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.
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"
Stage 2 - "The Defense"
Stage 3 - "The Offense"
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).
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?
How many participants are allowed in a group?
Is it possible to use a different platform rather than Docker?
Should we contact a TA only during exercise classes in case we need assistance?
Is it possible to reuse code for my application or security mechanisms?
Our code requires additional/external configuration files, what should we do?
Can we use the time allocated to exercise classes for implementing the CT?
We are lost, what should we do/ask?
Starting point(s)
Keywords: self-hosted, open-source, ecommerce
[1] https://docs.docker.com/get-started/02_our_app/
[2] https://github.com/zinmyoswe/Django-Ecommerce
[3] https://github.com/ikismail/ShoppingCart
[4] https://github.com/christophercliff/flatmarket
[5] https://docs.medusajs.com/create-medusa-app
[6] https://learn.microsoft.com/en-us/visualstudio/docker/tutorials/docker-tutorial
[7] https://www.google.com/search?q=todo+list+docker&oq=todo+list+docker
Reminder: always be extra careful with running non-verified third-party code (such as the application developed by another CT group).