Skip to content

Category: Bug Bounty

Notes on Finding Evasive Bugs (by James Kettle)

Highly recommend security researchers to watch this. The talk focuses more toward improving your methodology and mindset:

  1. Don’t look for defences; Start with the attacks first.
  2. Look for unfashionable flaws.
  3. Your understanding of a vulnerability concept may be corrupted. Don’t reply on internet searches to learn. Learn from the original sources.
  4. Recognise the fear from the new or unknown (Technique sounds cool but…)
  5. Recognise that you might think that something is an implausible idea. Don’t just try something and then give out if it does not work. Instead do this: Explain why the idea will not work unless condition X exists. Try the obvious to make sure that it is obviously secured.
  6. Invisible Chainlinks give you advantages. They can be related to a particular context, application specific knowledge, inconvenient. For example, param miner works well if you have the application specific knowledge.


  • Use automation to scan for clues about the application.
  • Scan to learn
    • Test Hypothesis
    • Ask question and iterate
  • When enumerating, focus on specific things rather than broad information to reduce noise.
    • Make asking questions cheap.
    • Develop your own framework.

Writeups on Free Challenges in BugBountyHunter

In this post, I will share some writeups on the free challenges in BugBountyHunter platform. I encourage everyone to check out the site

Cross-Site Scripting in Image Tag

How does the feature works? If you select the dropdown option, the image will be rendered with special effects using CSS. In the img tag, we can see the selected option value will appear in class.

What could go wrong? The POST request looks suspicious.


There is no server side validation of the imageClass value. You can send any value and it will be reflected in the response.


We can try sending a few payloads to test for XSS issue. First, we can modify the imageClass value to imageClass=helloworld" onload="alert(1)". The response return a class="1" in the tag. We can try imageClass=helloworld" onclick="alert(1)". The response also return class="1" in the tag.

It seems like there is some blacklisting of some keywords such as onload or onclick etc. Hence we need to find the event handler method that is not blacklisted. Fortunately, this payload was not blocked: img2" onpointerup="alert('xss').

When we click on the image in the browser, the malicious script is executed.

Finding Stored XSS in File Upload

FrontAccounting ERP is open source, web-based accounting software for small and medium enterprises. It supports double entry accounting providing both low level journal entry and user friendly, document based interface for everyday business activity with automatic GL postings generation.”

I have an opportunity to work with the developer of FrontAccounting to fix a Stored XSS issue due to unrestricted File upload. This was an educational experience to learn about the usability and security tradeoff in Open Source Project when fixing the issue. More details can be found in the bug tracker.

Issue Summary

In the attachment function, the user is allowed to attach a file to a particular existing transaction. However, I observed that there is no restriction on the type of files that are allowed to be uploaded.

I managed to upload a malicious SVG file that contains JavaScript. Since there was no validation on the file extension, the file was uploaded successfully.

When I opened up the attachment item, I can see that the malicious SVG file was uploaded.

Now, if another user have opened this attached file, then an alert box will appear.


  • The best method is to adopt a Secure by Default approach by restricting the file type to be uploaded. This approach will reduce the attack surfaces. For example, does the application require SVG file to be uploaded? Perhaps the filetype be restricted to PDF, PNG, JPEG, DOCX, etc.
  • If SVG is required, sanitize the uploaded SVG file:
  • If sanitization is not possible, please follow these approaches:
    • Load the SVG from image tags as this will prevent scripts from running.
    • Use “content-disposition: attachment” – this force the file to be downloaded.
    • Set Content Security Policy (CSP) to disallow inline JavaScript.
    • Combine (2) and (3) for double protection.


Summary: Beginning Bug Bounty – Part 2

This is the continuation of summary ( )


Bug Bounty Methodology


  • You retain the understanding by teaching others, practice doing and having discussion.
  • Most of the time, you are exposed to something new which you are not familiar with. You need to research the issue and test it. If it doesn’t work, then you need to work on CTF examples to gain hands-on experience with it.
  • Immerse yourself in hacking by learning and reading the things which you might not understand. Follow people who post complex stuffs in blogs or twitter. Read disclosed reports to understand the thinking process of others.
  • Recommended Resources:
    • Burp Proxy
    • PentesterLand Newsletter
    • Conferences: DefCon, BSides, BlackHat
    • Podcast: Bug Bounty Podcast, Darknet diaries, Security Now, Risky Business, Price of An Attack
    • Reading Resources: Web Hacking 101, OWASP Testing Guide, Bug Bounty Cheat-sheets, Hacktivity, @Disclosed
    • Practice: CTFS (OWASP DVWA, Juice Shop, Hacker 101)
    • Structured Course: PentesterLab, Web Security Academy
    • Videos: STOK, CyberMentor, CS50, MIT OCW


  • Hacking is a trial by fire process and require hands-on experience.
  • If you have some experience in security, then begin by practicing CTFs, watch and read contents from actual attackers. And then find a real target to test.
  • When it comes to Goal-setting, aim for autonomy, mastery and purpose. Motivation for money does not work well for cognitively demanding tasks.
  • Example of Goals:
    • Technical: Learn to use Burp
    • Communications: Write report and understand the impact of the bug to a company
    • Personal Effectiveness: Learn how to set goals and self-improve,
    • Community Engagement: Share what you learn with others.
    • Short-term: Get private invitation
    • Medium-term: Earn at least 5K
    • Long-term: Find a technically difficult bug such as RCE.

Recon (Asset Identification)

  • This can be done manually by browsing the app or using automated spidering tools.
  • Ideally, you want to identify the assets faster than majority of the hunters.
  • Look for assets that can be targeted e.g. API endpoints.
  • Learn what the assets do:
    • Interact with DB?
    • Using APIs
  • Write down your observations in notes. Think about the financial impacts to the company.
  • Tips:
    • Pick assets with high amount of user interaction.
    • Understand the privileges of different user account.

Identify Potential Attack Vector

Common Patterns:

ObservationPossible Attacks
Forms without CSRF TokenTry CSRF attacks
APIs with IDsTry IDOR attacks
GraphQL EndpointsTry IDOR attacks
UI Validation checksTry XSS or SQLi attacks
  • Pay attention to attack vectors that are relevant to the web or mobile apps.
  • Keep track of the endpoints found and test them one by one for possible attacks. Make sure you test every endpoints that you have found before moving on.
  • Map the regular program flow and learn how the app is supposed to work.
  • Prioritize the endpoints:
    • Look for strange or different endpoints
    • Endpoints with large amount of parameters.
    • Link to logic such as account changes or payment gateway
    • Common endpoints such as wordpress.

Stuck in a Plateau?

  • What if I don’t find any bugs?
    • Sometimes the app is beyond your current skill level .
    • Make sure you have really exhausted everything
    • No more endpoints to test on.
    • Tried everything with the endpoints
    • No luck with Biz Logic
  • Pause your testing :
    • Take notes and record your process so that you can go back to your target.
    • Reflect on what you learned and apply on a new target.

Summary: Beginning Bug Bounty – Part 1

The summary is written based on the following resources:


Daily Rituals

(a) Hack with intention to learn

  • Realize that you will gain knowledge and the know-how when you are trying to hack something.
  • Investigate a product / app to see how it works. The knowledge can be used for future hacking.
  • Journal down what you are learning everyday.
  • Do not worry about duplicates. It means that you found a genuine issue.
  • There are always bugs out there since companies are frequently pushing their code.

(b) Invest time in reading hands-on guide

  • Take note of how you can apply what you read to improve your methodology.
  • Read a lot of documentation about APIs, Products, Business Logic, Security Technologies, New Languages, CTFs, etc.

(c) Find / Build your niches:

  • Focus on areas where very few people are looking.
  • Think about where you can find bugs in an unexpected places.
  • Try testing the applications which are not in conventional platform.
  • You cannot be looking for low-hanging fruits all the time.

Bug Bounty Checklist

  • Test for Injections vulnerabilities in Web and Mobile apps (SQLi, Command Injection, ORM injection, etc.). Understand if there are any validation or filter done.
  • Test to see if sensitive data are encrypted while it is transit, at rest.
  • Testing XML External Entity (XXE). Check if you can upload files (DOCs, PPT, etc.) / xml types. Know the impact:
    • Retrieve file from server
    • Server Side Request Forgery (SSRF)
    • Denial of Service (DoS)
  • Testing for Broken access Control. Check if a user can have privileges of other roles to exploit. Access control is only effective if it is enforced on server-side code or serverless APIs.
    • Look at the where the access roles are indicated. JWT? Cookie? URL?
    • Can you access admin pages without authentication?
  • Learn how to test for XSS – in depth. Know the potential XSS loopholes in modern framework such as ReactJS, etc.
    • Reflected: Unvalidated Input becomes part of HTML output.
    • Stored: Unsanitized input are stored to be viewed later.
    • DOM: JS / Single Page App (SPA) / API that dynamically uses user data to create DOM.