TBO laboratorium2

[PawelMurdzek]

Combined Security Analysis Report

Zadanie 1 - Wrażliwe dane w logach

Wrażliwe dane:

Getting: Customer(ID: None, Name: Andrzej, City: Warszawa, Age: 18, Pesel: 12345677, Street: Plac Politechniki, AppNo: 1)

W powyższym logu mamy adres oraz Pesel osoby zapisywane jawnie i niezaszyfrowane a także skojarzone z imieniem.
Pojawiają się one tylko w przypadku dodanie nowego gościa biblioteki, nie w przypadku wypożyczeń.

Poprawki

    def __repr__(self):
        return f"Customer(ID: {self.id}, Name: {self.name}, City: {self.city}, Age: {self.age}, Pesel: {self._mask_sensitive(self.pesel)}, Street: {self._mask_sensitive(self.street)}, AppNo: {self._mask_sensitive(self.appNo)})"
    
    def _mask_sensitive(self, value):
        """Mask sensitive data by replacing with asterisks"""
        if value:
            return '*' * len(str(value))
        return value

Dodano funkcję _mask_sensitive, która zamienia wybrane dane na "*".
Wynik:

Getting: Customer(ID: None, Name: Jan, City: Wawa, Age: 420, Pesel: *********, Street: ********, AppNo: **).

---

Zadanie 2 - Wyniki użycia programu gitleaks

Znaleziono 3 secrety:

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

Finding:     -----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAKj34GkxFhD90vcNLYLInFEX6Ppy1tPf9Cnzj4p4WGeKLs1Pt8Qu
KUp...
Secret:      -----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAKj34GkxFhD90vcNLYLInFEX6Ppy1tPf9Cnzj4p4WGeKLs1Pt8Qu
KUp...
RuleID:      private-key
Entropy:     5.875154
File:        deployment.key
Line:        1
Commit:      bc17b7ddc46f46fff175aed55d68e11bb48166cc
Author:      Grzegorz Siewruk
Email:       gsiewruk@gmail.com
Date:        2023-11-15T12:52:32Z
Fingerprint: bc17b7ddc46f46fff175aed55d68e11bb48166cc:deployment.key:private-key:1
Link:        https://github.com/PawelMurdzek/task2/blob/bc17b7ddc46f46fff175aed55d68e11bb48166cc/deployment.key#L1

Finding:     -----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAKj34GkxFhD90vcNLYLInFEX6Ppy1tPf9Cnzj4p4WGeKLs1Pt8Qu
KUp...
Secret:      -----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAKj34GkxFhD90vcNLYLInFEX6Ppy1tPf9Cnzj4p4WGeKLs1Pt8Qu
KUp...
RuleID:      private-key
Entropy:     5.875154
File:        deployment2.key
Line:        1
Commit:      de9d7b8cb63bd7ae741ec5c9e23891b71709bc28
Author:      Grzegorz Siewruk
Email:       gsiewruk@gmail.com
Date:        2023-11-15T12:49:39Z
Fingerprint: de9d7b8cb63bd7ae741ec5c9e23891b71709bc28:deployment2.key:private-key:1
Link:        https://github.com/PawelMurdzek/task2/blob/de9d7b8cb63bd7ae741ec5c9e23891b71709bc28/deployment2.key#L1

Finding:     "private_key": "-----BEGIN PRIVATE KEY-----\nlRsGbRO/1A5LiQHjuR5SASDASDAiSMNeOYqna2R+HEalBoyISASDASD1Tgkj\n4CC02Uux+...\n",
Secret:      -----BEGIN PRIVATE KEY-----\nlRsGbRO/1A5LiQHjuR5SASDASDAiSMNeOYqna2R+HEalBoyISASDASD1Tgkj\n4CC02Uux+...
RuleID:      private-key
Entropy:     5.917361
File:        awscredentials.json
Line:        5
Commit:      bc17b7ddc46f46fff175aed55d68e11bb48166cc
Author:      Grzegorz Siewruk
Email:       gsiewruk@gmail.com
Date:        2023-11-15T12:52:32Z
Fingerprint: bc17b7ddc46f46fff175aed55d68e11bb48166cc:awscredentials.json:private-key:5
Link:        https://github.com/PawelMurdzek/task2/blob/bc17b7ddc46f46fff175aed55d68e11bb48166cc/awscredentials.json#L5

Wycieki bezpieczeństwa:

Gitleaks wykrył 3 prawdziwe wycieki sekretów w historii repozytorium Git:

1. deployment.key - klucz prywatny RSA (commit: bc17b7d, data: 15.11.2023)
2. deployment2.key - klucz prywatny RSA (commit: de9d7b8, data: 15.11.2023)
3. awscredentials.json - klucz prywatny w formacie JSON (commit: bc17b7d, data: 15.11.2023)

Weryfikacja:

Pliki NIE istnieją w obecnym kodzie - zostały usunięte. Jednak nadal są dostępne w historii Git, co stanowi zagrożenie bezpieczeństwa.

Wnioski:

• Wykrycia są prawdziwe (nie false positive)
• Klucze prywatne były commitowane do publicznego repozytorium
• Mimo usunięcia z kodu, klucze pozostają w historii i można je odzyskać
• Klucze należy uznać za skompromitowane i wymienić na nowe. W środowisku produkcyjnym powinny zostać natychmiast zdeaktywowane.

---

Zadanie 3 - Wyniki skanu Safety Check dla Python

Analiza najpoważniejszej podatności

Wybrana podatność: Jinja2 - Sandbox Bypass (ID: 76378)

Pakiet: Jinja2 wersja 3.1.2
Wymagana wersja: >= 3.1.5
Typ podatności: Remote Code Execution (RCE) - Sandbox Bypass
Krytyczność: Wysoka/Krytyczna

Opis podatności:

Podatność w silniku szablonów Jinja2 pozwala atakującemu, który kontroluje zawartość szablonu, na wykonanie arbitralnego kodu Python poprzez ominięcie mechanizmów sandbox. Podatność umożliwia:

• Przechowywanie referencji do metody str.format złośliwego stringa
• Przekazanie tej referencji do filtra, który ją wywołuje
• Wykonanie kodu Python poza sandboxem Jinja

Warunki wykorzystania:

1. Atakujący musi kontrolować zawartość szablonu (template content)
2. Aplikacja musi wykonywać niezaufane szablony (untrusted templates)
3. Wymagane jest użycie niestandardowych filtrów (custom filters), które wywołują przekazaną metodę
4. Alternatywnie: wykorzystanie filtra |attr do uzyskania referencji do metody format

Analiza w kontekście badanej aplikacji Flask_Book_Library:

Weryfikacja wykorzystania Jinja2:

• Aplikacja używa render_template() w plikach: books/views.py, customers/views.py, loans/views.py, core/views.py
• Szablony znajdują się w katalogu templates/ (books.html, customers.html, loans.html, index.html)

Weryfikacja warunków exploita:

• Aplikacja używa Jinja2 w wersji podatnej (3.1.2 < 3.1.5)
• Użytkownik NIE kontroluje zawartości szablonów - szablony są statyczne, zapisane w plikach HTML
• Nie znaleziono użycia filtrów xmlattr ani |attr w szablonach
• Brak niestandardowych filtrów, które mogłyby wywołać str.format
• Aplikacja nie wykonuje dynamicznie generowanych szablonów z danych użytkownika

Wnioski:

Prawdopodobieństwo wykorzystania podatności: MINIMALNE

Mimo że aplikacja używa podatnej wersji Jinja2, podstawowy warunek wykorzystania tej podatności nie jest spełniony. Atakujący nie ma możliwości kontrolowania zawartości szablonów, ponieważ:

• Wszystkie szablony są statyczne i przechowywane jako pliki .html
• Użytkownik dostarcza tylko dane (książki, klienci, wypożyczenia), które są renderowane w predefiniowanych szablonach
• Dane użytkownika są przekazywane jako zmienne kontekstowe, nie jako kod szablonu

Zalecenia:

