Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Missing access checks on caller-supplied video/space IDs (4 endpoints, PRs open)

Đang mở
  • Có gì không ổn?
#2,033 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
next.js, typescript
Lĩnh vực
api, authorization, security

Hướng nghiên cứu

Xem xét các PR #2029–#2032 trước khi bắt đầu, sau đó đọc VideosPolicy.canView, getSpaceAccess, /api/analytics/route.ts và Analytics.tsx để hiểu các kiểm tra hiện có. Được xem là hoàn tất khi bốn điểm truy cập được liệt kê thực hiện các kiểm tra quyền truy cập phù hợp và trả về các phản hồi not-found khi bị từ chối, mà không lặp lại công việc đã được các PR đang mở bao phủ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

While working on #1982 I audited every entry point in apps/web that accepts a caller-supplied resource ID, since that advisory looked like an instance of a pattern rather than a one-off. It was — I found four, and opened a PR for each.

The pattern

Cap has a solid access-control primitive in VideosPolicy.canView, and most code uses it. The failures all have the same shape: a second entry point to the same data that skips the check. Server actions are the main way this happens, because a "use server" function is independently callable by any client and does not inherit whatever gating its usual API route does.

What I found

PR Entry point State before Impact
#2029 newComment action authenticated only write comments/reactions into anyone's private video, notifying the owner
#2030 getVideoAnalytics action no auth at all read view counts of any private video
#2031 getSpaceVideoIds / getFolderVideoIds authenticated only enumerate video IDs in spaces of orgs you aren't in
#2032 /api/video/transcribe/status authenticated only read transcription status of anyone's private video

Two are worth calling out specifically:

#2030 is the sharpest. /api/analytics/route.ts does gate on canView, with a comment stating it exists so private view counts aren't disclosed. But getVideoAnalytics is a server action with zero auth of any kind — no getCurrentUser, no policy — and a "use client" component (Analytics.tsx) already calls it directly. The route's protection is bypassable by calling the action the same way the app's own client code does.

#2031 leaks IDs, which are the key to everything else. Video IDs are what /s/{videoId} and the other video endpoints take, so enumerating a private space's ID set is useful to an attacker even before any per-video check runs.

Sweep result

After these four, I re-swept: no remaining videoId-taking server action or API route in apps/web lacks an access check. Two files still show up in a naive grep but are fine on inspection — /api/notifications takes no ID and only returns the caller's own rows, and /api/tools/loom-download takes a Loom video ID, not a Cap resource.

Notes on the fixes

  • Every fix reuses an existing primitive (VideosPolicy.canView, or getSpaceAccess for the space paths) rather than introducing new logic, so they inherit the full existing model — owner, org, space, public, password, email-domain restrictions.
  • For #2031 I used getSpaceAccess and not requireSpaceManager: these are read paths, and requiring manager would have locked out ordinary members.
  • Denials return "not found" rather than "denied" throughout, so none of them become an oracle for which IDs exist.
  • Each PR is 1–2 files. They're independent and can be merged in any order.

Happy to consolidate them into a single PR if you'd prefer to review it that way.

cc @richiemcilroy

Ngôn ngữ chính
Rust
Star
22.8k
Fork
2k
Merge trung bình
10 giờ 41 phút
Pull request đã merge (30 ngày)
89

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.