Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Introduction: When Simplicity Betrays SecurityIDORs represent dangerous security defects which exist between convenience features and vulnerabilities in modern web application development. A descriptive analysis of a real-life IDOR vulnerability will demonstrate how an innocent chat transcript allowed unauthorized access to sensitive user passwords.We will analyze both essential technical aspects of the weak point and investigate the underlying reasons behind simple security flaws that continue to exist and provide strategies for creating effective defense mechanisms..Black-box TestingLab URL - https://app.hackthebox.com/challenges/Kryptos%2520SupportAt first glances, we note that we are not given source code for this lab. So we take an peak and we got an login page and a portal to enter some details. So quickly our instincts kick, what if we can manipulate the portal and steal cookies of some user? Thats precisely what we are doing at the first part of this challenge. You can read more about stealing cookies with xss online, or refer to previous series in this web pentest blog here . Alternatively you can also take an peek at their official writeup.Once you got intial access, look around in the settings and you see an option to reset the password. Now if you look the request behind the reset, it is not validated with any token, and we find uid parameter. What if we change the value? You can fuzz the uid values, using burp intruder, we see that with uid value as 1 we can change the password for admin user. And with that we should get our flag. Grey-box TestingUnlike the previous blogs, we had white box testing, since online I could not find any (yes I am aware of ctfs on ctf time that post web challenges with source code, but I dont have access to any of its source code or too lazy to find and set up from online, if you are interested you can very well do that as well), but I have found another way, a portswigger lab that kinda explains web application via javascript. Even though this is an apprentice lab (easy one) there is still a lot to learn from and the first two times I solved this lab, I overlooked these tiny details. As a pentester it's our duty to report such trivial findings The Discovery: Patterns in the Digital FabricSecurity testing often begins with observation - looking for patterns that might reveal underlying weaknesses in an applications architecture. During a recent engagement, the applications proxy history revealed an intriguing endpoint:/download-transcript/{ID}.txtWhat made this endpoint immediately suspicious was its adherence to the classic IDOR pattern - a resource accessed via a simple numeric parameter that appeared to be an internal identifier. This pattern often suggests direct mapping between the URL parameter and backend database records, which represents a potential security boundary that can be tested.Vulnerability Analysis: Peeling Back the LayersThe Technical MechanicsAt its core, this vulnerability stemmed from a fundamental architectural flaw: the application permitted users to access resources through direct references to internal implementation objects - in this case, transcript files - without implementing proper authorization checks.Lets break down the vulnerable request pattern:GET /download-transcript/2.txt HTTP/2Host: 0a25009004c1db6081ed89ff001e0026.web-security-academy.netCookie: session=kp1BS7J2wYMZPvEWYVEGbIYnB4ktSHz5User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36Accept: */*The critical vulnerability lies in how the application processes the identifier 2 in the URL path. This numeric ID serves as a direct reference to a specific transcript file stored on the server. The application retrieves the requested file based solely on this identifier, without verifying whether the currently authenticated user should have access to it.The Exploitation JourneyMy investigation followed a methodical approach:Observation: Identified the /download-transcript/2.txt endpoint in the HTTP history, which showed a pattern suggestive of direct object referencing.(The http request which got highlighted in blue.) Hypothesis Formation: Theorized that changing the numeric ID might allow access to other users transcripts if proper authorization checks were absent. Controlled Testing: Created a repeater tab in Burp Suite to test accessing /download-transcript/1.txt, maintaining the same session cookie but altering only the resource identifier. Vulnerability Confirmation: Successfully retrieved the transcript with ID 1, which belonged to a different user and contained sensitive information, including a password. The successful retrieval of this unauthorized transcript confirmed the vulnerability. The application failed to validate whether the requesting user had legitimate rights to access the resource identified by 1, instead blindly retrieving and returning whatever data was associated with that identifier.Technical Deep Dive: The Anatomy of the VulnerabilityTo understand this vulnerability at a deeper level, lets examine the client-side implementation that interacts with this endpoint. This provides crucial insight into how the vulnerability manifests from end to end. From the above image, we got two javascript files, one is chat.js and another is viewTranscript.js, lets take an peak at viewTranscript.js. This JavaScript function in the application revealed the transcript download mechanism:function viewTranscript(downloadTranscriptPath) { var chatForm = document.getElementById("chatForm"); var viewTranscriptButton = document.createElement("button"); viewTranscriptButton.setAttribute("id", "download-transcript"); viewTranscriptButton.setAttribute("class", "button"); viewTranscriptButton.innerText = "View transcript"; viewTranscriptButton.onclick = viewTranscript; chatForm.appendChild(viewTranscriptButton) function viewTranscript() { var chatArea = document.getElementById("chat-area"); var messages = chatArea.getElementsByClassName("message") var transcript = [] for (var i = 0; i < messages.length; i++) { var message = messages.item(i) transcript.push(message.getElementsByTagName("th").item(0).innerText + " " + message.getElementsByTagName("td").item(0).innerText) } var xhr = new XMLHttpRequest(); xhr.onload = function() { window.location = xhr.responseURL; } xhr.open("POST", downloadTranscriptPath); data = new FormData(); data.append("transcript", transcript.join("<br/>")); xhr.send(data); }};This function reveals several critical details, and we draw the following conclusions:The application collects chat messages from the DOM and sends them as a transcript to the server via a POST requestThe server processes this data and returns a redirect to a URL where the transcript can be downloadedThe redirect leads to the /download-transcript/{ID}.txt endpoint, where the ID is assigned by the serverThe vulnerability exists due to the following reasons:The server generates sequential or predictable IDs for transcriptsWhen users request a transcript file, the application fails to verify ownershipThe server blindly trusts the ID parameter, assuming that the request is legitimate if it contains a valid session cookieExploitation Refinement: From Discovery to ImpactFrom Theory to ProofHaving identified the vulnerability, I systematically verified its severity:Initial access: Successfully accessed /download-transcript/1.txt despite it belonging to another user Content analysis: The transcript contained sensitive information including: Conversation details A user password (the most critical finding) Potentially other sensitive data exchanged during chat sessions Pattern analysis: The sequential nature of the IDs (1, 2, 3) suggested all transcripts might be accessible, indicating a widespread access control failure.Suggested Remediation Strategies:Addressing IDOR vulnerabilities requires a multi-layered approach:Immediate Tactical FixesImplement Resource-Level Authorization Checks function downloadTranscript(transcriptId, currentUser) { // Retrieve the transcript object transcript = getTranscriptById(transcriptId) // Verify ownership or permission if (transcript.owner != currentUser.id && !currentUser.isAdmin) { return AccessDeniedError } // Proceed with download if authorized return transcript.content }Use Indirect Reference Maps Instead of exposing internal IDs directly, implement a mapping layer: // Server-side map (stored in session) userResourceMap = { "a7f392e": "transcript_2" // User-specific mapping } // URL becomes /download-transcript/a7f392e // Server translates the reference before retrieving the resourceReferences:https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-208ahttps://github.com/urma/indirect-referencehttps://www.nodejs-security.com/blog/secure-javascript-coding-to-avoid-insecure-direct-object-references-idorIDOR hunting ChecklistNote that this list is not exhaustive and do take it from grain of salt as it comes from previous ctf experiences and vulnerable labs. 1. Check for any ID value in URL 2. Check for any guessable or numbers that can be altered in URL or in any URL parameters. 3. Check how request on the web application gets processed in burp suite and see if you can change any numeric values. 4. Dont forget to check cookies, sometimes they might be encoded with base64, or any base or hex values, sometimes understanding how these cookies are applied on web browser might allow us to create our own cookies for users like admin or administrator. 5. Chain IDOR with other vulnerabilities. (Often some other vulnerability like stealing cookie or authentication bypass using SQL Injection often leads us to an endpoint that is vulnerable to IDOR)ConclusionWe have explored the IDOR vulnerability to demonstrate that simple implementation should always be coupled with stringent authorization measures for web security. IDOR vulnerabilities present two dangerous characteristics because they combine simple conceptual nature with devastating impact. Such vulnerabilities cause severe data breaches because hackers need no advanced exploit techniques nor specific tech expertise to take advantage of them.IDOR vulnerabilities can only be properly addressed through the combination of strong authorization controls and indirect reference maps, unpredictable identifiers and deep defense security measures. Security requires proper foundation instead of complex algorithms or sophisticated defense systems to succeed. The comprehension of these security flaws together with suitable protection methods enables us to develop systems that secure user-sensitive information against virtual attackers concealed within electronic frameworks.At the end of the day, major application security vulnerabilities emerge from basic human mistakes yet cause the most extensive damage.

Introduction: When Unlimited Tries Becomes a Hackers Best FriendEnvision a vault that grants the crims to propose its procedure time and againno enforcers, no freezes, no repercussions. Replace the vault with Instagram 2FA, GitHub accounts, OTP, and you have a $25,000 lesson in failed auth. In this blog we deep dive, we and poke around three true-world case studies where a simple blunder , overlooked rate limits could cost a lot to these companies if not fixed. Do take this with grain of salt as an learning experience, and ==lets be realistic in 2025 its hard to earn bounty worth thousands of dollars for just lack of rate limitings as every website now is enforcing rate limits==. So do keep that in mind while you are reading this blog. Case Study Breakdowns1. Cracking the Code: How a Missing Rate Limit Led to a $5k Account TakeoverVulnerability TypeMissing rate limiting on OTP verification leading to account takeoverImpactFull account takeover via OTP brute-forcingSignificanceExposed authentication bypass in a secure OTP systemBounty Awarded$5,000Bug Bounty WriteupRead the full writeup hereVisual analogy: No rate limits = a lock that lets you try every key.Introduction: The Hole in the Digital LockPicture a bike lock with 1 million combinationsunbreakable at first glance. What if the lock allowed you attempt every combination in seconds with no penalty? In essenza quel che accaduto a quando lesploratore MRD7 ha trovato un rate limit lost su di un 6 digitale OTP (One-Time Password) sistema. This mistake allowed the attackers to brute-force their way into user accounts (making a secure authentication mechanism into a one way revolving door). Why does this matter? OTPs are the digital worlds final safety measures on account security. If there was no rate limit, even a 6-digit code can easily be broken. For the target companya mature company with dozens of resolved reportsa staggering new bug was a painful lesson: no system is completely secure. Vulnerability Explanation: The Math Behind the MayhemOTPs are like perishable codes: they are so made to be used once only and become invalid as soon as possible. But heres the rub: if an attacker can attempt all possible combinations unimpeded, then the odds are in their favor. A 6-digit code has 1 million permutations (000000999999). Although this is enormous, current cloud infrastructure can burn through these permutations in minutes. Why its a big deal: Probability > protection: At 100 guesses per second (and by using automated tools), 1 mil combo will take us 2.7 hours to test No noise, no surprise: With no rate limiting, the target server didnt observe any blocked or flagged attempts. Imagine it like a burglar talking softly alone every single key on a keychain until one unlockswhether than instead has a digital keyring as well as then there is a script burglar. Exploitation Process: The Silent Brute-Force AttackMRD7s approach was methodical: Target Selection: A personals lead program and invite-only with OTP login. Reconnaissance: Noticed that the OTP was numeric (6 digits) and questioned: What is stopping me from guessing all possible codes? Sent repeated OTP attempts. No end to Rate Limits, lockouts, CAPTCHAS. Jackpot. Automation: Deployed a script to brute-force the OTP field. The labor was done by the cloud servers, which processed thousands of combinations quickly. The Attackers Mindset: Low-hanging fruit: Always brute force OTP fields.Scale leverage: Cloud tools take theoretical vulnerabilities and convert them to ones that are exploitable. Impact & Mitigation: Turning Oops into Oh NoWorst case: Attackers take over any account by brute-forcing the OTP, no phishing, no malware, just math. How to fix it: * Rate limiting: Block IP-counts/corresponding accounts after 5-10 failed attempts. Lockouts: Instantly block OTP attempts upon multiple fail attempts. require the CAPTCHAs to noticeably slow down the pace of automated scripting. Anomaly detection: Notify on increases in OTP attempts. The company fixed the bug in 15 hours, but this accident teaches a vital lesson: there automate process, there must automate defence. As MRD7 showed, the smallest things a mere lack of speed bump, for instance can bring down the biggest highs. Stay curious, test mercilessly, and never forget: in the world of cybersecurity, complacency is the thing most desired by exploiters. 2. Bypassing GitHubs Digital Guard: A $15k Lesson in Rate Limit FailuresVulnerability TypeRate limit bypass enabling OTP brute-forcingImpactAccount takeover via unlimited OTP attemptsSignificanceCompromised GitHub accounts risk third-party platform breachesBounty Awarded$15,000Bug Bounty WriteupOriginal ArticleVisual analogy: No rate limits = a vault that never stops spinning. Introduction: When Unlimited Attempts Becomes a WeaponPicture a vault door with a 6-digit combination lock. Now imagine the vault lets you spin the dial endlessly, never locking you outno matter how many wrong guesses you make. Thats exactly what researcher Taniya Agarwal discovered in GitHubs OTP verification system: no rate limits on login attempts, turning a security feature into a hackers playground. Why this matters: GitHub isnt just a code repositoryits a gateway to thousands of third-party services (CI/CD tools, cloud platforms, etc.). A compromised account here can ripple across the digital ecosystem. For a platform trusted by millions, this oversight was a wake-up call: even giants stumble over basic security controls. Vulnerability Explanation: The Infinite Guess GameOTP authentication performs through two main mechanisms which combine randomness with limited chance attempts at authentication verification. When the second security measure proves inadequate attackers can make numerous unlimited attempts to guess the code. A weakness arose from GitHub implementing a six-digit OTP with one million probable options which attackers could easily break into because the method allowed continuous consecutive attempts at guessing without any hindrance. A design failure in parameter implementation made OTP brute-forcing easier because developers provided separate parameters for each digit such as when they set digit1=1&digit2=2. The analogy presents the security hack as a simple 6-piece puzzle testing approach that brings substantial complexity reduction to the process. Exploitation Process: How a Hacker Outsmarted the VaultThrough the perfect use of design flaws Taniya executed a brilliant attack. The vulnerability researcher selected the OTP-based login method as her primary target due to its crucial position in GitHubs security framework. The tester performed reconnaissance to discover the system lacked any restrictions on number of attempts during their manual testing phase. The security probe Cluster Bomb within Burp Suite allowed Taniya to execute simultaneous attacks on all 6 OTP digits. The attack was simplified because Taniya separately targeted each digit in the OTP system. The Attackers Mindset: Tesseracts attain through GitHub access represent professional developers most valuable keys. The observation of structure within the system led to the question about splitting OTP across six distinct text fields. A problematic validation approach becomes noticeable when a system separates a confirmation code into multiple segments. Burp Suite enabled payload configuration to make an initially complex one-million-guess problem more manageable. Impact and Mitigation: When a Single Flaw Unlocks Every DoorThe hijacking of GitHub accounts enables attackers to obtain software code and data while they can introduce malware into the platforms which intersect with AWS and npm. Fixes implemented: The system locks out users after five to ten unsuccessful tries to verify with OTP authentication. The OTP parameters exist as a whole concatenated string when using the parameter consolidation method (like otp=123456). Monitoring: Alert on rapid-fire OTP attempts. The swift GitHub repair confirmed the truth that security depends more on behavior prediction of humans and bots rather than algorithmic efforts. Taniya received $15k from the bounty program to show us how even minor technical flaws can breach the most imposing security structures. You should preserve a sense of paranoia while performing aggressive tests and never assume rate limits will be present. 3. Masked Attacker: How IP Rotation Broke Instagrams 2FA GuardVulnerability Type2FA bypass via IP rotation during OTP brute-forcingImpactDisabling 2FA protection for victim accountsSignificanceCompromised account security for millions of Instagram usersBounty Awarded$5,000Bug Bounty WriteupOriginal Article (link placeholder)Visual analogy: IP rotation = changing masks to avoid detection. Introduction: The Disappearing ShieldPicture yourself owning a home with a security system that instantly deactivates if an individual press 10,000 times his security code in front of your house while wearing 10,000 different disguises. What the scientist did next is in a way similar towhat happened when the researcher abused Instagrams 2FA mechanism with IP rotation a tool that allowed them to crack through OTP codes while trying to avoid rate limits. Deadline significance: Two-factor authentication (2FA) is the last protection against account takeovers. By bypassing it, attackers could block users from logging into their rival accounts, also nullify with recovery options and jump to interconnected platforms to Facebook. Vulnerability Explanation: The Chameleon AttackInstagrams 2FA stack had a major flaw: it counted failed OTP attempts per IP address. Attackers exploited this by: Rotating of IP Addresses for every guess (like changing the costumes) Bypassing the rate limits set to prevent brute force Causing Instagram to auto-delete victims phone number after a successful guess Analogy : Much like a thief attempting different combination of key on your lock, but coming up with a different face each time so that your security cameras never recognize it as the same individual. Exploitation Process: The Proxy DanceHeres how the attack unfolded: Inspiration: The researcher leveraged on a stub (Neeraj Sonaniyas phone number removal bug) that was already documented. Recon: Checked if Instagrams OTP method blocked rate guesses from a single IP. Tool Setup: Configured Burp Suite with: IP rotation (abordado via AWS API Gateway/proxy services) Cluster Bomb attack to brute-force 6-digit OTPs Triggering Impact: After a successful OTP guess, Instagram ended up automatically filtering the victims phone number from their account. The Attackers Mindset: Building on certainly prevailing study: Clearly my numbers horizontally removed, weapons of mass destructions I can sabotage OTP systems? **Misusing cloud infra: IP rotation is low cost/heavy scalewhy not? Timing is everything: Attacked the account sign up flow where defenses are more down. Impact and Mitigation: When Security BackfiresWorst-case scenario: Hackers, the ones with malicious intents could potentially steal and impersonate social media accounts of high profile individuals for their own personal profit. How Instagram fixed it: Globally rate-limited OTP attempts (regardless of IP) Removed auto-removal of phone numbers after OTP validation Added confirmations before changing 2FA settings Conclusion: The$25k Bug with a Billion Dollar PatternA haunting pattern repeated in these casestudies: where security teams downplayed brute-force risks, attackers oversold creativity. The takeaways?Regulatory limits are non-negotiable: Regardless of whether it is protecting OTPs, 2FA or APIs for that matter by way of throttling youalways act as the gatekeeper.Context determines impact: A GitHub vulnerability isnt merely a code leakits a skeleton keyinto ecosystems. Hackers are systems thinkers: IP rotation + OTPflaws = 2FA removal. Always ask the question: Whats thedomino effect?To defenders,these $5k-$15k bounties are warning flares complacency is your cheapest exploit. For hackers? Theyreevidence that even giants leave vault doors spinning.