review · segments
Untitled session
claude 49 events 1 segments main
segment 1 of 1
Security-review the five Livewire Storage components and report findings
The reviewer enumerated app/Livewire/Storage/ (FreeTierCard, FreeTierMigrationBanner, QuotaRecommendation, StorageProfileForm, StorageProfileList) and their paired Blade views, confirmed the mounting route middleware (auth+verified on storage-profiles), and audited each component against a Livewire threat model (client-callable methods, writable public props, IDOR, mass assignment, XSS, token/key exposure, rate limiting). Grep checks found no {!! !!} unescaped output, no raw SQL, and ownership scoping on deletes/migrations was present. The reviewer then traced StorageProfileForm.save()/testConnection() through StorageProfileValidator.checkCredentials() and StorageProfileFilesystemFactory.client(), discovering that the public endpoint_url property (validated only required|url|max:255) flows straight into the AWS S3 client endpoint, enabling authenticated SSRF against internal/metadata addresses with an error-message oracle and no rate limiting.
outcome
A concise findings report was produced: HIGH SSRF via unrestricted endpoint_url in StorageProfileForm (with metadata/RFC1918 exploit and denylist fix), plus a LOW defense-in-depth note on plaintext S3 credential public props round-tripping through Livewire requests.
next steps
- Implement a custom validation rule resolving endpoint_url's host and rejecting loopback/link-local (169.254.169.254)/RFC1918/.internal ranges
- Consider disabling redirects on the Guzzle client the S3 SDK uses
- Add rate limiting to the testConnection/save credential-check flow
- Consider not echoing raw AWS SDK exception details back to the user to remove the SSRF oracle
key decisions
- Review-only: no files modified
- Treat all public Livewire props/methods as attacker-controlled unless #[Locked]
- Report precision over volume — only flag components with genuine issues (clean components omitted)
open questions
—
2 days ago → 2 days ago