234 lines
8.8 KiB
Markdown
234 lines
8.8 KiB
Markdown
# PHP – Grundlagen & Übungsaufgabe
|
||
|
||
## Aufgabe 1: PHP-Informationsfunktion
|
||
|
||
**Hinweis:** Bitte bei allen Zeilen Kommentare einfügen (Funktion der Zeile).
|
||
|
||
### Frage:
|
||
Welche Informationen liefert die Funktion `phpinfo();`?
|
||
|
||
---
|
||
|
||
## Lösung Aufgabe 1
|
||
Die Funktion `phpinfo();` gibt eine umfangreiche Übersicht über die aktuelle PHP-Laufzeitumgebung aus. Sie enthält u.a.:
|
||
- PHP-Version, Build-Datum und Compiler-Informationen
|
||
- Server-API (z. B. Apache Module Handler, FPM, CLI)
|
||
- Pfade: `Loaded Configuration File`, zusätzliche INI-Dateien
|
||
- Konfigurations-Direktiven und ihre aktuellen Werte (lokal vs. master)
|
||
- Installierte und geladene Erweiterungen (Extensions) wie mysqli, PDO, curl, openssl
|
||
- Environment-Variablen und gesetzte HTTP-Header
|
||
- Informationen zu Betriebssystem, Architektur und Thread-Sicherheit
|
||
- Module für Datenbanken, Grafik (GD), OpenSSL, Session, Mail, JSON u.v.m.
|
||
- Lizenzinformationen
|
||
|
||
Minimalbeispiel mit kommentierten Zeilen:
|
||
```php
|
||
<?php
|
||
// Aktiviert die vollständige Informationsausgabe zur PHP-Umgebung
|
||
phpinfo(); // Gibt HTML mit allen PHP- und Systeminformationen aus
|
||
?>
|
||
```
|
||
Hinweis: Nicht in Produktionsumgebungen offen stehen lassen – sensibel für Informationslecks.
|
||
|
||
---
|
||
|
||
## Aufgabe 2: PHP.ini-Einstellungen
|
||
|
||
Erkläre die jeweilige Funktion folgender PHP.ini-Einstellungen:
|
||
|
||
- PHP-Fehler ausgeben
|
||
- Speichernutzung und Laufzeit deiner Skripte limitieren
|
||
- allow_url_fopen = off
|
||
- session.auto_start = off
|
||
|
||
---
|
||
|
||
## Lösung Aufgabe 2
|
||
**Fehlerausgabe**
|
||
- `display_errors` (bool): Steuert, ob Fehler direkt im Browser/CLI ausgegeben werden. In Entwicklung: `On`, Produktion: `Off`.
|
||
- `error_reporting` (int): Legt fest, welche Fehlertypen gemeldet werden (z. B. `E_ALL`).
|
||
- `log_errors` (bool): Fehler ins Log schreiben statt anzeigen – wichtig für Sicherheit.
|
||
|
||
**Speicher- und Laufzeitbegrenzung**
|
||
- `memory_limit` (z. B. `256M`): Maximale Menge RAM, die ein Skript nutzen darf. Verhindert Abstürze durch Überlastung.
|
||
- `max_execution_time` (Sekunden): Maximale Laufzeit eines Skripts (Standard oft 30). Schutz gegen Endlosschleifen / Hänger.
|
||
- `max_input_time`: Zeitlimit für das Parsen von Input-Daten (POST/GET).
|
||
|
||
**Remote-File-Handling**
|
||
- `allow_url_fopen`: Erlaubt Dateifunktionen (`file_get_contents`, `fopen`) auf URL-Wrapper (http/https). `off` erhöht Sicherheit (verhindert SSRF / unerwartete externe Zugriffe). Bei Bedarf besser cURL mit Validierung nutzen.
|
||
|
||
**Session-Verhalten**
|
||
- `session.auto_start`: Wenn `On`, startet PHP automatisch eine Session bei jedem Request – unflexibel, kann Performance und Ressourcen belasten. Mit `Off` startet man Sessions gezielt (`session_start();`).
|
||
|
||
**Sicherheits-Implikationen (kurz):**
|
||
- Zu aggressive Fehleranzeige in Produktion = Informationsleck.
|
||
- Fehlende Limits = Risiko von Ressourcenerschöpfung (DoS).
|
||
- `allow_url_fopen` ungeprüft = Angriffsfläche für SSRF / Remote Inclusion.
|
||
- Unkontrollierte Sessions = Tracking-/Sicherheitsprobleme.
|
||
|
||
---
|
||
|
||
## Aufgabe 3: Beispielwebseite in PHP
|
||
|
||
Erstelle eine Datei mit dem Namen **`test.php`**
|
||
und kopiere sie in dein **`htdocs`**-Verzeichnis.
|
||
Führe sie anschließend im Browser aus.
|
||
|
||
### Beschreibung
|
||
Die Aufgabe dieses Programms ist die **Addition und Multiplikation mehrerer Zahlen**
|
||
sowie die **Anzeige des Rechenergebnisses**.
|
||
|
||
Es darf **keine Benutzerinteraktion** stattfinden –
|
||
die Werte werden **fix in der PHP-Datei** eingetragen.
|
||
|
||
### Szenario
|
||
Zwei Tankfüllungen:
|
||
```text
|
||
liter1 = 40.5
|
||
liter2 = 35.7
|
||
preis = 1.499
|
||
```
|
||
|
||
---
|
||
|
||
## Lösung Aufgabe 3 (Auszug aus `test.php`)
|
||
```php
|
||
<?php
|
||
$liter1 = 40.5; // Erste Tankfüllung in Litern
|
||
$liter2 = 35.7; // Zweite Tankfüllung in Litern
|
||
$preis = 1.499; // Preis pro Liter (EUR)
|
||
|
||
$gesamtLiter = $liter1 + $liter2; // Addition der Literwerte
|
||
$kostenFuellung1 = $liter1 * $preis; // Kosten der ersten Füllung
|
||
$kostenFuellung2 = $liter2 * $preis; // Kosten der zweiten Füllung
|
||
$gesamtKosten = $gesamtLiter * $preis; // Gesamtkosten für beide
|
||
|
||
echo 'Gesamtmenge: ' . $gesamtLiter . ' L'; // Ausgabe Menge
|
||
// ... weitere formatierte Ausgaben siehe vollständige Datei
|
||
?>
|
||
```
|
||
Vollständiger Code siehe `test.php`.
|
||
|
||
---
|
||
|
||
## 🌐 Client-Server & HTTP-Zyklus
|
||
**HTTP Cycle:**
|
||
1. Request: Browser → Server (Methoden: GET, POST, PUT, DELETE, PATCH; Headers; Body)
|
||
2. Processing: Routing, Business-Logik, DB-Operationen
|
||
3. Response: Status-Codes (2xx, 3xx, 4xx, 5xx), Headers, Body (HTML/JSON/Assets)
|
||
|
||
**Netzwerkschichten (vereinfacht):**
|
||
```
|
||
App: HTTP/HTTPS, REST, GraphQL
|
||
Transport: TCP/UDP, WebSockets
|
||
Internet: IP Routing, DNS
|
||
Link: Ethernet, WiFi, 5G
|
||
```
|
||
|
||
**Webserver Beispiele:** Nginx (Reverse Proxy, Performance), Apache (flexibel), Caddy (Auto-HTTPS), Cloudflare Workers (Edge/Serverless)
|
||
|
||
---
|
||
|
||
## 🛠️ Entwicklungsumgebung (Stack-Beispiele)
|
||
Runtime: Node.js 18+, PHP 8.1+, Python 3.11+, Docker / Podman
|
||
DB: PostgreSQL 15+, MySQL 8+ / MariaDB, Redis, MongoDB
|
||
Tools: IDE (VS Code, PhpStorm), Docker, Git, Linter, Test-Frameworks
|
||
|
||
**Docker Compose Beispiel:**
|
||
```yaml
|
||
version: '3.8'
|
||
services:
|
||
app:
|
||
build: .
|
||
ports:
|
||
- '8080:80'
|
||
db:
|
||
image: postgres:15
|
||
environment:
|
||
POSTGRES_DB: myapp
|
||
redis:
|
||
image: redis:7-alpine
|
||
```
|
||
Lokale Installation (macOS/Linux): `brew/apt install nginx postgresql redis`
|
||
|
||
---
|
||
|
||
## ⚠️ Sicherheitsrisiken (Auswahl)
|
||
1. Phishing – Nutzer werden auf gefälschte Seiten gelockt (Schutz: HTTPS, Schulung, DMARC)
|
||
2. Datendiebstahl – Unautorisierter Zugriff (Schutz: Zugriffskontrolle, Verschlüsselung)
|
||
3. SQL Injection – Manipulierte Eingaben verändern Queries (Schutz: Prepared Statements)
|
||
4. XSS – Eingebettete Skripte (Schutz: Output Encoding, CSP)
|
||
5. Session Hijacking – Session-Diebstahl (Schutz: Secure/HttpOnly Cookies, Regeneration)
|
||
6. DoS/DDoS – Überlastung (Schutz: Rate Limits, WAF, Caching)
|
||
7. CSRF – Ungewollte Aktionen (Schutz: CSRF-Token, SameSite Cookies)
|
||
8. File Inclusion (LFI/RFI) – Lokale/Remote Ausführung von Dateien (Schutz: Whitelists, `allow_url_fopen=off`, Pfadvalidierung)
|
||
|
||
### Weitere Angriffsvektoren / Exploits
|
||
- Remote Code Execution (RCE) durch unsichere eval/include oder veraltete Bibliotheken
|
||
- Path Traversal (../../..) für unerlaubten Datei-Zugriff
|
||
- Insecure Direct Object Reference (IDOR) durch fehlende Autorisierung bei Ressourcen-IDs
|
||
- Unsichere Dateiuploads (Webshells) – fehlende Typ-/Inhaltsprüfung
|
||
- Insecure Deserialization – Ausführung schädlicher Objekte
|
||
- Server-Side Request Forgery (SSRF) – Ausnutzen interner Netzwerkzugriffe
|
||
- Cryptographic Weaknesses – schwache Hashes (MD5/SHA1), hartecodierte Schlüssel
|
||
- Race Conditions – Logikfehler bei paralleler Verarbeitung (z. B. doppelte Buchungen)
|
||
- Fehlkonfiguration (Default-Passwörter, offene Admin-Panels)
|
||
- Supply-Chain Angriffe – manipulierte Drittanbieter-Pakete
|
||
|
||
---
|
||
|
||
## 🛡️ Schutzmaßnahmen
|
||
**Encryption:** TLS (HTTPS), Verschlüsselung ruhender Daten (Disk/DB)
|
||
**Auth:** MFA, starke Passwörter, RBAC/Least Privilege
|
||
**Validation:** Strikte Input-Validierung, Prepared Statements, Output Encoding
|
||
**Sessions:** HttpOnly + Secure Cookies, Session-Regeneration nach Login, angemessener Timeout
|
||
**Headers:** CSP, X-Frame-Options, X-Content-Type-Options, HSTS, Referrer-Policy
|
||
**Monitoring:** Logging, Audit Trails, IDS/WAF, SIEM
|
||
**Updates:** Regelmäßige Patches, Dependency-Scans (Composer Audit)
|
||
**Backup & Recovery:** Getestete Wiederherstellungsprozesse, Offline-Backups
|
||
|
||
Beispiel Prepared Statement (PDO):
|
||
```php
|
||
<?php
|
||
// $pdo vorher sicher initialisiert (DSN, User, Passwort)
|
||
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?'); // Platzhalter vermeidet SQL Injection
|
||
$stmt->execute([$email]); // Binded Wert sicher
|
||
$user = $stmt->fetch(PDO::FETCH_ASSOC); // Holt Datensatz als Array
|
||
?>
|
||
```
|
||
|
||
---
|
||
|
||
## ✅ Best Practices (Kurzliste)
|
||
- Eingaben validieren & sanitisieren
|
||
- Prepared Statements überall für DB-Zugriffe
|
||
- HTTPS erzwingen / HSTS aktivieren
|
||
- Starke Authentifizierung (MFA, Passwortrichtlinien)
|
||
- Sicherheitsheader setzen (CSP, X-Frame-Options, etc.)
|
||
- Software & Dependencies aktuell halten
|
||
- Logging + aktives Monitoring (Anomalien)
|
||
- Least Privilege & strikte Rollen
|
||
- Regelmäßige Penetrationstests & Code Reviews
|
||
- Geplante Backups & Wiederherstellung testen
|
||
|
||
---
|
||
|
||
## 📚 Ressourcen
|
||
- OWASP Top 10: https://owasp.org/www-project-top-ten/
|
||
- PHP Security: https://www.php.net/manual/en/security.php
|
||
- Mozilla Web Security Guidelines: https://infosec.mozilla.org/guidelines/web_security
|
||
- CWE: https://cwe.mitre.org/
|
||
- PHP The Right Way: https://phptherightway.com/
|
||
- Composer Security Advisories: https://github.com/FriendsOfPHP/security-advisories
|
||
|
||
---
|
||
|
||
## Hinweise zur lokalen Ausführung
|
||
**PHP Dev-Server (falls kein Apache/Nginx konfiguriert):**
|
||
```bash
|
||
php -S localhost:8000
|
||
```
|
||
Dann im Browser: `http://localhost:8000/test.php`
|
||
|
||
**Sicherheits-Hinweis:** `phpinfo()` nur temporär verwenden und danach entfernen.
|