Skip to content
Snippets Groups Projects
Commit 7bacb588 authored by Nikolai Milenko's avatar Nikolai Milenko :grinning:
Browse files

Upload New File

parent ab589f1e
No related branches found
No related tags found
No related merge requests found
# 📖 Lerntagebuch - Woche 11
---
## **1. Vorfallanalyse: PyPi 'Colourama'-Supply-Chain-Angriff (2023)**
### **Problemquelle**
- Im September 2023 wurde das populäre Python-Paket `colourama` auf PyPi durch eine manipulierte Version ersetzt.
- Angreifer nutzten gestohlene Zugangsdaten eines Paketmaintainers, um bösartigen Code in das Paket einzufügen.
- Die infizierte Version enthielt eine Hintertür, die es ermöglichte, sensible Daten (API-Keys, Umgebungsvariablen) von betroffenen Systemen abzugreifen.
### **Auswirkungen und Folgen**
- Millionen von Entwicklern und Unternehmen nutzen `colourama` für Terminal-Farbformatierungen.
- Anwendungen, die das Paket automatisch aktualisierten, wurden infiziert.
- Gestohlene Zugangsdaten führten zu potenziellen Angriffen auf Cloud-Dienste, APIs und kritische Infrastrukturen.
### **Ursache und Schwachstellen**
- Fehlende Multi-Faktor-Authentifizierung (MFA) auf PyPi ermöglichte den Diebstahl von Zugangsdaten.
- Automatische Updates (`pip install --upgrade`) luden ohne manuelle Prüfung die infizierte Version herunter.
- Fehlende Signaturen und mangelnde Code-Überprüfung ermöglichten es Angreifern, den Code unbemerkt zu manipulieren.
### **Reaktionen und Lösungen**
- PyPi führte verpflichtende MFA für alle Paket-Maintainer ein.
- Entwickler wurden ermutigt, `pip install --require-hashes` zu verwenden, um Hash-basierte Integritätsprüfungen zu erzwingen.
- Sicherheits-Tools wie `pip-audit` wurden verstärkt genutzt, um Pakete auf Schwachstellen zu überprüfen.
---
## **2. Untersuchung von Semantic Versioning**
| Notation | Beispiel | Anwendung | Vorteile | Nachteile |
|----------|---------|-----------|----------|-----------|
| **Exakte Version** | `1.2.3` | Kritische Anwendungen, die vollständige Stabilität benötigen. | Sicherste Option, keine unerwarteten Änderungen. | Keine automatischen Sicherheitsupdates. |
| **Bereichsoperatoren** | `>=1.2.0, <2.0.0` | API-Bibliotheken, die mit allen 1.x-Versionen kompatibel sein müssen. | Ermöglicht kleinere Updates ohne Major-Breaking-Changes. | Minor-Versionen können unerwartete Inkompatibilitäten einführen. |
| **Intervall-Notation** | `[1.2.3, 2.0.0)` | Software, die nur auf einen bestimmten Bereich von Versionen getestet wurde. | Präzise Kontrolle über erlaubte Versionen. | Höherer Wartungsaufwand bei Updates. |
| **Tilde (~)** | `~1.2.3` | Frontend-Frameworks, die nur Bugfixes innerhalb einer Minor-Version erhalten sollen. | Sicherheitsupdates ohne Funktionsänderungen. | Keine neuen Features oder Performance-Verbesserungen. |
| **Caret (^)** | `^1.2.3` | Moderne Web-Apps, die regelmäßige Feature-Updates innerhalb einer Major-Version akzeptieren. | Automatische Minor- und Patch-Updates. | Minor-Versionen könnten unvorhergesehene Änderungen enthalten. |
| **Platzhalter (*)** | `1.*` | Interne Skripte, die immer mit der neuesten verfügbaren Version arbeiten sollen. | Immer aktuelle Features und Fixes. | Risiko von Breaking Changes und unerwarteten Fehlern. |
---
## **Reflexion**
Die Untersuchung von Paketmanager-Vorfällen hat gezeigt, wie kritisch die Sicherheit von Open-Source-Paketen ist. Ich werde in Zukunft:
- Nur vertrauenswürdige Pakete mit `pip install --require-hashes` installieren.
- Automatische Updates mit Bedacht nutzen, insbesondere bei sicherheitskritischen Anwendungen.
- Versionen in meinen Projekten mit `~` oder `^` einschränken, um Stabilität zu gewährleisten.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment