The best way I know to get acquainted with an unknown codebase is to fire it up locally (this alone may be very hard). Then approach softly, humbly, as a mere user. Start making theories about how it works, and what parts of the code are responsible for the behaviors you see.
Nó giống như việc xem shorts/reels và làm chúng ta bị FOMO.
Chúng ta không cần một random fact để trở nên hứng thú với điều gì đó. Thay vào đó, ta nên chủ động tìm kiếm các thông tin mà ta thấy hứng thú hoặc làm project.
I recommend you spend as much time actually hacking, because it is not time wasted even if you do not find any valid issues.
I do encourage that you learn how to build, not just break things. This can be a major advantage in bug bounties as it allows you to potentially better understand how systems are built, so you can formulate attacks to break them.
What you may find is that some companies are harder to find vulnerabilities in (how long it takes to find security issues), and you may give up before you find anything, but you need to understand that there are still vulnerabilities yet to be found for any attack surface. In bug bounties, you have to be comfortable with spending a lot of time not finding anything and genuinely enjoy the journey not just the destination.
I cannot understate how important it is to be constantly learning as a bug bounty hunter and challenging yourself to learn concepts in other hackers write ups that you do not immediately understand.
My advice to you is to specialise (i.e. become a master at) on what you enjoy the most in bug bounties. There are companies running bug bounties that cover the wide spectrum of technologies and platforms needed to be a perfect battle ground to progress your skills enough to mastery.
When reporting bugs to bug bounty programs, I highly recommend you forget about the submission and start finding more bugs that you can report, immediately. Another harsh reality you should be prepared for is that programs may not see the risk the same way you do when you find and report a vulnerability.
Something I suggest to those getting into bug bounties is to find a specific program that you want to focus on and become a master at understanding the assets on that programs attack surface, and the technologies and processes this program may employ.
If you start sensing that you are burning out, the worst thing to do is try and push yourself to work harder and longer. When experiencing burn out, stop doing what you’re doing and spend some time decompressing.
Hacking With Direction: Hacking với mục đích cụ thề chẳng hạn như “hôm nay tôi sẽ tìm ra các params bị reflected vào DOM”.
Motivation: Có thể set routine hằng ngày thay vì dựa vào motivation do nó không ổn định.
Starting Out: Đừng so sánh với người khác. Không ai giỏi ngay từ ban đầu. Việc tìm được bao nhiêu bug là không quan trọng, quan trọng là ta bắt đầu và thực hành. Và hơn hết là học được thứ gì đó và phát triển bản thân.
Flexible Thinking: Không nên đóng khuôn application vào một loại lỗi nhất định. Thay vào đó, ta nên xem xét cách mà ứng dụng phản hồi và tìm lỗi cụ thể đặc thù cho từng loại ứng dụng.
Assumptions: Không nên giả sử một feature nào đó là an toàn.
Generating Ideas: Khi bị stuck, hãy nghỉ ngơi, không nghe nhạc rồi quay lại sau. Sự buồn chán cùng với suy nghĩ sẽ giúp sinh ra ideas mới.
Dissecting Attack Surface: Bugbounty là impact-based, chúng ta chỉ nên tìm các lỗ hổng mà có impact đến thứ mà công ty quan tâm. Ví dụ, ứng dụng chat sẽ là các cuộc hội thoại còn ứng dụng tài chính sẽ là các dữ liệu tài chính.
Dành ít nhất 30 tiếng cho từng program.
Starting From Zero: Đừng áp lực bản thân là sẽ thành công mà hãy tận hưởng quá trình học và săn bug. Tất nhiên, cũng không nên đặt áp lực vào việc học.
Có một cách exploit khá hay đặc thù cho React: nếu application nhận vào JSON string và truyền nó vào làm Props của một component thì ta có thể thêm vào thuộc tính dangerouslySetInnerHTML để inject XSS payload:
Giải thích rất chi tiết về các directives và các giá trị của CSP. Đưa ra rất nhiều misconfigured examples của CSP kèm theo cách tấn công. Giới thiệu công cụ CSP Evaluator để test CSP.
Attacker khai thác tính năng custom action của ChatGPT. Tính năng này cho phép nhập vào OpenAPI schema dùng để gửi request. Mục tiêu là gửi request đến SSRFUtility - SSRF Exploitation Tool và cho nó redirect đến http://169.254.169.254 (sử dụng redirect để bypass việc schema chỉ cho phép dùng HTTPS).
Sau đó, attacker còn cần phải set custom header là Metadata: True đế lấy IMDS. Để làm điều này, attacker đã tận dụng chức năng cho phép sử dụng custom authentication header để set custom header.
Nội dung gần cuối liên quan đến việc sử dụng tính năng Overrides của browser để lưu client-side source rồi chỉnh sửa. Tính năng này khiến cho những thay đổi persistent qua các lần reload. Ngoài ra còn biết thêm extension HTTP Mock: về cơ bản là giống với Match & Replace nhưng dễ nhìn và dễ chỉnh sửa response hơn.
Ngoài ra còn chỉ cách phân tích client-site đã bị ofuscated (khó hơn cả bundled) và phân tích các trang có cơ chế bảo vệ client-side source khỏi dynamic analysis chẳng hạn như Self-Defending JavaScript, Debug Protection (tương tự như cách chống dynamic analysis của binary application).
Sử dụng param url và configUrl để tạo ra một trang phishing ở giao diện của Swagger nhằm đánh lừa người dùng để login. Về bản chất chỉ là HTML injection. Tương tự với report https://hackerone.com/reports/2534300.
Swagger UI cho phép sử dụng url param để load Swagger specs từ xa rồi render ra giao diện. Khi render thì sử dụng DOMPurify thể sanitize. Tuy nhiên, các version cũ của Swagger UI sử dụng DOMPurify cũ và có thể bypass dẫn đến XSS do Swagger UI render bằng dangerouslySetInnerHTML.
Payload ban đầu được sử dụng là <math><mtext><option><FAKEFAKE><option></option><mglyph><svg><mtext><style><a title="</style><img src='#' onerror='alert(1)'>"> nhưng do style bị cấm một cách tường minh bởi Swagger UI khi nó config DOMPurify nên ta cần tìm cách bypass. Cụ thể hơn, ta cần tìm một element tương đương với <style>. Để làm điều đó, tác giả cung cấp script sau: https://gist.github.com/kannthu/fd5cdd4664cc669755a928fb42aba0de?ref=blog.vidocsecurity.com. Script này sẽ lặp qua tất cả các HTML tags và thay thế vào payload rồi dùng DOMPurify để sanitize. Nếu output vẫn còn <img onerror=alert(1)> thì tìm được bypass.
Từ script trên tìm ra được 2 tags là <textarea> và <title>. Payload được cập nhật thành: <math><mtext><option><FAKEFAKE><option></option><mglyph><svg><mtext><textarea><a title="</textarea><img src='#' onerror='alert(1)'>">.