• Mimo niskiego ryzyka, zaleca się aktualizację Jinja2 do wersji >= 3.1.6
• Należy zachować obecną architekturę (statyczne szablony)
• NIGDY nie implementować funkcjonalności pozwalającej użytkownikom na tworzenie/edycję szablonów Jinja2

Wyniki skanu

+==============================================================================+
|                                                                              |
|                               /$$$$$$            /$$                         |
|                              /$$__  $$          | $$                         |
|           /$$$$$$$  /$$$$$$ | $$  \__//$$$$$$  /$$$$$$   /$$   /$$           |
|          /$$_____/ |____  $$| $$$$   /$$__  $$|_  $$_/  | $$  | $$           |
|         |  $$$$$$   /$$$$$$$| $$_/  | $$$$$$$$  | $$    | $$  | $$           |
|          \____  $$ /$$__  $$| $$    | $$_____/  | $$ /$$| $$  | $$           |
|          /$$$$$$$/|  $$$$$$$| $$    |  $$$$$$$  |  $$$$/|  $$$$$$$           |
|         |_______/  \_______/|__/     \_______/   \___/   \____  $$           |
|                                                          /$$  | $$           |
|                                                         |  $$$$$$/           |
|  by pyup.io                                              \______/            |
|                                                                              |
+==============================================================================+
| REPORT                                                                       |
| checked 18 packages, using free DB (updated once a month)                    |
+============================+===========+==========================+==========+
| package                    | installed | affected                 | ID       |
+============================+===========+==========================+==========+
| jinja2                     | 3.1.2     | <3.1.3                   | 64227    |
+==============================================================================+
| 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.                                                             |
+==============================================================================+
| jinja2                     | 3.1.2     | <3.1.4                   | 71591    |
+==============================================================================+
| Jinja is an extensible templating engine. The `xmlattr` filter in affected   |
| versions of Jinja accepts keys containing non-attribute characters. XML/HTML |
| attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be    |
| interpreted as starting a separate attribute. If an application accepts keys |
| (as opposed to only values) as user input, and renders these in pages that   |
| other users see as well, an attacker could use this to inject other          |
| attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces |
| but not other characters. Accepting keys as user input is now explicitly     |
| considered an unintended use case of the `xmlattr` filter, and code that     |
| does so without otherwise validating the input should be flagged as          |
| insecure, regardless of Jinja version. Accepting _values_ as user input      |
| continues to be safe.                                                        |
+==============================================================================+
| jinja2                     | 3.1.2     | <3.1.5                   | 76378    |
+==============================================================================+
| An oversight in how the Jinja sandboxed environment detects calls to         |
| str.format allows an attacker who controls the content of a template to      |
| execute arbitrary Python code. To exploit the vulnerability, an attacker     |
| needs to control the content of a template. Whether that is the case depends |
| on the type of application using Jinja. This vulnerability impacts users of  |
| applications which execute untrusted templates. Jinja's sandbox does catch   |
| calls to str.format and ensures they don't escape the sandbox. However, it's |
| possible to store a reference to a malicious string's format method, then    |
| pass that to a filter that calls it. No such filters are built-in to Jinja,  |
| but could be present through custom filters in an application. After the     |
| fix, such indirect calls are also handled by the sandbox.                    |
+==============================================================================+
| jinja2                     | 3.1.2     | <3.1.6                   | 75976    |
+==============================================================================+
| Prior to 3.1.6, an oversight in how the Jinja sandboxed environment          |
| interacts with the |attr filter allows an attacker that controls the content |
| of a template to execute arbitrary Python code. To exploit the               |
| vulnerability, an attacker needs to control the content of a template.       |
| Whether that is the case depends on the type of application using Jinja.     |
| This vulnerability impacts users of applications which execute untrusted     |
| templates. Jinja's sandbox does catch calls to str.format and ensures they   |
| don't escape the sandbox. However, it's possible to use the |attr filter to  |
| get a reference to a string's plain format method, bypassing the sandbox.    |
| After the fix, the |attr filter no longer bypasses the environment's         |
| attribute lookup. This vulnerability is fixed in 3.1.6.                      |
+==============================================================================+
| jinja2                     | 3.1.2     | >=3.0.0a1,<3.1.5         | 74735    |
+==============================================================================+
| A vulnerability in the Jinja compiler allows an attacker who can control     |
| both the content and filename of a template to execute arbitrary Python      |
| code, bypassing Jinja's sandbox protections. To exploit this vulnerability,  |
| an attacker must have the ability to manipulate both the template's filename |
| and its contents. The risk depends on the application's specific use case.   |
| This issue affects applications that render untrusted templates where the    |
| attacker can determine the template filename, potentially leading to severe  |
| security breaches.                                                           |
+==============================================================================+
| werkzeug                   | 2.3.7     | <2.3.8                   | 62019    |
+==============================================================================+
| Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for  |
| large parts potentially enabling DoS attacks.                                |
| https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d69692 |
| 2bfc5c1                                                                      |
+==============================================================================+
| werkzeug                   | 2.3.7     | <3.0.3                   | 71594    |
+==============================================================================+
| Werkzeug is a comprehensive WSGI web application library. The debugger in    |
| affected versions of Werkzeug can allow an attacker to execute code on a     |
| developer's machine under some circumstances. This requires the attacker to  |
| get the developer to interact with a domain and subdomain they control, and  |
| enter the debugger PIN, but if they are successful it allows access to the   |
| debugger even if it is only running on localhost. This also requires the     |
| attacker to guess a URL in the developer's application that will trigger the |
| debugger.                                                                    |
+==============================================================================+
| werkzeug                   | 2.3.7     | <3.0.6                   | 73969    |
+==============================================================================+
| Affected versions of Werkzeug are vulnerable to Path Traversal (CWE-22) on   |
| Windows systems running Python versions below 3.11. The safe_join() function |
| failed to properly detect certain absolute paths on Windows, allowing        |
| attackers to potentially access files outside the intended directory. An     |
| attacker could craft special paths starting with "/" that bypass the         |
| directory restrictions on Windows systems. The vulnerability exists in the   |
| safe_join() function which relied solely on os.path.isabs() for path         |
| validation. This is exploitable on Windows systems by passing paths starting |
| with "/" to safe_join(). To remediate, upgrade to the latest version which   |
| includes additional path validation checks.                                  |
| NOTE: This vulnerability specifically affects Windows systems running Python |
| versions below 3.11 where ntpath.isabs() behavior differs.                   |
+==============================================================================+
| werkzeug                   | 2.3.7     | <3.0.6                   | 73889    |
+==============================================================================+
| Affected versions of Werkzeug are potentially vulnerable to resource         |
| exhaustion when parsing file data in forms. Applications using               |
| 'werkzeug.formparser.MultiPartParser' to parse 'multipart/form-data'         |
| requests (e.g. all flask applications) are vulnerable to a relatively simple |
| but effective resource exhaustion (denial of service) attack. A specifically |
| crafted form submission request can cause the parser to allocate and block 3 |
| to 8 times the upload size in main memory. There is no upper limit; a single |
| upload at 1 Gbit/s can exhaust 32 GB of RAM in less than 60 seconds.         |
+==============================================================================+
| werkzeug                   | 2.3.7     | <=2.3.7                  | 71595    |
+==============================================================================+
| Werkzeug is a comprehensive WSGI web application library. If an upload of a  |
| file that starts with CR or LF and then is followed by megabytes of data     |
| without these characters: all of these bytes are appended chunk by chunk     |
| into internal bytearray and lookup for boundary is performed on growing      |
| buffer. This allows an attacker to cause a denial of service by sending      |
| crafted multipart data to an endpoint that will parse it. The amount of CPU  |
| time required can block worker processes from handling legitimate requests.  |
+==============================================================================+
| healpy                     | 1.8.0     | <=1.16.6                 | 61774    |
+==============================================================================+
| Healpy 1.16.6 and prior releases ship with a version of 'libcurl' that has a |
| high-severity vulnerability.                                                 |
+==============================================================================+