Behind every SQL query hides an opportunity: a carefully crafted payload can elicit sensitive data long after obvious error messages have been addressed.

In this guide, we explain basic and advanced SQL injection (SQLi) techniques, including blind SQLi, time-based attacks and out-of-band (OOB) callbacks.

You'll learn how to tailor payloads to the SQL statement in play, incorporate them into your Bug Bounty workflow, and detect and exploit SQLi vulnerabilities – even in hardened systems.

Understanding SQL Injection – definition, impact and Bug Bounty earnings

Why SQLi vulnerabilities persist despite improved protections

Simple SQLi: detecting vulnerabilities by analysing responses

SQL statement cheat sheet
- SELECT statement injection
- UPDATE statement injection
- DELETE statement injection
- INSERT statement injection

Exploitation workflow of a time-based SQLi

Out-of-Band (OOB) SQL injection via DNS/HTTP callbacks

Recommended SQL injection exploitation tools

SQL injection prevention & best-practice defences

Conclusion & Next Steps for Bug Bounty Hunters

. It’s the primary way of interacting with relational databases, which store data in rows and columns (tables), like a spreadsheet. SQL commands such as 

 allow developers to efficiently organise, retrieve and modify information.

For example, if a website needs to check a user’s token, it might run a query like:

This tells the database: “Find every row in the 

By splitting data into clearly defined tables, SQL makes it easy for developers to build a wide variety of features, from simple user profiles to recommendation engines – which is why it powers everything from personal blogs to enterprise applications. Learning about various SQL statement structures will help you tailor payloads to your target.

SQL injection (SQLi) occurs when untrusted input is embedded into an SQL query in a way that alters its intended logic – often leading to unauthorised data access, modification or deletion. First 

, SQLi bugs have become somewhat less prevalent over time due to the use of parameterised queries, ORMs (Object-Relational Mappers) and secure frameworks. However, they 

 and are frequently classed as high or critical severity vulnerabilities – earning significant rewards for Bug Bounty hunters.

As an ethical hacker, you will frequently encounter endpoints whose user-supplied parameters map directly to backend database queries. Have you ever noticed an error, strange behaviour or inconsistent response times after submitting unexpected characters or timing-based payloads? Those quirks are your first hint that an endpoint might be injectable.

In the modified query below, A hunter sets 

 clause that is always true, followed by a comment sequence that ignores the rest of the statement, thereby bypassing the token check:

This modifies the original SQL query structure, making the 

This visualisation shows how SQL injection works:

Successful SQL injection attacks enable attackers to interact directly with the application’s backend database, which can cause operational disruption or large-scale data breaches. Depending on privileges and security context, attackers can:

Achieve remote code execution (RCE) by abusing file-write or upload capabilities to inject a malicious payload

Despite the introduction of defences such as prepared statements and Object–Relational Mappers (ORMs), SQL injection vulnerabilities continue to persist in legacy systems as well as surface in modern applications. Take 

, which affected the WP_Query function used by WordPress to sanitise SQL queries with prepared statements. Due to improper handling of user input, SQL injection was still possible.

Simple SQLi: detecting vulnerabilities by analyzing responses

Let’s kick off with some comparatively simple techniques. Consider a website that leverages SQL for product search functionality.

A query for a non-existent product should return no results:

If the application is vulnerable to SQLi, a boolean-based payload that always returns true could return unexpected results:

