Why I Stopped Fighting Burp and Built My Own Listener
After struggling with Burp Suite and Caido during a financial app pentest, a security researcher decided to stop acting as a proxy and build a custom listener.
Stock photo for illustration only, not from the actual event
- Burp Suite and other proxies frequently timed out during internal network security tests.
- The researcher built a browser extension paired with a custom local listener program.
- Successfully bypassed CORS limitations and eliminated traffic interception bottlenecks.
- Uncovered critical authorization bypasses by comparing endpoints between Sales and Super Admin accounts.
During a penetration test on an internal student loan servicing web application for a financial company — restricted by IP filtering and VPN access — a security tester was provided with two testing accounts: a sales account and a super admin account. However, on the very first day, Burp Suite simply failed to function. It was neither slow nor buggy; it just refused to work altogether.
He checked everything from his new laptop and certificates to corporate security software like SeroPOS, even asking IT to uncheck it under the assumption that it was intercepting traffic before Burp could detect it. Yet, the issue persisted across Burp, Caido, and even standard browsers like Firefox and Internet Explorer running without a proxy.
Stock photo for illustration only, not from the actual event
A pattern eventually emerged. Four or five requests would process successfully before the application would stall and timeout. After 15 to 30 minutes, sometimes an hour, it would resume working briefly for a few requests before stopping again. Stranger still, sending the exact same request twice succeeded, but making any modification—such as adding a quote or a script tag—resulted in complete silence with no response. This cost three days of testing with barely any usable traffic captured, severely denting confidence.
From an architectural standpoint, proxy tools like Burp Suite intercept, decrypt, and re-transmit every single request. If the underlying application connection is already unstable, introducing a man-in-the-middle decryption tool only compounds the latency and causes connection drops. Moving from interception to passive observation is a robust architectural shift in network debugging.
While stuck fighting the proxy, he shifted to reading the application's JavaScript directly in the browser without any proxy needed, helping him understand the loan application flow, user roles, and frontend-backend communication. This realization hit him: the problem wasn't his setup, but the proxy itself sitting in the middle deciding whether requests survived. If the connection was unstable, a decryption tool made it worse.
He stopped trying to sit in the middle and chose to simply observe instead. Using the browser's Network tab, he built a small extension to grab traffic and save it to localStorage. While it worked initially, localStorage quickly bogged down the browser when handling thousands of requests across more than 200 endpoints.
The lesson learned was clear: the browser is great for observing traffic, but terrible for storing it. He separated the responsibilities by having the extension instantly transmit requests without holding onto anything, while writing a lightweight local listener program to accept requests at /capture and save them reliably without performance degradation.
The first hurdle encountered was CORS. When the extension sent data to the listener on a different address, the browser triggered a preflight request. Because his listener lacked a response handler for preflight checks, requests failed instantly until he implemented the correct response headers.
This concept mirrors tools like mitmproxy, with the crucial difference of abandoning the proxy role in favor of watching, saving simply, and exporting flexibly. Once traffic flowed smoothly without timeouts, he crawled the application as the sales account, repeated the crawl as the super admin, and compared the two endpoint lists.
Many endpoints intended exclusively for admins worked seamlessly when accessed using the sales account token due to a lack of backend authorization checks. This allowed critical actions such as changing other users' passwords, modifying emails, disabling 2FA, updating phone numbers, or creating unauthorized financial records. While client data remains confidential, the core vulnerability pattern remains consistent: frontend role checks without backend validation.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment