Security: Deleted content exposure + revision history IDOR via sequential IDs
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
調査の方向性
影響を受ける2つのエンドポイントについて、まず AnswerService.Get と GetObjectTimelineDetail から始め、そのアクセスチェックを SearchList、GetRevisionList、GetQuestion と比較します。削除済みおよび保留中の質問、回答、リビジョンがどのように読み込まれるかを追跡します。未認証ユーザーに削除済みの回答が公開されず、認証済みユーザーにも削除済みまたは保留中のリビジョンの内容が公開されなくなり、許可されたコンテンツには引き続きアクセスできれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Summary
Two information disclosure issues allow access to deleted/pending content:
1. Deleted Answer Content via GET /answer/api/v1/answer/info (Low-Medium)
`AnswerService.Get()` calls `answerRepo.GetByID()` which fetches answers by raw ID with no `status != deleted` filter. Deleted answers are returned with full content to unauthenticated callers.
Secure comparison: `SearchList` correctly filters: `session.Where("status != ?", entity.AnswerStatusDeleted)`
2. Revision History IDOR via GET /answer/api/v1/activity/timeline/detail (Medium)
`GetObjectTimelineDetail` fetches revision content by sequential integer ID (`autoincr BIGINT`). No check for whether the associated question/answer is deleted or pending. Any authenticated user can enumerate `revision_id=1,2,3...` to read full content of deleted/pending questions and answers.
Secure comparison: `GetRevisionList` correctly checks `objInfo.IsDeleted()` before showing history. `GetQuestion` blocks access to deleted/pending content.
Impact
- Bypasses content moderation (admin-deleted content remains accessible)
- Reveals pending-review content before publication
- Sequential revision IDs make enumeration trivial
Discovery
Found through automated security research comparing content visibility controls across endpoints.
- 主要言語
- Go
- スター
- 15.7k
- フォーク
- 1.4k
- 平均マージ
- 1日 20時間
- マージ済み PR(30日)
- 6
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/answer のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
Hardening: cap the invite_user list size in UpdateQuestionInviteUser to bound notification fan-out オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
Gravatar hash is computed from the un-lowercased email, so mixed-case accounts render an identicon オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
Bob Shell support オープンenhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
santhosh-tekuri/jsonschema#276 ·