<div class="key-takeaways"><ul><li>Burp Suite และ Proxy อื่นๆ ล่มและหมดเวลาบ่อยครั้งขณะทดสอบระบบเครือข่ายภายใน</li><li>นักทดสอบจึงหันมาสร้างเบราว์เซอร์เอ็กเทนชันร่วมกับโปรแกรม Listener ส่วนตัว</li><li>แก้ไขปัญหา CORS และหลีกเลี่ยงการขัดขวางทราฟฟิกได้อย่างราบรื่น</li><li>ค้นพบช่องโหว่สำคัญด้านความปลอดภัยหลังเปรียบเทียบ Endpoint ระหว่างบัญชี Sales และ Super Admin</li></ul></div><p>ระหว่างการทำเพนเทสต์ (Pentest) แอปพลิเคชันเว็บประเภทระบบกู้ยืมเงินนักศึกษา (Student Loan Servicing) ภายในองค์กรที่มีการกรองไอพีและใช้งานผ่าน VPN นักทดสอบระบบรายหนึ่งต้องเผชิญกับอุปสรรคสำคัญ โดยเขาได้รับบัญชีสำหรับทดสอบมา 2 บัญชี ได้แก่ บัญชีพนักงานขาย (Sales) และบัญชีผู้ดูแลระบบสูงสุด (Super Admin) แต่ตั้งแต่วันแรกที่เริ่มงาน โปรแกรมดักจับทราฟฟิกยอดนิยมอย่าง Burp Suite กลับใช้งานไม่ได้เลย แม้จะไม่ใช่เพราะความช้าหรือบั๊ก แต่มันไม่ยอมทำงานตามที่ควรจะเป็น</p><p>เขาใช้เวลาตรวจสอบทุกอย่าง ตั้งแต่แล็ปท็อปเครื่องใหม่ ใบรับรองความปลอดภัย (Certs) ไปจนถึงซอฟต์แวร์ความปลอดภัยอย่าง SeroPOS ที่ทางไอทีติดตั้งไว้บนเครื่องบริษัท โดยขอให้ยกเลิกการทำงานในส่วนดังกล่าวเพราะคิดว่ามันอาจจะดักจับทราฟฟิกไปก่อนที่ Burp จะมองเห็น แต่ปัญหาก็ยังคงอยู่ ไม่ว่าจะเป็นบน Burp, Caido หรือแม้แต่บน Firefox และ IE ที่ไม่ได้ผ่านพร็อกซี่ก็ตาม</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/burp_suite_pentest_ms8h7xig_inline_1_58cf48edce.jpg" alt="browser developer tools network tab" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div></p><p>หลังจากนั้นรูปแบบบางอย่างก็ปรากฏขึ้น คำขอ (Requests) ประมาณ 4 ถึง 5 รายการแรกสามารถส่งผ่านไปได้ด้วยดี ก่อนที่ระบบจะหยุดชะงักและเกิดอาการหมดเวลา (Timeout) จากนั้นผ่านไป 15 ถึง 30 นาที หรือบางครั้งอาจนานถึงหนึ่งชั่วโมง มันก็จะกลับมาใช้งานได้อีกครั้งสำหรับคำขออีกเพียงไม่กี่รายการแล้วหยุดไปอีก ที่แปลกไปกว่านั้นคือ หากเขาส่งคำขอเดิมซ้ำอีกครั้งทันทีมันจะทำงานได้ แต่หากมีการเปลี่ยนแปลงใดๆ เช่น เพิ่มเครื่องหมายคำพูด แท็กสคริปต์ หรือสิ่งผิดปกติ ระบบจะนิ่งเงียบไปทันทีไม่มีการตอบกลับใดๆ ส่งผลให้เวลาผ่านไป 3 วันโดยแทบไม่ได้ทราฟฟิกที่ใช้งานได้เลย ซึ่งสร้างความบั่นทอนความมั่นใจอย่างมากโดยเฉพาะกับผู้ที่ยังใหม่ในวงการ</p><div class="ai-insight"><p>ในทางเทคนิคแล้ว เครื่องมือประเภท Proxy เช่น Burp Suite มีหน้าที่ถอดรหัสและส่งต่อทุกคำขอ (Decrypt and Resend) ซึ่งหากระบบเครือข่ายต้นทางหรือแอปพลิเคชันมีความไม่เสถียรอยู่แล้ว การแทรกเครื่องมือระดับกลางนี้เข้าไปยิ่งเพิ่มภาระและทำให้การเชื่อมต่อล่มได้ง่ายขึ้น แนวคิดการ "เฝ้าดูแทนที่จะขวางกั้น" จึงเป็นทางออกทางสถาปัตยกรรมที่ช่วยลดจุดพังของระบบได้อย่างมีประสิทธิภาพ</p></div><p>ในระหว่างที่ติดขัดกับการใช้พร็อกซี่ เขาจึงเปลี่ยนไปอ่านโค้ด JavaScript ของแอปพลิเคชันแทน ซึ่งทำให้เขาเข้าใจกระบวนการสมัครสินเชื่อ บทบาทหน้าที่ และวิธีที่หน้าบ้านสื่อสารกับหลังบ้าน โดยไม่ต้องพึ่งพาพร็อกซี่เลย จากจุดนั้นทำให้เขาตระหนักว่าปัญหาไม่ได้อยู่ที่การตั้งค่าของตนเอง แต่เป็นเพราะพร็อกซี่ที่ทำหน้าที่เป็นตัวกลางคอยตัดสินใจว่าคำขอใดจะรอดชีวิต ซึ่งหากการเชื่อมต่อระหว่างตัวเขากับแอปพลิเคชันมีปัญหาอยู่แล้ว การใช้เครื่องมือที่ถอดรหัสและส่งต่อทราฟฟิกทุกอย่างยิ่งทำให้อาการแย่ลง</p><p>เขาจึงตัดสินใจเลิกพยายามทำตัวเป็นคนกลาง และหันมาใช้วิธี "เฝ้าดู" แทน เนื่องจากเบราว์เซอร์มองเห็นทุกคำขอที่ถูกส่งออกไปอยู่แล้วในแท็บ Network เขาจึงสร้างเบราว์เซอร์เอ็กเทนชันขนาดเล็กขึ้นมาเพื่อดึงข้อมูลทราฟฟิกเหล่านั้นและบันทึกลงใน localStorage ทันที แม้ในตอนแรกวิธีนี้จะใช้งานได้ แต่เนื่องจาก localStorage ไม่ได้ถูกออกแบบมาให้รองรับข้อมูลคำขอนับพันรายการ จึงทำให้เบราว์เซอร์เริ่มช้าลงอย่างเห็นได้ชัดเมื่อทดสอบกับแอปที่มีกว่า 200 Endpoint</p><p>บทเรียนสำคัญที่ได้คือ เบราว์เซอร์เป็นสถานที่ที่ดีในการเฝ้าดูทราฟฟิก แต่เป็นที่แย่มากในการจัดเก็บข้อมูล เขาจึงแยกงานออกจากกันอย่างเด็ดขาด โดยให้เอ็กเทนชันทำหน้าที่เพียงแค่มองเห็นคำขอ ส่งออกทันทีแล้วลืมมันไป ไม่เก็บข้อมูลไว้ในแท็บ จากนั้นเขาจึงสร้างโปรแกรม Listener บนเครื่องของตัวเองเพื่อเปิดพอร์ตรับคำขอที่ /capture และบันทึกข้อมูลลงไป ทำให้เอ็กเทนชันไม่เกิดอาการหน่วงไม่ว่าจะรันนานแค่ไหนก็ตาม</p><p>อุปสรรคแรกที่พบคือเรื่อง CORS (Cross-Origin Resource Sharing) เมื่อเอ็กเทนชันพยายามส่งข้อมูลไปยัง Listener ซึ่งอยู่คนละแอตเดรสกับหน้าเว็บ เบราว์ซอร์ตจะส่งคำขอตรวจสอบล่วงหน้า (Preflight request) ไปก่อน แต่เนื่องจาก Listener ของเขายังไม่ได้เขียนรองรับคำตอบในส่วนนี้ ทุกคำขอจึงล้มเหลวตั้งσόงยังไม่เริ่ม เมื่อเขาเพิ่มการตอบสนองที่ถูกต้องสำหรับคำขอนั้น ระบบก็เริ่มทำงานได้ทันที</p><p>แนวคิดนี้ไม่ใช่เรื่องใหม่ เพราะมีพื้นฐานเดียวกับเครื่องมืออย่าง mitmproxy หรือเครื่องมือขนาดเล็กชิ้นเดียวที่นักวิจัยมักสร้างขึ้นและนำมาเชื่อมต่อกัน ความแตกต่างเดียวคือเขาเลิกพยายามทำตัวเป็นพร็อกซี่ แต่เปลี่ยนเป็นเฝ้าดู บันทึกอย่างเรียบง่าย และส่งออกในรูปแบบที่ต้องการ เมื่อทราฟฟิกไหลลื่นไม่มีอาการหมดเวลาเพราะไม่มีอะไรขวางกั้น เขาก็เริ่มกระบวนการที่น่าเบื่อแต่มีประโยชน์ นั่นคือการคอยเคาะเรียก (Crawl) แอปพลิเคชันด้วยบัญชี Sales และส่งออกทุก Endpoint ที่เข้าถึง จากนั้นทำซ้ำด้วยบัญชี Super Admin แล้วนำรายการทั้งสองมาเปรียบเทียบกัน</p><p>ผลลัพธ์คือ Endpoint จำนวนมากในรายการแอดมินสามารถใช้งานได้โดยตรงด้วยบัญชี Sales โดยไม่มีการตรวจสอบฝั่งหลังบ้านว่าผู้ใช้งานคือใครจริงๆ ซึ่งส่งผลกระทบรุนแรงในแอปพลิเคชันทางการเงิน เช่น การเปลี่ยนรหัสผ่านของผู้ใช้อรายอื่น การเปลี่ยนอีเมล การปิดระบบยืนยันตัวตนสองชั้น (2FA) การเปลี่ยนเบอร์โทรศัพท์ หรือการสร้างบัญชีและบันทึกธนาคารใหม่ที่บัญชีพนักงานขายไม่ควรเข้าถึงได้ แม้เขาจะไม่เปิดเผยรายละเอียดคำขอจริงเพื่อรักษาความลับของลูกค้า แต่รูปแบบปัญหาที่ว่า "หน้าบ้านตรวจสอบบทบาท แต่หลังบ้านไม่ตรวจสอบ" ยังคงเกิดขึ้นซ้ำซ้อนและสร้างความเสียหายมากที่สุดในการทดสอบระบบ</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/toklas495/why-i-stopped-fighting-burp-and-built-my-own-listener-1ncf" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Burp Suite and other proxies frequently timed out during internal network security tests.</li><li>The researcher built a browser extension paired with a custom local listener program.</li><li>Successfully bypassed CORS limitations and eliminated traffic interception bottlenecks.</li><li>Uncovered critical authorization bypasses by comparing endpoints between Sales and Super Admin accounts.</li></ul></div><p>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.</p><p>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.</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/burp_suite_pentest_ms8h7xig_inline_1_58cf48edce.jpg" alt="browser developer tools network tab" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div></p><p>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.</p><div class="ai-insight"><p>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.</p></div><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/toklas495/why-i-stopped-fighting-burp-and-built-my-own-listener-1ncf" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

small_burp-suite-pentest-ms8h7xig.jpg

thumbnail_burp-suite-pentest-ms8h7xig.jpg

burp-suite-pentest-ms8h7xig.jpg

เมื่อ Burp Suite และ Caido ใช้งานไม่ได้ดั่งใจในงาน Pentest ระบบกู้ยืมเงิน นักทดสอบระบบรายนี้จึงตัดสินใจหยุดเป็นตัวกลาง แล้วสร้าง 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.

Inewgen

Inewgen

#Burp Suite

Why I Stopped Fighting Burp and Built My Own Listener

Inewgen