Listen to this Post
The vulnerability is an Insecure Direct Object Reference (IDOR) in the `/api/share/{hash}` endpoint’s deletion handler. The `shareDeleteHandler` function in `/http/share.go` (lines 72-82) processes DELETE requests by taking a share hash directly from the URL path. It then passes this hash to the `d.store.Share.Delete(hash)` method without performing any authorization check. The critical flaw is the function’s failure to verify that the share link being deleted (link.UserID) actually belongs to the currently authenticated user (d.user.ID). This missing ownership validation allows any authenticated user who knows or can guess a share’s unique hash to delete any other user’s shared links by simply issuing a DELETE request to that endpoint, using only their own valid JWT token for general authentication.
Platform: FileBrowser
Version: < v2.23.1
Vulnerability: IDOR
Severity: Critical
date: 2024-10-15
Prediction: 2024-11-05
What Undercode Say:
curl -X DELETE -H "Authorization: Bearer <USER_B_JWT>" http://filebrowser.local/api/share/MEEuZK-v
// Vulnerable Code Snippet (/http/share.go)
var shareDeleteHandler = withPermShare(func(_ http.ResponseWriter, r http.Request, d data) (int, error) {
hash := strings.TrimSuffix(r.URL.Path, "/")
hash = strings.TrimPrefix(hash, "/")
if hash == "" {
return http.StatusBadRequest, nil
}
err := d.store.Share.Delete(hash) // Missing ownership validation
return errToStatus(err), err
})
How Exploit:
1. Attacker authenticates.
2. Discovers target share hash.
3. Sends crafted DELETE request.
4. Share deleted unauthorized.
Protection from this CVE
Update to FileBrowser version v2.23.1 or later, which includes a patch that adds the necessary authorization check to verify the requesting user owns the share before deletion is permitted.
Impact:
Data loss
Service disruption
Breached confidentiality
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
