Puces'in - SLAM, 2025 session

Mission A1 - VerifColis (desktop client)

An employee approved buyback prices higher than the resale price: Puces’in buys back for more than it resells → direct financial loss (buying at a loss) on each affected book.

Add a check (application/server-side) before saving: only save the proposed buyback price if the book is in an 'acceptable' condition and this price does not exceed 10% of the resale price; otherwise, reject/block the save and flag it. The rule must not rely on the interface alone (which can be bypassed) but must be verified upon saving.

Mission A2 - Puces’in Rachète (mobile / REST API)

1. Unnecessary logistics costs: Puces’in processes empty parcels (reception, sorting, handling) with no books to buy back.
2. Misuse/abuse of the service: competitors obtain free shipping labels and disrupt operations - leading to wasted time and harming service availability for genuine sellers.

Before validating the parcel, call getNbBordereauDuMois(idVendeur); if the result is ≥ 4, reject validation (return false/error); otherwise validate. The check is performed API-side (server), not only in the mobile app.

Mission A3 - REST API and JWT tokens

a/b/c) The two vulnerability tests typically reveal: an unauthenticated access to a resource (the request succeeds when it should not → breach of confidentiality), and an access control / integrity flaw (an unauthorised write goes through → breach of integrity). Each test is classified according to the affected criterion (confidentiality, integrity or availability).

It is only secure if it compares hashes (salted hashed passwords) using a prepared statement. If it compares plaintext passwords or builds the query by concatenation (possible SQL injection), it is not secure.

Implement rate limiting: count requests per user/URI over a time window and reject beyond a threshold (HTTP 429 response). (Implementation is not required.)

The token signature is calculated with HMAC using a secret key known only to the server. Any modification to the token content (header or payload) invalidates the signature: the server recalculates the HMAC and detects the tampering. An attacker cannot forge a valid token without the key → the integrity (and authenticity) of the token is ensured.

The JWT proves identity but does not encrypt its transport: over HTTP, an attacker can intercept the token (eavesdropping) and replay it to hijack the session. HTTPS (TLS) encrypts the channel → it protects the token (and data) against eavesdropping and theft.

The second test fails because the token is not valid at the time of the request: typically an expired token (lifespan exceeded), a missing token, or a mismatched signature (modified token / wrong key) - so the API rejects it.

a) Two missing rights: the right to rectification and the right to erasure ('right to be forgotten').

b) Ms Mathy has a statutory deadline of one month to respond (extendable to three months for complex requests, provided the individual is informed) - her current timeframe of 2 months exceeds the deadline.

No, this is not compliant. The GDPR imposes storage limitation: copies of identity documents must only be kept for as long as necessary to process the request, and then deleted. Keeping them indefinitely 'as a precaution' constitutes excessive retention (a breach of the data minimisation/storage limitation principle).

The processing activity for logging rights requests must be documented in the record of processing activities (GDPR register maintained by the data controller).

Complete the schema to manage the deadline, statistics and traceability:

• a Demande table with the type of right and relevant dates (entry date, status change dates) → allows the timeframe and statistics by type to be calculated;
• a Echange table (date, description, origin = D requester or P DPO), linked to the request → keeps a record of communications.

Mission C1 - Attacks and countermeasures

a) The attacker usedsocial engineering (for example phishing: a fraudulent message prompting the employee to click or disclose their credentials).

b) The employee was therefore the victim of a phishing attack.

1. Regular training and simulation campaigns on phishing.
2. Promote simple best practices: check the sender and links, never share credentials, report any suspicious message to the IT department.

Depending on the attack described in the ticket, two appropriate preventive measures - such as updates/patches for exposed components and access filtering/hardening ('deny all by default' policy, strong authentication) - to prevent the incident from recurring.

In addition to alerts at 3 months and 1 month before expiry, add an additional reminder 1 week before the expiry date: add a condition checking whether the current date reaches 'expiry date - 7 days' and, if so, trigger the alert.

Mission C2 - Log analysis

Analysis of the auth.log file (multiple failed authentication attempts followed by a successful one) reveals a brute-force attack (brute force) on authentication.

1. Weak passwords (guessable).
2. No account lockout after repeated failures (and no MFA) → the attacker can try indefinitely.

• Confidentiality: data access and leakage (customers, sales) once the account is compromised.
• Integrity: fraudulent data modification (privileges, content).
• Availability: service disruption/alteration (data deletion, site downtime).

a) Must be notified: the CNIL (within 72 h) and the individuals concerned if the risk is high.

b) The breach must be recorded in the data breach register.

c) To preserve the integrity of evidence: retain logs without modifying them (read-only copy, file timestamping/fingerprinting/hashing) and isolate affected systems as they are for the investigation.

REVOKE ALL PRIVILEGES, GRANT OPTION
ON pucesin.* FROM 'compte_compromis'@'%';

(The account is then removed/recreated with only legitimate privileges.)

Mission C3 - Secure access to the database

a) Create the statistiques account, restricted to address 95.10.2.54, with read-only access to only the tables needed for statistics:

CREATE USER 'statistiques'@'95.10.2.54' IDENTIFIED BY '<mot_de_passe_fort>';
GRANT SELECT ON pucesin.Livre        TO 'statistiques'@'95.10.2.54';
GRANT SELECT ON pucesin.Publication  TO 'statistiques'@'95.10.2.54';
-- (uniquement les tables nécessaires aux statistiques)

b) Alternative technical solution: expose a SQL view (or role) for statistics containing only the relevant columns/tables → the account only accesses this view, never the complete data.