Fix: Usunięcie wycieku danych wrażliwych w logach

[B1rtek]

Zadanie 1 - Weryfikacja wycieku wrażliwych danych

W logach aplikacji pojawiają się wszystkie dane tworzonego na podstronie /customers w formularzu pokazującym się po kliknięciu w przycisk "Add New Customer" klienta:

Po kliknięciu przycisku "Add Customer" po wypełnieniu formularza w logach pojawi się:

127.0.0.1 - - [22/Nov/2025 01:55:57] "GET /static/js/customers.js HTTP/1.1" 304 -
Getting: Customer(ID: None, Name: Czesław, City: Cieszyn, Age: 12, Pesel: 33333333333, Street: Chojnicka, AppNo: 12)
127.0.0.1 - - [22/Nov/2025 01:56:25] "POST /customers/create HTTP/1.1" 302 -

Zaproponowaną poprawką jest usunięcie z logów (zasłonięcie prawdziwych wartości) danych o miejscu zamieszkania, wieku i PESELu, które mogłyby pozwolić na identyfikację klienta, część z nich stanowi dane wrażliwe. Poprawka zastępuje w logach prawdziwe wartości stałą liczbą znaków * aby nie dało się uzyskać informacji również o długości np. nazwy ulicy zamieszkania czy miasta.

Zadanie 2 - weryfikacja wycieku sekretów

Uruchomienie w repozytorium narzędzia gitleaks poskutkowało znalezieniem trzech zhardkodowanych kluczy prywatnych w dwóch różnych commitach:
https://github.com/B1rtek/task2/blob/bc17b7ddc46f46fff175aed55d68e11bb48166cc/deployment.key#L1
https://github.com/B1rtek/task2/blob/de9d7b8cb63bd7ae741ec5c9e23891b71709bc28/deployment2.key#L1
https://github.com/B1rtek/task2/blob/bc17b7ddc46f46fff175aed55d68e11bb48166cc/awscredentials.json#L5
Nazwy plików i pola w których zostały zapisane sugerują, że były to najprawdopodobniej klucze służące do uwierzytelnienia na platformach na których aplikacja była wdrażana, w przypadku trzeciego klucza platformą tą było najprawdopodobniej AWS. gitleaks nie znalazł żadnych false positives.

Zadanie 3 - weryfikacja bezpieczeństwa bibliotek OpenSource wykorzystywanych w projekcie

Uruchomienie skanera podatności w aplikacji Pythonowej wykryło 11 podatności w 3 pakietach:

11 vulnerabilities were reported in 3 packages. For detailed remediation & fix recommendations, upgrade to a 
  commercial license.

Jedną z wykrytych podatności jest możliwość ataku XSS poprzez szablony jinja2 w przypadku użycia filtra xmlattr:

-> Vulnerability found in jinja2 version 3.1.2
   Vulnerability ID: 64227
   Affected spec: <3.1.3
   ADVISORY: Jinja is an extensible templating engine. Special placeholders in the template allow writing
   code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template,
   potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary
   HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also
   be possible to bypass attribute validation checks if they are blacklist-based.
   CVE-2024-22195
   For more information about this vulnerability, visit https://data.safetycli.com/v/64227/97c
   To ignore this vulnerability, use PyUp vulnerability id 64227 in safety’s ignore command-line argument or add the
   ignore to your safety policy file.

Odpowiednie wartości wprowadzone do pola oznaczonego tym filtrem mogły posłużyć do wstrzyknięcia kodu HTML, który może prowadzić do ataku XSS. Takie miejsce w szablonie strony wyglądałoby np. tak (przykład wzięty z https://help.dashly.io/article/5146):

{{ {"id": "123", "class": "button"} | xmlattr }}
{# Outputs 'id="123" class="button"' #}

Zatem wykorzystanie podatności wymagałoby utworzenia odpowiedniego słownika który wstawiany by był bezpośrednio do wyświetlenia na stronie po przepuszczeniu przez filtr xmlattr. Za pomocą narzędzia grep sprawdziłem zawartość repozytorium pod kątem ilości miejsc, w których filtr xmlattr został użyty, takie miejsca w kodzie nie występują.

 ╰─λ grep -rnH xmlattr . | wc -l
0

Na tej podstawie można stwierdzić, że wykorzystanie tej podatności nie jest możliwe w aktualnej wersji aplikacji.