vk
|
9faae15212
|
[P1 Security] Rate Limiting für API-Routes und Livewire-Actions (vibe-kanban e1f85c61)
## Security Audit: Fehlendes Rate Limiting
### Problem
Die Anwendung hat **kein Rate Limiting** auf API-Routes oder Livewire-Actions. Das ermöglicht:
- Brute-Force-Angriffe auf Authentication-Endpoints
- Denial-of-Service durch massenhaftes Aufrufen von API-Endpoints
- Vote-Manipulation durch schnelle, wiederholte Requests
- Ressourcen-Erschöpfung durch unkontrollierte Datenbankabfragen
### Betroffene Endpoints
**API-Routes (`routes/api.php`):**
```php
Route::get('/nostr/profile/{key}', GetProfile::class); // kein Rate Limit
Route::get('/members/{year}', GetPaidMembers::class); // kein Rate Limit
```
**Kritische Livewire-Actions (kein Throttling):**
- Voting auf ProjectProposals (`association/project-support/show`)
- Login via Nostr (`handleNostrLogin`)
- ProjectProposal-Erstellung
- Election Voting
### Lösung
**1. API Rate Limiting in `bootstrap/app.php`:**
Nutze Laravel 12's Middleware-Konfiguration um Rate Limiting zu aktivieren:
```php
->withMiddleware(function (Middleware $middleware) {
$middleware->api(prepend: [
\Illuminate\Routing\Middleware\ThrottleRequests::class.':api',
]);
})
```
Und definiere den `api` Rate Limiter in `app/Providers/AppServiceProvider.php`:
```php
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
public function boot(): void
{
RateLimiter::for('api', function (Request $request) {
return Limit::perMinute(60)->by($request->ip());
});
}
```
**2. Livewire Action Throttling:**
Nutze Livewire's `#[Throttle]` Attribut auf sensiblen Actions. Suche in der Livewire-Dokumentation nach der korrekten v4-Syntax mit `search-docs`:
- `queries: ['throttle', 'rate limiting']`
- `packages: ['livewire/livewire']`
Wende Throttling an auf:
- Vote-Submit-Methoden in den ProjectSupport-Components
- Login-Handler (`handleNostrLogin` in `WithNostrAuth` Trait)
- ProjectProposal Create/Update Actions
**3. Zusätzlicher Custom Rate Limiter für Voting:**
```php
RateLimiter::for('voting', function (Request $request) {
return Limit::perMinute(10)->by($request->ip());
});
```
### Betroffene Dateien
- `bootstrap/app.php` – Middleware-Konfiguration (Rate Limit Middleware hinzufügen)
- `app/Providers/AppServiceProvider.php` – RateLimiter Definitionen
- `routes/api.php` – Rate Limit Middleware anwenden
- `app/Livewire/Traits/WithNostrAuth.php` – Throttle auf `handleNostrLogin`
- Livewire-Components in `app/Livewire/Association/ProjectSupport/` – Throttle auf Vote/Create Actions
### Vorgehen
1. `search-docs` nutzen für: `['rate limiting', 'throttle']` (Laravel) und `['throttle']` (Livewire)
2. Rate Limiter in AppServiceProvider definieren
3. API-Middleware in `bootstrap/app.php` konfigurieren
4. Livewire-Actions mit Throttle versehen
5. Pest-Tests schreiben, die verifizieren dass Rate Limiting greift (429 Response bei Überschreitung)
6. `vendor/bin/pint --dirty` und `php artisan test --compact`
### Akzeptanzkriterien
- API-Routes geben HTTP 429 nach 60 Requests/Minute zurück
- Voting-Actions sind auf max. 10/Minute limitiert
- Login-Attempts sind throttled
- Tests verifizieren Rate Limiting Verhalten
|
2026-02-11 21:13:36 +01:00 |
|
vk
|
90288ac20e
|
[P0 Security] Mass Assignment Protection – $fillable für alle 18 Models (vibe-kanban 4a764a11)
## Security Audit: Mass Assignment Protection
### Problem
Alle 18 Eloquent Models verwenden `protected $guarded = [];` – das bedeutet **kein Schutz** gegen Mass Assignment. Ein Angreifer könnte über manipulierte Requests sensible Felder wie `accepted`, `sats_paid`, `association_status`, `paid` oder `created_by` direkt setzen.
### Betroffene Dateien und empfohlene Änderungen
Ersetze in **jedem** der folgenden Models `protected $guarded = [];` durch ein explizites `protected $fillable = [...]` Array. Hier die Analyse pro Model:
**Höchstes Risiko (Finanzen & Identity):**
1. **`app/Models/PaymentEvent.php`** – Finanz-kritisch!
- Sensible Felder (NICHT fillable): `einundzwanzig_pleb_id`, `year`, `amount`, `event_id`, `paid`, `btc_pay_invoice`
- `$fillable` sollte leer oder minimal sein – alle Felder werden programmatisch gesetzt
2. **`app/Models/EinundzwanzigPleb.php`**
- Sensible Felder: `association_status`, `application_for`, `nip05_handle`
- `$fillable = ['npub', 'pubkey', 'email', 'no_email', 'application_text', 'archived_application_text']`
3. **`app/Models/Vote.php`**
- Sensible Felder: `einundzwanzig_pleb_id`, `project_proposal_id`, `value`
- `$fillable = ['reason']` – alle anderen Felder müssen programmatisch gesetzt werden
4. **`app/Models/ProjectProposal.php`**
- Sensible Felder: `einundzwanzig_pleb_id`, `accepted`, `sats_paid`, `slug`
- `$fillable = ['name', 'support_in_sats', 'description', 'website']`
5. **`app/Models/Election.php`**
- Sensible Felder: `year`, `candidates`, `end_time`
- `$fillable` sollte leer sein – nur Admin-gesteuert
**Mittleres Risiko (mit `created_by` auto-fill in boot):**
6. **`app/Models/Venue.php`** – `$fillable = ['name']` (slug & created_by auto-generiert)
7. **`app/Models/MeetupEvent.php`** – `$fillable = ['start']` (meetup_id, created_by, attendees guarded)
8. **`app/Models/CourseEvent.php`** – `$fillable = ['from', 'to']` (course_id, venue_id, created_by guarded)
9. **`app/Models/Course.php`** – `$fillable = ['name', 'description']` (lecturer_id, created_by guarded)
10. **`app/Models/Meetup.php`** – `$fillable = ['name']` (city_id, created_by, slug, github_data, simplified_geojson guarded)
11. **`app/Models/Lecturer.php`** – `$fillable = ['name']` (active, created_by, slug guarded)
12. **`app/Models/City.php`** – `$fillable = ['name']` (country_id, created_by, slug, osm_relation, simplified_geojson guarded)
**Niedrigeres Risiko (Lookup/Reference-Daten):**
13. **`app/Models/Event.php`** – `$fillable = []` (alle Felder: event_id, parent_event_id, pubkey, json, type sind extern gesteuert)
14. **`app/Models/RenderedEvent.php`** – `$fillable = []` (event_id, html, profile_image, profile_name alle system-generiert)
15. **`app/Models/Profile.php`** – `$fillable = ['name', 'display_name', 'picture', 'banner', 'website', 'about']` (pubkey, deleted, nip05, lud16, lud06 guarded)
16. **`app/Models/Category.php`** – `$fillable = ['name']`
17. **`app/Models/Country.php`** – `$fillable = ['name']` (code, language_codes guarded)
18. **`app/Models/Notification.php`** – `$fillable = ['name', 'description']` (einundzwanzig_pleb_id, category guarded)
### Vorgehen
1. Jedes Model öffnen und `$guarded = []` durch das oben definierte `$fillable` Array ersetzen
2. Prüfen, ob bestehende `::create()` oder `::update()` Aufrufe noch funktionieren – ggf. müssen explizite Feld-Zuweisungen ergänzt werden
3. Für jedes geänderte Model einen Pest-Test schreiben, der verifiziert, dass Mass Assignment von sensiblen Feldern blockiert wird
4. `vendor/bin/pint --dirty` ausführen
5. Bestehende Tests laufen lassen: `php artisan test --compact`
### Akzeptanzkriterien
- Kein Model hat mehr `$guarded = []`
- Alle sensiblen Felder (status, paid, accepted, created_by, slug, IDs) sind NICHT in `$fillable`
- Bestehende Features funktionieren weiterhin (Tests grün)
- Neue Tests verifizieren Mass Assignment Protection
|
2026-02-11 21:13:36 +01:00 |
|