CYS401 · Project Report
Prince Sultan University · College of Computer and Information Sciences · CYS401: Fundamentals of Cybersecurity
←→ move between slides · Present shows the short version for the 10-minute talk
01
Section 1
Cybersecurity education entails the use of practical exercises to reinforce theoretical concepts. The CTF events are great tools in helping the learners go through realistic situations, find weaknesses, and solve security problems in order to collect flags which develop important critical thinking and technical skills.
1 · The platform
This paper discusses a Mini Capture-The-Flag (CTF) Security Lab Platform which has been created to offer guided challenges in technical and non-technical areas. The platform provides a user-friendly graphical interface—avoiding any complexities of command lines—and offers guided challenges in four key areas:
Track 01
Web Security
Open workshop →
Track 02
Cryptography
Open workshop →
Track 03
Security Awareness
Open workshop →
Track 04
Cybersecurity Ethics
Open workshop →
Users go through different security situations to obtain and upload challenge flags such as insecure configurations, password security, phishing, and simple ciphers. The major purpose of this platform is to offer a safe environment for educational activities and connecting cybersecurity theory with practical experiences.
1 · Key functionalities
01
Processes and validates entered flags based on cryptographic hashes stored in the system.
02
Provides unlockable hints when attempting and post-solution explanations after solving challenges in order to learn the basic security principles.
03
Computes earned scores in real-time and manages participant states of completing challenges on a live leaderboard.
04
Ensures security of the application through password salting, input validation, and session-based access controls in order to prevent SQL injections and flag exposures.
This report presents the security background and risks, current CTF solutions, system design and implementation, testing outcomes, and security recommendations for the project.
02
Section 2
What needs protection in the CTF platform, the risks that threaten it, the flaws that could be exploited, and the attacks most relevant to its functionality.
2.1 · Assets
Individual accounts used to identify users and associate their activity with the platform.
Security importance
Accounts must be protected from unauthorized access and impersonation to ensure that activity and progress are associated with the correct user.
Authentication information used to verify the identity of users when accessing their accounts.
Security importance
Credentials must remain confidential to prevent account compromise and unauthorized access to the platform.
Secret values that users must discover and submit to successfully complete CTF challenges.
Security importance
Flags must remain confidential until legitimately discovered. Exposure of flags would allow users to bypass the challenge and undermine the integrity of the CTF.
Security scenarios, instructions, hints, resources, and educational explanations provided for each challenge.
Security importance
Content must maintain its integrity so that challenges remain accurate, functional, and consistent with their intended learning objectives.
Records of challenges attempted and completed by each user.
Security importance
Progress data must remain accurate and protected from unauthorized modification to ensure that users receive the correct completion status.
Information used to represent participant scores, completed challenges, and rankings.
Security importance
Scoreboard data must maintain its integrity to prevent manipulation of scores or rankings and ensure fair results.
Underpins every asset
The underlying data storage used by the platform to maintain user, challenge, progress, and other application data.
Security importance
Unauthorized access, modification, or loss of database information could compromise the confidentiality, integrity, and availability of multiple platform assets.
2.2 · Security Risks and Threats
CTF Security Lab might have to face some security risks that can threaten users, content, the evaluation system, and even data within the platform. Recognizing such security risks is crucial in order to come up with the right security controls for the platform and its data.
T1
An unauthorized individual may attempt to gain access to another user’s account or restricted areas of the platform.
Potential impactAccount compromise, exposure of protected information, or unauthorized changes to user data and progress.
T2
User authentication information may be obtained through methods such as phishing or other credential-stealing techniques.
Potential impactAn attacker could impersonate a legitimate user and gain unauthorized access to the user’s account.
T3
Challenge flags may be exposed to users without requiring them to legitimately solve the associated challenge.
Potential impactUsers could submit exposed flags without completing the challenges, reducing the fairness and educational value of the platform.
T4
An unauthorized user may attempt to alter stored information such as challenge completion records, scores, or challenge content.
Potential impactIncorrect progress records, unfair scoreboard rankings, altered challenges, and loss of data integrity.
T5
Platform data or services may become unavailable because of system failure, accidental deletion, or disruption.
Potential impactUsers may be unable to access the platform, and stored progress or other information could be lost.
T6
Users may intentionally provide unexpected or malicious input through platform fields such as flag submissions or account-related forms.
Potential impactImproperly handled input could affect application behavior, stored data, or platform security.
2.3 · Vulnerabilities
A vulnerability refers to a flaw in a system that can be exploited by an attack resulting in harm. Vulnerabilities in the CTF Security Lab can range from those associated with authentication, input processing, access control, data protection, to system configuration. Recognizing such vulnerabilities helps in instituting security measures that prevent exploitation of such flaws.
Weak authentication mechanisms may allow unauthorized individuals to gain access to user accounts and impersonate legitimate users.
Failure to properly validate or sanitize user input may allow malicious or unexpected input to affect application behavior or stored data.
Users may be able to access or modify information or functionality that should be restricted to other users or administrators.
If challenge flags are exposed or stored insecurely, users may retrieve them without solving the intended challenges.
Improper protection of stored data may expose user information, progress records, challenge information, or other application data to unauthorized parties.
Incorrect permissions, exposed configuration information, or insecure settings may unintentionally expose sensitive information or functionality.
2.4 · Potential Attacks
The identified vulnerabilities could be exploited through several attacks against the CTF Security Lab. These attacks may compromise the confidentiality, integrity, or availability of platform assets. The following attacks are particularly relevant to the functionality of the proposed system.
CIA principle at risk
| Attack | C | I | A |
|---|---|---|---|
| Brute-force login | ●Yes | ●Yes | ○No |
| Injection | ●Yes | ●Yes | ○No |
| Broken access control | ●Yes | ●Yes | ○No |
| Denial-of-service | ○No | ○No | ●Yes |
Target
Authentication System
Repeated automated login attempts leading to unauthorized account access and user impersonation.
Target
Input Fields & Database
Submitting malicious input via form fields to manipulate data, bypass application logic, or leak stored data.
Target
Progress & Score Data
Exploiting authorization flaws to access restricted resources, modify user scores, or alter challenge content.
Target
App & Hosting Infrastructure
Flooding the server with excessive requests to consume resources and cause platform slowness or downtime.
03
Section 3
How CTF fits into cybersecurity education, how three established platforms teach it, how they compare with ours, and three real incidents from the Gulf region that shaped our attack analysis.
3.1 · Capture-the-Flag in Cybersecurity Education
Capture-The-Flag (CTF) challenges engage learners in solving practical cybersecurity tasks to retrieve hidden flags. CTF events generally follow an Attack-Defense structure or a Jeopardy-style format that organizes standalone challenges by category.
Standalone challenges organized by category. The proposed platform uses a Jeopardy-style structure so beginner-level users can complete guided exercises independently.
The other common structure for CTF events.
Švábenský et al. (2021)
While CTF activities effectively build technical skills, traditional platforms often neglect human-centric topics like social engineering and security awareness. Additionally, steep technical requirements frequently deter beginners.
How our lab responds
The Mini CTF Security Lab addresses these limitations by providing a balanced, accessible curriculum that combines technical and non-technical topics.
3.2 · Existing and Previous Solutions
Several established platforms demonstrate how CTF activities teach cybersecurity.
Carnegie Mellon University
Created by Carnegie Mellon University, it offers interactive challenges and a practice gym (picoGym).
Open-source management platform
An open-source management platform providing flag validation, scoring, and customizable hosting.
Limitation
While functional for hosting events, it includes no built-in educational content, leaving challenge creation entirely to organizers.
docs.ctfd.io ↗Wargames
Offers technical wargames (e.g., Bandit, Natas) arranged in sequential levels.
Limitation
While effective for hands-on learning, its heavy reliance on command-line tools creates a steep learning curve for novices.
overthewire.org/wargames ↗Our platform In contrast to these existing solutions, the proposed Mini CTF Security Lab delivers a lightweight, web-based graphical interface with pre-built, guided challenges—eliminating command-line friction and complex platform setup.
3.3 · Comparison of Existing Approaches
| Feature | picoCTF | CTFd | OverTheWire | Our Platform |
|---|---|---|---|---|
| Web Challenges | Yes (Web Exploitation) | Depends on organizer | Yes (Natas) | Yes |
| Cryptography | Yes | Depends on organizer | Yes (Krypton) | Yes |
| Awareness | No dedicated category | Depends on organizer | No | Yes |
| Ethics | No | Depends on organizer | No | Yes |
| Flag Validation | Automated | Automated (static and regex flags) | No flag submission; each level’s password unlocks the next level | Automated, using hashed flags |
| Hints | Yes | Yes (free or cost points) | No built-in hints | Yes, free |
| Progress Tracking | Yes (picoGym) | Yes | No | Yes |
| Scoreboard | Yes (during competitions) | Yes | No | Yes |
Existing platforms like CTFd, OverTheWire, and picoCTF focus exclusively on technical skills, requiring custom content, command-line setup, or lacking hints (CTFd LLC, n.d.; OverTheWire, n.d.; Carnegie Mellon University, n.d.). Our browser-based lab addresses this gap by offering non-punitive hints, post-solution explanations, and dedicated Security Awareness and Ethics tracks (Švábenský et al., 2021).
3.4 · Related Security Incident · 1 of 3
We selected three incidents from the Gulf region, each linked to one of the attacks described in Section 2.4.
What happened
About 1.4 GB of internal files and customer records from Qatar National Bank were published online in April 2016. The leak exposed more than 100,000 accounts, including passwords and PINs (Have I Been Pwned, 2016; Al Jazeera, 2016).
Impact
Customers’ personal and financial data were exposed publicly, and the breach went undetected for about nine months.
Relevance to this project
Our flag submission and login forms accept user input that reaches the database. This incident shows why the platform must validate input and never build database queries from raw user input. It relates to the Injection Attack in Section 2.4.
3.4 · Related Security Incident · 2 of 3
What happened
Careem, a Dubai-based ride-hailing company, announced that attackers had gained unauthorized access to the system it uses to store customer and driver data. About 14 million users across the Middle East were affected (Arab News, 2018; Tom’s Hardware, 2018).
Impact
Names, email addresses, phone numbers, and trip data were exposed. Careem hired a cybersecurity firm to investigate and advised users to change their passwords (Gulf News, 2018).
Relevance to this project
Our database stores user accounts, progress, and scores. This incident shows the need for strict access control on stored data, and for storing passwords and flags in protected or hashed form so that a leak does not reveal usable secrets. It relates to Broken Access Control in Section 2.4.
3.4 · Related Security Incident · 3 of 3
What happened
Several Saudi government websites, including the Ministry of Interior’s site, were disabled by coordinated attacks traced to hundreds of IP addresses in several countries. The Ministry of Interior website crashed after receiving a very large number of requests and was restored in less than two hours (Al Jazeera, 2013; Gulf News, 2013).
Impact
Government services were unavailable to the public during the attack.
Relevance to this project
If an attacker floods our login or flag submission path, students lose access during a lab session. This supports request limits on submissions. It relates to the Denial-of-Service Attack in Section 2.4.
04
Section 4
What the system shall do, and the four challenge categories it delivers.
4.1 · Functional Requirements
FR-01
The system shall allow users to register an account, securely log in using username/password, and manage active sessions.
FR-02
The system shall display all available challenges categorized by domain (Web, Cryptography, Awareness, Ethics) alongside their difficulty levels and point values.
FR-03
The system shall display scenario descriptions, target environment details, instructions, and flag submission fields upon selecting a challenge.
FR-04
The system shall accept flag inputs, evaluate them against stored secret hashes, and display immediate visual confirmation (Success / Incorrect).
FR-05
The system shall provide unlockable hints during challenge attempts and reveal detailed post-completion explanations reinforcing cybersecurity principles.
FR-06
The system shall track individual user progress, recorded solved challenges, completion percentages, and timestamps.
FR-07
The system shall compute total points earned by each user and maintain an updated public scoreboard ranking all participants.
FR-08
The system shall enforce role-based access control (User vs. Admin) to restrict challenge editing and administrative configurations to authorized users.
4.2 · Challenge Categories
4
challenges
Identify common web application vulnerabilities.
2
challenges
Recognize weak encryption and decoding techniques.
2
challenges
Recognize online security risks and prevent safe cyber hygiene failures.
2
challenges
Understand responsible disclosure and ethical security testing boundaries.
05
Section 5
5.1 · Hardware Requirements
Computer
Standard PC / Laptop
Windows, macOS, or Linux
Enables participants to access the CTF platform via a web browser and allows team members to develop and maintain the application.
Processor
Dual-Core CPU
Intel Core i3/i5, AMD Ryzen 3/5, or equivalent
Ensures smooth rendering of web pages, execution of client-side JavaScript, and use of browser developer inspection tools.
RAM
4 GB minimum
8 GB recommended
Handles modern web browser processes, multiple active challenge tabs, and developer tools without performance degradation.
Internet Connection
Broadband Wi-Fi / Ethernet
Minimum 2–5 Mbps
Provides stable connectivity to communicate with the cloud-hosted server (shoug-tech.com), submit flags, and sync scoreboard data in real time.
5.2 · Software Requirements
Frontend
All 20 pages are static HTML styled with Tailwind utility
classes; no framework and no build step. Shared header/footer,
the challenge cards, and the guided tour are plain JS modules
(assets/js/).
Backend
There is no custom server. Email/password accounts run on
Firebase Auth, and
firestore.rules
does the server-side work: it SHA-256 hashes each submitted
flag and compares it against the stored hash, enforces exact
point awards, one solve per challenge, the 5-second
anti-brute-force throttle, and user/admin roles.
Database
Users, roles, solves, scores, attempt log, and the hidden
flagHashes
collection that no client can read. Firebase JS SDK 10.14.1,
loaded from gstatic.
Hosting
The workflow checks internal links, assembles the site, and
publishes to Pages on every push to
main. Served at
ctf-lab.shoug-tech.com over HTTPS.
Tooling
IDE plus Prettier formatting on save, and the Firebase CLI
emulators for local testing. Version control on
github.com/Shoug-Alomran/cys401;
.gitignore keeps
the private flag and answer files out of the repo.
5.3 · User Interface
5.3.1
The home page introduces the platform, displays live lab statistics (12 challenges across 4 tracks), and guides users on how to participate.
Open the home page →5.3.2
The dashboard allows users to view their personalized statistics, including total points, current rank, category progress bars, and recent submission logs.
Open the dashboard →5.3.3
The challenges page lists all available CTF tasks organized across the four security tracks, displaying their difficulty ratings, point values, and solve status.
Open the challenges page →5.3.4
The challenge details page provides participants with the track scenario, objective, difficulty rating, point value, and flag format guidelines before starting a task.
Open a track’s challenges →5.3.5
The flag submission interface processes participant inputs, displaying error feedback and non-punitive hints on incorrect attempts, and revealing earned points, flags, and post-solution explanations upon successful validation.
Open a lab →5.3.6
The scoreboard section displays a real-time dynamic leaderboard ranking all participants by total points earned, while tracking individual completion rates and solution histories across all four security tracks.
Open the scoreboard →5.4 · Challenge Implementation
Scenario & execution
Participants navigate to the club login page, which displays a prompt to enter an invitation code.
Inspection: The participant opens browser developer tools to inspect the webpage’s HTML source code.
Discovery: They discover an unstripped developer comment containing the invitation code:
<!-- Secret club invitation code: •••••••• -->
Authentication: Entering the code into the invitation code field unlocks the secret message and reveals the flag.
Completion: The participant submits the flag to the CTF platform to earn 100 points.
The code and flag are hidden on this page so the challenge stays unsolved. Try the lab →
Educational outcome: Teaches participants to inspect HTML source code to identify client-side information disclosure vulnerabilities, reinforcing the critical principle that credentials, access codes, and API keys must never be hardcoded or stored in front-end code.
5.5 · Flag Validation
Challenge (CTF) flags will be stored securely on the server as cryptographic hashes to prevent participants from viewing the original flags in the website’s source code.
When a participant submits a flag, the server identifies the challenge, normalizes the input, hashes the submitted flag, and compares it with the stored hash.
If the flag is correct, the system records the completion and awards 100 points. If it is incorrect, the system displays an error message and awards no points.
After a correct submission, the system displays a success message and updates the participant’s score.
The system checks whether the participant has already completed the challenge. If so, it confirms the existing completion without awarding additional points. A database uniqueness constraint prevents duplicate completion records.
5.6 · Progress Tracking and Scoreboard
The platform dynamically calculates user progress and updates leaderboard rankings in real time.
01
Each challenge awards a fixed point value. Points are added to the user’s total score upon successful flag validation.
02
The system keeps track of solved challenges by each account and determines their percentage completion both globally and per track (number of solved challenges out of 12).
03
The real-time ranking on the scoreboard is done in decreasing order of total points and then using the earliest time stamp of their last correct flag submission.
5.7 · Hints and Explanations
Hints and scoring
Users can make use of hints using the “Show Hint” option. To facilitate the learning process for beginners, the use of hints will incur no penalty on scores.
Explanation after a successful solve
After submitting the right flag, users are provided with an explanation of the vulnerability being exploited and how to prevent such vulnerabilities.
Case example · The Secret Cyber Clubhouse
Hint
“Sometimes, the cutest secrets are hidden where your eyes can’t see them. Have you checked behind the webpage?”
Post-solution explanation
“The invitation code was stored in an HTML comment within the webpage source code. HTML comments are publicly readable and must never contain credentials or sensitive parameters. Confidential data should remain server-side under proper access control measures.”
Educational effectiveness: The combination of non-punitive clues and post-solution summaries helps promote problem solving along with the secure coding principles.
Live demonstration
06
Section 6
How the platform applies the CIA triad, how it identifies, authenticates, and authorizes users, and the controls mapped to every threat from Section 2.
6.1 · CIA Triad
C
Flags, passwords, and each user’s private records (profile, solves, attempts) must stay hidden from other users.
Controls
Flags are stored only as SHA-256 hashes in a database collection that no user can read. Passwords are handled by Firebase Authentication and are not stored in our database. Each user can read only their own profile, solves, and attempts; admins can read all.
I
Scores, solves, and challenge content must change only through legitimate actions.
Controls
A score can increase only by the points of a challenge solved in the same transaction. Each challenge can be scored once per user. Solve and attempt records cannot be edited or deleted. Only admins can change challenges and flag hashes. Timestamps are set by the server, not the browser.
A
Students must be able to reach challenges and submit flags during lab sessions.
Controls
The website is static and hosted on GitHub Pages, and data is stored on Firebase’s managed infrastructure. Each user can submit at most one flag every 5 seconds, which limits flooding through the submission path.
6.2 · Authentication and Authorization
The platform follows five principles of AAA for access control.
01
User registration through a unique email address, a case-insensitive username (3–20 characters including letters, numbers, and underscore), and an auto-generated Firebase UID.
02
Uses Firebase email/password authentication with email verification and re-authentication for important activities within the account. Also includes a 30-minute session timeout.
03
Provides Role-Based Access Control where users have two roles, User and Admin. Administrators perform management actions like management of challenges, flag hashes, and system logs through server-side Firestore security rules, not through hiding of UI elements.
04
Logs are automatically created with user ID, challenge ID, value submitted, correctness of the input, hint usage, and server timestamp. Server-side validation is done to avoid fake completion.
05
All submission and hint logs are immutable and associated with the user ID and server timestamps for auditing purposes (e.g. flag sharing, brute forcing). Logs remain available even after the user account is deleted.
6.3 · Security Controls
The controls below map the threats and vulnerabilities from Sections 2.2 to 2.4 to the controls implemented in the platform. Control types follow the course classification (preventive and detective).
Firebase Authentication blocks sign-in temporarily after repeated failures (“too many requests”). Passwords must be at least 8 characters.
A server rule allows one submission per user every 5 seconds.
Flags are stored only as SHA-256 hashes in a collection no user can read. Pages do not contain plain flags.
The database is Firestore (NoSQL), accessed through its SDK, so no SQL statements are built from user input. Server rules check input type and length (flags up to 200 characters, usernames by pattern). Usernames are HTML-escaped before display to prevent cross-site scripting.
Server rules let users read and change only their own records. Role is fixed to “user” at sign-up. Only admins can write challenges and flags.
A score update is accepted only with a new, valid solve in the same transaction. Each challenge scores once per user.
Automatic logout after 30 minutes of inactivity; current password required for sensitive account changes.
Attempts and hints are logged with server timestamps and cannot be edited or deleted. Admins can review them.
Automated tests check the security rules (for example, “nobody can read flag hashes” and “a user cannot promote themselves to admin”).
All controls are technical.
07
Section 7
We tested the main features on the live platform: login, challenges, flag validation, an invalid flag, the dashboard, and the scoreboard.
6 / 6
tests passed
0
issues found
7.1 · Test Cases
| ID | Feature | Test | Expected | Actual | Status |
|---|---|---|---|---|---|
| T01 | Login | Log in with a valid email and password. | The user logs in. | The website displayed the user’s account after login. | Pass |
| T02 | Challenge | Open a Web Security challenge. | The challenge instructions are displayed correctly. | The lab opened and displayed the challenge instructions and input fields. | Pass |
| T03 | Flag validation | Submit the correct flag for WEB-01. | The flag is accepted and 50 points are awarded. | The flag was accepted, WEB-01 was marked as solved, and 50 points were awarded. | Pass |
| T04 | Invalid flag | Submit an incorrect flag for WEB-02. | The flag is rejected and no points are awarded. | An incorrect-flag message was shown, and WEB-02 stayed unsolved. | Pass |
| T05 | Dashboard | Complete a challenge and check the user dashboard. | The dashboard updates the number of solved challenges and earned points. | The dashboard displayed 1 out of 12 solved challenges and 50 out of 1200 points. WEB-01 was also listed as completed. | Pass |
| T06 | Scoreboard | View the scoreboard after completing a challenge. | The scoreboard updates to show the new points and ranking. | The scoreboard reflected the updated score and ranking for the user. | Pass |
The CTF platform functions properly for the primary features, according to the testing. The user received 50 points after the system recognized the correct flag. Additionally, it rejected an incorrect flag, leaving the challenge unresolved. The dashboard displayed one of the twelve challenges that had been completed and updated the user’s progress. The correct points and user ranking were also shown on the scoreboard. During these tested features, no issues were discovered.
08
Section 8
Where the platform can be used, who it is for, and four changes that would make it more secure.
8.1 · Practical Application
Where it can be used
The platform can be used in introductory courses such as CYS401, where an instructor assigns one workshop and its challenges alongside each lecture topic. Student clubs can use it for training days or a small campus CTF, since the scoreboard turns the challenges into a light competition. It can also support awareness sessions for first-year students or non-technical staff, because the Security Awareness and Ethics tracks require no programming.
Who it is for
The main users are university students and beginners with no CTF experience. Everything runs in a web browser, so users do not need to install Linux or use a command line.
What participants practise
Skills from all four tracks: inspecting web pages for exposed information and understanding web vulnerabilities, decoding simple encodings and ciphers, recognizing phishing and weak passwords, and deciding what is authorized and how to disclose vulnerabilities responsibly. The explanation shown after each solve links the flag to the security concept, so users learn the reason behind the answer.
8.2 · Security Recommendations
R1
R2
R3
R4
09
Section 9
Mini CTF Security Lab Platform succeeds in connecting cybersecurity theory and practice by providing a proper hands-on learning platform. By filling the educational gap in the non-technical security field, the platform combines the main technical aspects (Web Security, Cryptography) with relevant human-centered ones (Security Awareness, Cybersecurity Ethics).
Learning at their own pace
The key features of the system give participants an opportunity to learn at their own pace and get immediate feedback from the system.
Security built in
The system incorporates basic CYS401 knowledge in terms of application layer security mechanisms to protect itself from injection attacks, broken access control, and data leakage.
Thank you!
Try the challenge tracks yourself, or see how the project is scoped and graded.
01 / --
Title