Alternatively, injecting a single quotation mark (') may trigger a database error or 500 Internal Server Error, indicating improper input sanitisation:

Time-based SQLi, a more complicated variant, abuses delays in query execution. For example, in PostgreSQL, the following payload forces a four-second delay if vulnerable:

SQL injection vulnerabilities can occur wherever user input is incorporated into SQL queries. It’s wise to manually pinpoint where and how your input is handled by the database before you launch automated tools. 

, has its own escape hatch. Knowing your injection context determines whether you break out with a quote, parenthesis or 

Searching for products in an e-commerce web application:

Boolean-based SQL injection is a form of blind SQLi, which means attackers sends crafted inputs that cause the database to return either 

 conditions. By comparing the application’s behaviour for true versus false conditions, they can infer what’s happening behind the scenes and gradually extract data.

Imagine a login form where the user submits a login and username and password, as demonstrated by this raw HTTP request:

And behind the scenes, the application runs this query:

An attacker might try something like this:

 obviously always evaluates to true. This renders the username check irrelevant and, combined with the SQL comment sequence 

, causes the database to ignore the rest of the query. A successful SQLi here allows the attacker to log into the first user record – usually the administrator’s account.

 operator to trick a website into combining the results of multiple 

 queries – allowing attackers to extract sensitive data such as usernames, emails or passwords. The attack only works if the queries have matching column counts and compatible data types.

And behind the scenes, the application runs:

If this input is not properly sanitised, an attacker might try injecting a 

 operator that pulls the username and password from the database:

Vulnerability vectors: SQL injection for Bug Bounty hunters

Adrián Pedrazzoli – aka lemonoftroy – was hooked on hacking as soon as he encountered this “new world”.

In this interview, the Argentinian bug hunter recounts how he got into hacking and discusses his favourite kinds of vulnerabilities, preferred hacking tools, proudest Bug Bounty discovery so far and some tips for aspiring hunters.

, who is also a pentester, product security senior at Salesforce and co-founder of 

, brought a variety of InfoSec expertise to the conversation.

This interview took place during Ekoparty, in Buenos Aires, during a live hacking event held by YesWeHack. Adrián finished third on the 

That is a good question. Twenty years ago I think, when I was younger, I [had] a conversation [with] a friend, and he sent a trojan horse, and he explained what that was. So for me it was a revelation. And in that moment, I think that was something interesting, a new world – and I wanted to be part of it.

Burp Suite, LinkFinder… and I think that’s all. Only two. Because I don’t like to do automation. I try to do more manual jobs and try to, you know, understand the business logic. So tools, there are a lot of them. Actually, I can mention a couple more, like ffuf or dirsearch, for discovering and fuzzing web applications. But for me, I think that those are enough.

I can tell you nowadays that IDORs or broken access control are my best bugs or my favourite bugs, because those are business logic bugs and are pretty impactful. And you can find them easily. So broken access control, IDORs and server-side request forgery too. But I really love XSS, like any one of us, because these are the first bugs that we used to report when we started going about bug hunting.

On the bug you are most proud of discovering so far…

It was a server-side request forgery, because it was simple. It was an HTML injection. I just embedded an iframe and I was able to extract all the metadata from AWS. Basically a critical server-side request forgery in the moment of the PDF creation. For me, it was straightforward. Around 20 minutes, but it was amazing. Not much time, but good impact and fun.

On his top tip for inexperienced hackers…

You have a lot of content nowadays: YouTube channels, TikTok, you have a lot of writeups. Try to read any kind of articles that you can, that you are interested in. For example, you have Pentester Land, you have channels like NahamSec.

Nowadays there are a lot of ‘hack-fluencers’. So I think there is a lot of content that you can use to learn and platforms to practice on.simple. It was an HTML injection. I just put embedded an iframe and I was able to extract all the metadata from AWS. Basically a critical server-side request forgery Server-Side Request Forgery in the moment of the PDF creation. For me, it was like straightforward. Around 20 minutes, but it was amazing. Not much time, but good impact and fun.

You have a lot of content nowadays:, YouTube channels, TikTok,. You you have a lot of writeups. Try to read any kind of articles that you can, that you are interested in. For example, you have Pentester Land, you have channels like NahamSec.

Nowadays There there are a lot of nowadays “‘hack-fluencers”. ’. So I think that there are is a lot of content that you can use to learn and platforms to practice on.

, or learn about the latest hacking tools and hacking techniques 

‘It was a revelation’: lemonoftroy’s origin story and hacking methodology

The process of fixing vulnerabilities should yield security benefits beyond the immediate hardening of the affected application.

Implemented as part of continuous threat exposure management (CTEM), remediation can also generate insights that help to prevent the recurrence of similar vulnerabilities and optimise future security testing and vulnerability management. In this sense, the final ‘mobilisation’ phase of the CTEM cycle can be the engine of a positive feedback loop.

This is the third (but not final) part of a series on a CTEM model that Gartner predicted could lead to a 

, and its implementation via YesWeHack’s 

In the first instalment we talked about systematically 

mapping your (probably) fast-growing external attack surface

 digital assets, and automatically and continuously 

 related assets, services and technologies.

. Our ASM platform automatically assigns priority scores based on severity, exploitability and asset criticality. These ‘findings’ are then manually confirmed/rejected as exploitable/non-exploitable within the environment.

 phase then operationalises the information gathered so far:

Real-time visibility of your full attack surface

Knowledge of any CVEs currently affecting your environment

Knowledge of any validated vulnerabilities discovered through your own testing

The risk posed by each vulnerability within the context of your environment, as reflected by priority scores

This equips SecOps teams to deploy resources – teams, tools and processes – to the end of urgently fixing the highest-priority bugs, remediating the rest in a timely fashion and retesting fixes to ensure their effectiveness.

Leveraging vulnerability reports from multiple sources is of course much easier if they are standardised and accessible from the same interface. This is what our platform delivers: a unified view of vulnerabilities generated from known issues (CVEs), Bug Bounty Programs, traditional pentests, Vulnerability Disclosure Policies (VDPs) and passive plus active scanning approaches.

All findings can be edited, shared, assigned and tracked in real time. These reports can be integrated with your existing bug-tracking tools through our connectors and open API.

Consolidating all vulnerabilities into a common interface facilitates essential collaboration between internal teams as well as with security researchers plus YesWeHack triagers and customer success managers.

For managed VDPs and Bug Bounty programs, triagers liaise with security researchers to clarify ambiguities and provide missing details – ensuring complete, actionable reports. Your teams can also engage with triagers, security researchers or pentesters directly from within the platform.

Bug Bounty hunters are incentivised to provide high-quality reports and prompt, helpful responses not just by the promise of financial rewards, but also to earn points that can unlock lucrative hacking opportunities.

The remediation timetable should be guided primarily by automated priority scores set in the prioritisation phase, which the user can manually adjust to reflect their risk appetite and operational context. This ensures the most dangerous vulnerabilities are addressed first.

With YesWeHack Bug Bounty Programs, remediation decisions can also be influenced by technical fixes and advice offered by Bug Bounty hunters – in terms of not just when but also how to remediate, as well as communicate patches to users and regulators.

Consider how practical constraints can, alongside priority scores, impact remediation timelines.

For instance, remediation can be delayed by unavailable personnel or a fix affecting third-party systems or potentially breaking functionality, especially if compensating controls offer effective mitigation in the meantime. Conversely, vulnerabilities can jump the queue if a fix is simple and obviously non-disruptive, if evidence of in-the-wild exploitation emerges or if compliance requirements demand it, among other scenarios.

Remediation doesn’t just close issues – it can improve secure development practices.

With input from triagers and hunters, your teams can identify patterns and turn patches into developer training material, or integrate automated tests early into CI/CD pipelines to catch similar bugs sooner.

Vulnerability insights can also inform broader security activities like access control reviews, red teaming activities or tabletop exercises.

Optimising the CTEM process and vulnerability discovery obviously depends on having the ability to track and evaluate a variety of operational metrics.

A SecOps team might for instance finetune its security testing coverage by filtering and analysing vulnerable assets by category or the top five most vulnerable assets overall. In a bid to reduce time-to-fix, they might measure variables like average first-response, average resolution times by priority tiers, or the percentage of successful retests achieved.

Our ASM enables SecOps teams to track and act upon these outcomes via executive dashboards and key metrics that can be sorted/filtered, represented by charts and exported as part of executive reports.

The iterative nature of these CTEM activities thereby allows for adaptation to emerging threats and the maintenance of long-term resilience.

Strategised security testing and remediation

An incomplete view of your attack surface, ‘point in time’ pentests and a fragmented testing regime are no longer tenable for today’s threat landscape.

By offering a unified, comprehensive and risk-based approach to attack surface management, security testing and vulnerability management, YesWeHack’s solution can therefore serve as the missing link in your offensive security strategy.

In service of this strategy, our ASM offers continuous visibility of your true digital footprint and exposure to known and newly discovered vulnerabilities; automated prioritisation of vulnerabilities based on severity, exploitability and asset criticality; and strategised security testing and remediation to tackle the most critical vulnerabilities at scale.

The next and final instalment in our CTEM series will explore the synergy between Bug Bounty Programs and CTEM.

 with YesWeHack today and discover how a risk-based approach can transform your organisation's security strategy.

Continuous threat exposure management (CTEM) series #3: mobilisation and remediation

The axiom that ‘patience is a virtue’ is surely no truer than when applied to the world of 

, Argentinian hacker g4mb4 cited this attribute among his three most important traits when it comes to hacking in this interview with YesWeHack.

G4mb4 – aka Damian Gambacorta – also recounted the impact of the vulnerability he is most proud of so far, considers whether being a developer made it easier to build a successful career in Bug Bounty, and details his methodology for choosing targets.

This conversation was filmed at Ekoparty, in the hunter’s hometown of Buenos Aires in November 2024, during a live hacking event where g4mb4 finished second on the 

The former developer has since started a company – 

 – that leverages the expertise he has accrued in Bug Bounty, which he also combines with an additional senior cybersecurity role.

I started as a software developer like 15 years ago, and at some point, I decided that security was something that I needed to be more focused on.

During the pandemic, I started a course to learn about how to hack and do it in an ethical way.

And I started checking Bug Bounty and realised that it's something I really liked to do.

I migrated from development to Bug Bounty, which I’m currently focusing on right now.

I always say that I like to hack companies that I probably wouldn’t be part of, because the interviewing process would be complex.

So I really like to hack big companies that have a wide scope, that pay good, reasonable bounties and – most importantly – that treat us nicely and as part of their company. Not like a competition, because for us it’s a job also, and it’s something that we really care about.

On the three words that best describe him as a hacker…

I call it PPC – that is: persistence, patience and curiosity. That means I’m very curious about hacking techniques, tools and platforms. And I also have a lot of patience to spend long hours hacking through the night.

On the bug he is most proud of discovering so far…

Well, I found an IDOR. I focus mostly on IDORs, and the IDOR I found, I was able to get all the tickets from a big company.

And after getting all the tickets from that company, I was able to access reservations, cancel them and do more stuff with them.

That was pretty impactful because it was affecting a $1 billion company that was really big.

I really like the way that the programs are organised on the platform, and how easy it is to report on YesWeHack.

I found it really easy to create the report, to focus on the flaw, and also the relation with the triagers was really helpful to commit, to solve the tickets faster.

On whether being a former developer typically makes you a better hacker…

I would say that it's the opposite: I had a background as a developer, then I started doing Bug Bounty, and once I had a lot of knowledge from Bug Bounty I started improving my coding techniques and being more professional in that.

I started applying for cybersecurity jobs, and now I’m a security architect due to the fact that I started doing Bug Bounty in my free time.

I would say that the tip I can recommend for new hackers is spending some time reading, learning about the vulnerabilities, how they can be exploited.

And with that in mind, start taking some time reviewing the programs, learning how the scope is, and start hacking. I think that you just need to start hacking!

‘I have the patience to spend long hours hacking through the night’: g4mb4 on his Bug Bounty career so far

“Keeping yourself motivated” as a Bug Bounty hunter is paramount given the feast-and-famine nature of vulnerability discovery, says Italian hacker leorac.

 – or Leo – also discusses his favoured type of vulnerability, tips for beginner bug hunters and the changes he’s observed in software development over the past two decades and the implications for hacking.

As he also explains in the video, Leo is a part-time hunter since he also works as a software engineer, and is married with two children.

The footage below was filmed in September 2024 at the RomHack cybersecurity conference in Rome, where Leo took part in Italy’s 

I started hacking in 2021. I wanted to be a penetration tester. And I started to do CTF, and then I discovered the Bug Bounty world. I tried myself and I was very lucky, because I found some bugs pretty soon, so I got motivated. And I have been hacking ever since.

On the most challenging aspect of bug-hunting…

The most challenging part, I think, is the psychological one, because Bug Bounty is not only technical.

It’s important also to keep yourself very motivated, and Bug Bounty is a rollercoaster of emotions. Sometimes you find some bugs, some critical bugs – and you see yourself at the top of the mountain, like the best hacker in the world. And next time you can’t find anything for weeks, for months – and you think that you’re just done.

You have to be intentional in keeping yourself motivated and to stay healthy, and maybe take some pauses – and start all over again.

I guess ‘consistent’, because from when I started, I always went through all the process and I never stopped. The second one, I guess, is ‘creative’, and that’s the counterpart of technical – because I’m not so technical. I prefer to see myself as a creative, finding creative ways to hack on the applications. And the third one is ‘passionate’, because Bug Bounty is a part-time job. But for me, it’s my very passion and what I’m very passionate about.

‘My best attribute is persistence – technical skills you can learn’: drak3hft7’s Bug Bounty story so far

I guess that my most critical or biggest-impact bugs are all broken authorisation bugs, because it’s what I keep testing. Testing that I was able to, most of the time, get to privilege escalation, to do stuff with low privilege users that was meant to be done by an admin. And this leads to account takeover or, with an IDOR, information disclosure. So my main bugs are mostly just like that.

On the evolution of software development and hacking techniques…

I guess that the main evolution is about technology. So some years ago, old websites for example were in PHP, and now you see that not so much anymore. Before there were no frameworks, and now everything is based on frameworks. As I said before, I’m 40 years old so I’ve seen a lot in 20 years. And right now, of course you can’t hack as if it were five years ago or 10 years ago. You have to focus on different classes of vulnerabilities. So I guess you have to follow the technology – and then understand what this technology is, where this technology is more prone to be vulnerable.

My main tip is: just start. Because I see so many people in the loop of trying to study, to understand – because they are scared to start, they are scared of the challenge. But there are a lot of public programs, a lot of platforms, so just start.

And on the technical side, something that helped me a lot was the PortSwigger Academy. So all the time I suggest that. If you’re able to go through the PortSwigger Academy, then you are just fine to start doing Bug Bounty.

Learn more about hunting through YesWeHack

, or learn about the latest hacking tools and techniques 

‘The most challenging part is the psychological one’ – leorac on the ups and downs of Bug Bounty hunting

The Dojo challenge, Hex Color Palette, required participants to exploit an XXE (XML External Entity) vulnerability in order to trigger a file disclosure. 

By crafting a malicious XML payload, they had to trick the parser into leaking the contents of a sensitive local file - specifically 

Want to create your own monthly Dojo challenge and won a contributing award? Send us a message on Twitter!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

This time, things were a little different – and some context is needed.
The challenge was created by myself – @

 – and while preparing it for release last month I realised that the original PoC no longer worked as expected.

After some investigation, I discovered that the issue was caused by an update to the Python 

 revealed that payloads relying on parameter entities had worked reliably until this update – including in scenarios involving DTD injection and indirect file disclosure. However, changes in the underlying 

This change explains why the challenge suddenly stopped working: 

although the intended solution remained valid,

 the parser no longer processed parameter entities the way it used to – effectively breaking the error-based XXE vector the intended solution relied on.

To address this, we added a feature to Dojo that allows us to use the previous version of 

 when creating challenges, and I left the challenge itself unchanged. 

Instead, I have decided to publish two separate reports for this community write-up: one detailing the intended PoC before the 

 update, and another showcasing the exploitation technique based on Anatoly Katyushin (heart1ess) discovery!

This challenge revolves around a Python web application that renders user-supplied XML data through a templated HTML interface. The application uses the 

 library to parse XML files and extract hexadecimal colour codes to populate a front-end colour palette. However, the XML parser is configured to allow external Document Type Definitions (DTDs) and resolve entities, which opens the door to an XML External Entity (XXE) injection vulnerability.

Due to insufficient input validation and insecure parser configurations, an attacker is able to inject arbitrary entity declarations, thereby allowing him to manipulate the server into disclosing files stored on it.

To identify potential vulnerabilities within an application, analysing the source code is an effective approach as it reveals insecure coding practices, such as improper input validation or the misuse of certain libraries. In this scenario, we are presented with a web application that accepts a user input, which is then parsed by the program - potentially influencing the contents returned to the user.

The first step in performing our taint tracking is to examine how our input is being handled by the program. In this scenario, a Web Application Firewall URL-encodes the user input before it reaches the web server.

Our user input is first decoded using the 

 function, returning to its original form (our raw input) before being passed to the 

function. The result of XML parsing, or any errors that occurs, is echoed back to the user in a templated HTML response. This hints that our payload could manipulate the contents of error messages, which often tend to be verbose.

 function is where the bulk of the data processing lies at. There are a few key points that can be noted regarding the function's implementation:

: allows the XML parser to load external DTDs

: enables the expansion of external entities

In the setup code, we can observe that there is a DTD file located at 

Note the reference to an undefined entity 

, we can deduce that the application will:

3. Attempt to resolve file paths provided within entity values

, we can deduce the possibility of overriding this entity with arbitrary ones, which will be subsequently loaded by the parser. Based on this idea, we can slowly piece together a payload:

To begin with, we need to load the local DTD at 

, which could have nested parameter entities that would be expanded via the parser's 

configuration. We need to include the following:

 that references a non-existent file path (

Finally, we just need the parser to load 

The parser will then read the contents of 

 most probably does not exist, an error containing the resolved path will be thrown, and the resolved path will be returned as part of the error message (hopefully).

Before we merge everything together, we need to note that some characters need to be replaced with their Unicode hex character codes to bypass parser restrictions and prevent premature expansions during entity parsing.

Double-encoding is also used to delay expansions. For example, 

This vulnerability presents a serious risk as it allows an attacker to read files on the server, leading to a loss of confidentiality. For example, we are able to leak the contents of 

To remediate this vulnerability, the configuration options of the 

 to prevent the loading of DTDs and entity expansions.

Input validation and sanitisation should be incorporated before the user input is processed by the 

 function to prevent blacklisted characters and keywords (e.g. 

Additionally, error messages returned to the user should avoid including the XML parser's error messages as these could unintentionally leak file paths, stack traces, and in this scenario, the contents of arbitrary files.

————– END OF 0necloud‘s REPORT —————

As explained earlier, this approach no longer works with the current version of 

, it's no longer possible to trigger an XXE using parameter entities - which were previously exploitable regardless of this setting.

The YesWeHack Blog

Vulnerability vectors: SQL injection for Bug Bounty hunters

Vulnerability vectors: SQL injection for Bug Bounty hunters

‘It was a revelation’: lemonoftroy’s origin story and hacking methodology

Continuous threat exposure management (CTEM) series #3: mobilisation and remediation

Vulnerability vectors: SQL injection for Bug Bounty hunters

‘I have the patience to spend long hours hacking through the night’: g4mb4 on his Bug Bounty career so far

‘The most challenging part is the psychological one’ – leorac on the ups and downs of Bug Bounty hunting

Dojo challenge #42 - Hex Color Palette winners & writeup

‘I have the patience to spend long hours hacking through the night’: g4mb4 on his Bug Bounty career so far

Recon series recap: The ultimate guide to Bug Bounty reconnaissance and footprinting

Chunked-body parsing flaws, making self-XSS great again, using HTTP redirect loops to achieve non-blind SSRFs – ethical hacker news roundup

‘Bug Bounty has become a security best practice’: Why Ferrero is sweet on crowdsourced testing

Recon series recap: The ultimate guide to Bug Bounty reconnaissance and footprinting

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us