This Proof of Concept (PoC) document is aimed at validating the security design of the Prisleas system, with a focus on user login security and transaction security. To ensure the integrity of the system and the confidentiality of data, we have adopted multiple layers of security measures including Java Spring Security, email verification, two-factor authentication (2FA), and encrypted communication between services. Additionally, we will test the security mechanisms for transactions to ensure the confidentiality of financial data and the security of the transaction process.
GitLab Repository Link: Prisleas Security PoC Repository
User login and transactions are the most critical security concerns in the Prisleas system. By implementing multi-layered verification mechanisms and encrypted communication, we aim to validate the following security objectives:
- Verify the authenticity of user identities to ensure that only authorized users can access the system.
- Prevent malicious intrusion into accounts, such as brute force attacks or phishing attacks.
- Ensure the security of user data and sensitive information during transmission through encrypted communication.
- Ensure data consistency and integrity during transactions to prevent tampering and leakage.
We have developed a proof of concept focusing on system security by implementing three microservices: user_auth, 2fa, and transaction. The user_auth service handles user registration, login, and authentication, while 2fa is responsible for the release and management of new products. Both user_auth and 2fa share a common persistence layer using a MySQL database. The transaction service manages transactions and payments, utilizing Spring's embedded H2 database for its operations.
All three microservices and the MySQL database have been containerized using Docker. We hosted Kubernetes on Docker Desktop to orchestrate the deployment of these services. We integrated Istio within the Kubernetes cluster to configure and secure the microservices, enhancing the overall system security through advanced networking features and traffic management provided by Istio.
We have implemented HTTPS communication for external access to our software and mutual TLS (mTLS) communication between microservices. The relevant configurations are available in gateway.yaml and mtls.yaml within our project directory. This setup ensures that both external and internal communications are securely encrypted, protecting against unauthorized access and data interception.
To test the security of our software, we used Postman to interact with the software's APIs while simultaneously monitoring network traffic using Wireshark. This approach simulates a malicious user attempting to intercept and analyze data packets. We compared the scenarios of the software running directly on the local machine versus being deployed on Kubernetes with our security configurations applied. The used filter is http && tcp.port == 8081(local) and tcp.port == 443 && !(tcp.flags == 0x010 || tcp.flags == 0x010 + 0x010) (deployed)
The above figure shows the network traffic caused by accessing /2fa/user before (left) and after implementing our security settings (right). In the scenario where the software lacks security measures, an attacker can easily intercept and view the content submitted by the user. This includes sensitive data and metadata such as the URI, which could be exploited for malicious purposes. However, after applying our security settings the attacker is only able to see that a TLS connection has been established and cannot get the data transmitted below.
In typical microservices architectures, all service APIs are often treated indiscriminately in terms of accessibility. However, in real-world applications, some APIs are designed to be exposed to end-users, others are meant only for access by internal microservices, and some are specifically tailored for external services. Without proper access restrictions, these APIs can become potential security vulnerabilities. Below, we illustrate the necessity of implementing a layered access control system by providing examples of the three types of APIs within our software.
/leasePrisonTo:It allows a tenant to submit a form containing their personal information and details about the prison they wish to lease. Should be publicly accessible by end-users./makeTransaction:Intended for internal use, this API should only be accessible by the/leasePrisonToendpoint. Thetransactionmicroservice retains only the prison's ID and lacks detailed information about the prison. It requires the2famicroservice to perform security checks before invoking this API.
We only expose necessary APIs to end user by making router to distribute net access to different microservice.
Flow control is an important security metric, which refers to mechanisms that manage the rate of data transmission, helping to prevent network congestion and ensure smooth communication between systems. In our project, we implemented flow control by utilizing Spring Boot’s RateLimiter to effectively limit the request rate from clients. This approach ensures that the system can handle traffic efficiently without being overwhelmed by too many requests at once. By controlling the flow of incoming requests, we maintain system performance and avoid potential downtimes caused by overload or DDoS attacks.
In our experiment, we imposed a limit on the system's total load, restricting it to a maximum of 100 requests per second. Additionally, we set a cap of 10 requests per second for each individual IP address. This approach is designed to efficiently manage concurrent requests and prevent system overload. We conducted simulation tests to evaluate the effectiveness of these constraints, and the results are presented below. By implementing these traffic control measures, we aim to enhance overall system performance while ensuring a better user experience.
The figure illustrates two key points: (1) The system's maximum load limit is 100 per second. Even if individual IP addresses do not reach their own load limit, the overall request rate slows down when the total system load hits this threshold. (2) Before reaching the system’s maximum limit of 100 per second, successful requests increase at a rate of 0.2, which aligns with expectations. This is because each process has a maximum request rate of 20 per second, and adding more processes contributes to an overall increase at a slope of up to 0.2.
The following directory structure reflects the microservices architecture based on the Spring framework. Each directory corresponds to a microservice or a module in the Prisleas system, designed to ensure modularity and maintainability.
- 2fa-backend: Backend service for handling user two-factor authentication.
- 2fa-frontend: Frontend service for user 2FA interactions.
- Operator-backend: Backend service for operator management functionalities.
- Operator-backend-llmAssist: An enhanced backend service using LLM assistive features.
- operator-frontend: Frontend interface for operators.
- transaction: Module for managing and securing financial transactions.
To set up the environment for this PoC, follow the steps below:
-
Clone the Repository:
git clone https://gitlab.ewi.tudelft.nl/cs4505/2024-2025/teams/team-36.git
-
Navigate to the Project Directory:
cd team-36 -
Navigate to Each Microservice Directory:
Go to each microservice directory (
2fa-backend,2fa-frontend,Operator-backend, etc.) and check the README documentation in the subdirectories for specific setup instructions.Links to subdirectories:
prerequisite: docker desktop istio
-
Enable kubernetes on dockerdesktop
-
build .jar for each service.
-
build docker image vis dockerfile under each service folder.
-
kubectl apply -f *.yaml* matches everything under the project first level directory. exceptinternal_accessandexternal accessaccess via https://localhost::443
To run this PoC, you will need the following:
- Java 17 or later
- Gradle (version 8.0+)
- MySQL (version 8.0+)
- Postman for endpoint testing
- OWASP Zap for security testing and automation
- JUnit5 and Mockito for testing
If you would like to contribute to this PoC, please fork the repository and submit a pull request. Ensure all tests pass and adhere to our coding standards before submitting. For major changes, please open an issue to discuss your proposed changes.