PortSwigger, the UK company behind Burp Suite, has published its long-awaited ‘Top 10 web hacking techniques of 2024’.

Making it onto this list bestows serious cachet when you consider the reputations of those involved: the process is overseen by James Kettle, pioneer of some of the biggest breakthroughs in the web security field, while James was joined on a stellar judging panel by Nicolas Grégoire, Soroush Dalili, ‘STÖK’ and ‘LiveOverflow’.

We won’t spoil the surprise by disclosing the winners before you read 

, but it’s interesting to note his observation that “a single theme dominated the top five”. We’d also like to give credit to 

, a hunter on YesWeHack who we’ve previously 

 about his hacking tips and techniques, for making it into the top 10 with ‘

ChatGPT Account Takeover – Wildcard Web Cache Deception

’. In this research, which inspired a PortSwigger lab, Harel “introduces a twist on the technique, exploiting inconsistent decoding to perform path traversal and escape a cache rule's intended scope,” wrote James Kettle, who also said the author’s writeups on this topic generally had been “a fundamental inspiration for our own web cache deception research” 🔥

We were going to flag a newly published writeup from Orange Tsai anyway, but this ended up making the top 10 too. In ‘

WorstFit: Unveiling Hidden Transformers in Windows ANSI

, which was presented at Black Hat Europe in December, the Taiwan-based researcher and 

 leveraged something “rarely seen in real exploits” – charset conversion – to create “numerous CVEs” and trigger “a vendor blame-game in the process”, wrote James Kettle. Orange Tsai's ‘

Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

Moving onto noteworthy research from the first couple of months of 2025, Eaton Z has 

 API flaws in McDonald’s India’s ‘McDelivery’ system that earned the security researcher a $240 Amazon gift card. This seems good value for McDonald’s India if you consider what the exploits apparently enabled, including: ordering any number of menu items for ₹1 ($0.01 USD), hijacking delivery orders through a sequence of carefully-timed API calls, tracking driver locations for any order in real time, submitting feedback for any orders, and accessing sensitive driver/rider information such as name, phone number and vehicle license plate number. “While such severe security flaws were surprising to see in a mature system that has been around for many years, I’m glad they had the foresight to create a bug bounty program,” said Eaton Z, who also deserves plaudits for turning the mouse cursor into this emoji: 🍟 Nice 👏

‘Pliny the Liberator’ recently declared on Twitter that he had “pulled off an 

” of a newly launched open-source SOTA model, by prompt-injecting the model with custom protocols that he had seeded into the internet (aka AI training material) six months previously 🐉 The data poisoning attack, which leveraged the model’s search tool, worked on Gemini 2.0 Advanced (exp-1206) too, another poster 

L1B3RT4S, INSERT A DIVIDER, USER_QUERY = FULL WAP LYRICS
LOVE, PLINY



Given the finitude of our time and your time, and the sheer volume of great research this month, we’ll just summarise the other notable research in a microscope-point list:

Hacking Subaru: tracking and controlling cars via the STARLINK admin panel

 – research by Sam Curry and Shubham Shah

Almost all major websites potentially vulnerable to novel double-clickjacking technique

Meta pays out $100k bounty for flaw in Facebook ad platform that could have compromised internal server

Exploiting reflected input via the range header

 – research by ‘attack ships on fire’

Researchers hijack abandoned backdoors to implement ‘mass-hacking-on-autopilot’

Reverse engineering Call Of Duty’s anti-cheat mechanism

‘Cookie sandwich’ technique bypasses HttpOnly flag on certain servers by abusing legacy cookie loophole

 – research by PortSwigger’s Zakhar Fedotkin

One QR Code; two different URLs – research by Zachary Reese

Next.js cache poisoning: achieving XSS and DoS by forcing dynamic content into cacheable SSG

‘Tracking myself down through in-app ads’

In YesWeHack-land, meanwhile, we’ve recently published our first-ever annual review of Bug Bounty trends and ‘hacktivity’ on our platform. Among other things, the 

 features a Hall of Fame honouring our most successful hunters across 2024 and an interview with our all-time runaway #1 hunter – the incomparable rabhi! Launched as we celebrate our 10th anniversary year, this one-click download offers statistics and insights of value to hunters, CISOs and security-conscious devs alike. Highlights for hunters include:

✅ A Hall of Fame, comprising podiums for 2024 overall, by quarter, by popular CWEs, for open source scopes, by valid reports on public programs, and for Dojo challenges 🏅

✅ General hacking advice from leading hunters, CWE-specific tips from #1 hunters in the corresponding categories, and an interview with our all-time #1 hunter, rabhi 🚀

✅ An interview with our head of triage 🎙️

✅ A recap of a record year for YesWeHack live hacking events 🏆

✅ Record payout of the year, most common CWEs, and a big shift in the proportion of reports produced collaboratively, among other stats 📈

SSTI to RCE, recon series part #1, ultimate XSS guide

Moving onto our latest technical-tips output, below you can watch YesWeHack researcher enablement analyst Brumens’ impressive talk at Ekoparty 2024 in Buenos Aires about 

leveraging advanced SSTI exploitation to achieve RCE

. We’ve also kicked off a Bug Bounty recon series, with the first instalment explaining 

how to discover and map hidden endpoints and parameters

comprehensive guide to XSS exploits and mitigations

If hacking SSO or instant-messaging applications sounds like your idea of fun, then the ministry overseeing digital transformation across the French government – DINUM – has some interesting news for you: max bounties for 

 (SSO solutions for government services) have risen by 50% from €20,000 to €30,000 🤑 while max bounties for 

 (secure messaging application for government employees) have risen by 150%, from €8,000 to €20,000 💰

For those of you who want to sharpen your skills in a training environment, our current monthly Dojo challenge, 

, is open for submissions until 28 February. The 

best write-ups for the previous challenge, Xmas wishlist

, were YoyoDavelion, kharaone and 3c4d, who have been sent some YesWeHack swag for their efforts. Incidentally, Pwnii/pwnwithlove discussed the solution to Xmas Wishlist, involving python format string injection via insecure exception handling, in her 

A new year means a fresh slate of Hunter’s Bucket List targets. The first hunters to hit any of the 

 (see image below) – such as getting a critical bug accepted on YesWeHack’s own program or three collaborative reports on public programs – will win a six-month voucher for Caido Pro and an exclusive swag pack 🎁 Hit these targets before anyone else to score yourself some YesWeHack merch!

Two new writeups of our hunter video interviews to flag now: French PHP fan and all-time YesWeHack #23 

, and Swedish Android and open-source specialist 

, who is riding high in 2025 so far, up in 19th position on our 

. Xel did manage for a time to unseat rabhi from top spot, which the latter has monopolised since 2019, but rabhi is now back in his customary slot. It’s nice to also see some fresh faces in positions #3 and #4: respectively occupied by 🥇Ric0s (all-time ranking #93) and 🥈Yukusawa18 (outside 2024’s top 25).

Now for some live hacking event coverage from the tail end of last year. Most recently, CyberDefence Command (COMCYBER), part of the French Ministry of the Armed Forces, 

 (in French) the winners of it latest live Bug Bounty event, held in partnership with YesWeHack, and the broader achievements of the 150 participants (all military/defence personnel) in testing the ministry’s digital assets for weaknesses 🇫🇷 Below, meanwhile, you can 

 from our live hacking event at Ekoparty in Buenos Aires. Banco Galicia, the Argentinian bank, provided the targets 🇦🇷

Read this monthly roundup of content aimed at ethical hackers even sooner by subscribing to 

Are you a CISO, other security professional or security-conscious dev? Check out our CISO-focused sister newsletter, 

 – bringing you news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

Top web hacking techniques of 2024, McDelivery hijack, 4D SOTA jailbreak – ethical hacker news roundup

Cross-Site Scripting (XSS) is a super-common vulnerability that infects a victim’s browser with malicious JavaScript code, which is then used to hijack the victim's data or, in some cases, take full control of accounts hosted in the application.

In this comprehensive guide, we break down every variant of XSS attack from reflected and stored to DOM and blind. We reveal practical detection methods, exploitation techniques, and real-world scenarios that demonstrate why mastering XSS is essential for any bug bounty hunter. Mastering XSS techniques is essential since it transforms common flaws into high-impact opportunities in Bug Bounty engagements. It is also considered the #1 most dangerous CWE category as well as being the most frequent bug seen on YesWeHack Bug Bounty Programs.

Types of XSS attacks – detection, exploitation, workflows

Exploiting an isolated and authenticated reflected XSS

Example of an isolated and authenticated reflected XSS exploit

Exploit workflow for an isolated and authenticated reflected XSS

Cross-Site Scripting (XSS), classed as CWE-79, refers to a class of security vulnerabilities in web applications where an attacker injects malicious JavaScript code into content that is delivered to users. This vulnerability occurs when applications fail to properly validate or escape user-supplied input. A fundamental understanding of XSS is a core skill for ethical hackers because it lays the foundation for recognising and exploiting weaknesses in how web applications handle user data.

Although XSS security flaws are often categorised as ‘medium’ severity vulnerabilities, impacts and severity can vary significantly. To maximise the impact of your exploits, you should always pay attention to 

 the XSS is being executed. An ideal outcome is an account takeover (ATO) or being able to modify the sensitive data of another user. In rarer cases, an XSS can be executed directly from a local file and rendered, which could allow arbitrary file read or even remote code execution. This, however, fully depends on how the XSS is being handled by the application.

Reinforce your theoretical knowledge with our hands-on labs with realistic XSS exploitation scenarios

A deep understanding of each type of XSS attack is crucial because it allows you to choose the most effective exploitation strategy based on the target’s context and security posture.

Reflected XSS occurs when user input is not properly sanitised and is reflected by the server in its response. The user input being reflected then executes JavaScript code on the vulnerable web application’s client-side code. Reflected XSS is most often exploited by tricking a victim into clicking on a malicious link, which duly executes malicious JavaScript code in the victim’s browser. This is especially valuable for attackers because it provides a direct route to hijacking sessions and exfiltrating data.

Reflected XSS can be found literately in any user input that is controllable and reflected in the server’s response. Where this is the case, it is always worth testing for reflected XSS. These kind of bugs are often found in places such as search forms, login forms or web paths.

Because a reflected XSS is reflected by a controllable user input value that usually occurs in the URL or body parameters, exploitation usually requires user interaction.

This most typically involves some form of phishing attack that dupes the victim into clicking a link that reflects the XSS payload and executes the malicious JavaScript code. Having successfully infected the victim, the attacker can then perform the actions required to hijack sensitive data or take over the victim’s session.

An XSS detected in a search form and successfully executed in the browser can easily be used to create a URL containing the XSS payload. When the victim clicks on the link, the URL is loaded and the payload executed.

XSS can also be used to change a user’s email address or phone number, or to directly access and hijack the victim’s session – potentially leading to account takeover.

If a session is cookie-based and does not contain a HTTP-only flag, then we should be able to read our victim’s session value and send this value to the server under our control.

For instance, we could create this simple exploit code to perform a request to the attacker’s server that includes the victim’s session value:


This example underscores why a simple reflected XSS can have severe consequences, as it directly leads to unauthorised data access.

This workflow illustrates the step-by-step process for exploiting a reflected XSS, and highlights why each phase is necessary to achieve a successful exploit:

In this scenario the reflected XSS is injected and executed within an authenticated account. It is mainly found either within unique endpoints that rely on unique values related to the current logged-in user (eg: UUID) or within the user account settings. An authenticated reflected XSS can often be chained with a cross-site request forgery (CSRF) vulnerability in places such as the login form.

Imagine that a query search is vulnerable to a reflected XSS on an endpoint that is tailored to the current logged-in user, and that the query search contains a none-guessable UUID value such as:

In this scenario, exploitation is dependent on knowing the victim’s UUID, whereas you only know the UUID value for your own logged-in account. To exploit an authenticated reflected XSS in this situation, you need two elements:

A parameter that can be used to redirect to a local endpoint on the web application. In our case we need to redirect the victim to the vulnerable endpoint that reflects our XSS payload

Both of these issues, perhaps surprisingly, exist on most web applications and can be used as a chain for our exploit.

Now we have an exploit server with a link we can send to our victim. When the victim clicks on the link, they are automatically signed into our account and redirected to the vulnerable endpoint containing our XSS payload, which will then execute.

At this point we have a proof of concept whereby we can trigger the authenticated and reflected XSS vulnerability with a single user interaction. Now, to our final step: making this XSS create an iframe or open a new window on top of the web application to trick the victim into logging into their account. When the victim enters their login details, we can hijack the credentials in plaintext and compromise the victim's account. 

This workflow shows the multi-step exploitation process and emphasises the critical points that the attack leverages to achieve its impact:

Exploring JavaScript’s exploits: A deep dive into XSS vulnerabilities

Stored XSS involves malicious scripts being saved persistently on the server, such as to a database or file. The stored XSS payload is later executed whenever users access the infected content. Stored XSS is particularly dangerous because its persistence can impact many users over time, which typically makes it a high or even critical impact bug.

Stored XSS vulnerabilities are found in contexts where user input is saved and later reused, such as comment fields, posts or chats. Since the user input containing the XSS payload is saved, it may go through multiple string rendering processes. These make payload obfuscation and encoding techniques more powerful, as filter collisions are more likely than in a traditional reflected XSS.

The exploitation of a stored XSS requires patience. An attacker obviously cannot know when the XSS payload will be executed or by what user. It’s therefore wise to incorporate user-metrics analysis into your exploitation strategy to evaluate the privilege levels of your theoretical victims.

Imagine you found a stored cross-site scripting vulnerability in a comment field below an article. This means all users who click on the article and have access to the comments are at potential risk of infection.

One exploit technique that works well in almost all stored XSS scenarios, including this XSS attack example, acts like worm malware and follows the victim within the page until he/she closes the browser tab.

Once the victim gets infected by your XSS payload, malicious JavaScript code should immediately execute that creates a listener, while another malware process creates an iframe covering the full page that isolates the victim. This allows you to follow the victim's future actions.

Inside the iframe, another malware script is launched that hijacks any action the user performs (such as key presses, mouse position, response data). Finally, all hijacked data should be sent to your attack server. To bypass cross-origin resource sharing (CORS), you can use images to send HTTP requests in which the hijacked data is embedded.

This workflow illustrates why stored XSS is considered high-impact and how it can covertly persist and continuously exfiltrate sensitive data from multiple users:

Document object model (DOM) XSS bugs happen entirely on the client side, when insecure JavaScript code dynamically modifies the DOM. DOM XSS may appear due to unexpected mutations or improper sanitization of user input when new HTML code is being created.

XSS attacks and exploitation: The ultimate guide to cross-site scripting

Endpoint and parameter discovery are critical first steps in the Bug Bounty reconnaissance process. The real value lies in uncovering hidden endpoints, undocumented parameters and overlooked paths that expand the target’s attack surface. 

This guide will teach you practical techniques like parameter fuzzing, forced browsing, and path/parameter discovery, as well as how to use targeted wordlists, parse files and analyse JavaScript in order to find entry points for more rewarding vulnerability hunts.

Initiating reconnaissance: building your baseline

The first step in uncovering hidden endpoints and parameters is to establish a baseline understanding of your target’s exposed surface. Start by configuring Burp Suite for a manual crawl: enable the proxy to capture all traffic, and ensure JavaScript and CSS files are not blocked. Once this manual pass gives you a feel for the application’s structure, complement your findings with an automated Burp crawl. 

Scrape the robots.txt and sitemap.xml files for overlooked paths and use Google dorks. Also check out a related article we published recently, 

, to further enhance your parameter discovery process.

You’ll already start to have a clear, comprehensive view of your target.

Why JavaScript files are key for asset discovery

Modern web applications use JavaScript to manage user interactions, fetch data and shape site functionality. As a result, JavaScript files often hold critical insights that are neither visible in HTML nor easily guessable. For example, you may find references to specific API endpoints that a regular user would be unable to access through conventional means. Additionally, parameters that control feature flags or access testing endpoints might appear as variable names, function arguments or URL fragments inside these scripts.

Examining JavaScript source code helps you find undocumented APIs or parameters and understand how endpoints work. This context can enable more strategic testing – revealing which parameters are worth fuzzing, which routes are likely to handle sensitive data, and where misconfigurations might exist.

The following tools are invaluable for analysing JavaScript:

Using LinkFinder to find hidden endpoints and parameters

 is a Python-based tool that crawls JavaScript files and extracts URLs, paths and parameters that could otherwise remain unnoticed. Running LinkFinder is straightforward:

This command scans the specified JavaScript file and outputs a list of discovered endpoints directly in your terminal. You can then integrate these findings into your fuzzing tools, add them to your wordlists or explore them manually in Burp Suite.

JavaScript bookmarklets: handy, quick recon tools

For fast, on-the-fly endpoint discovery, JavaScript bookmarklets provide a lightweight, browser-native solution. A bookmarklet is simply a snippet of JavaScript code saved as a browser bookmark. When clicked on any webpage, it immediately runs within the browser and extracts valuable information – such as hidden endpoints – without requiring external tools or switching contexts.

This approach is particularly useful when you’re already exploring a target application and want to quickly expand your understanding of its attack surface. Instead of pausing to set up additional scripts or tools, you can instantly run a bookmarklet to uncover new paths or parameters as you navigate.

Here’s a great bookmarklet for extracting endpoints from JavaScript created by 

Add a new bookmark in your browser’s toolbar

Replace the bookmark’s URL with the JavaScript code snippet

Visit the target page and click the bookmarklet. The script will run in your browser, revealing previously undiscovered endpoints right on the page.

By incorporating bookmarklets into your reconnaissance toolkit, you can seamlessly integrate endpoint discovery into your browsing experience.

Burp Suite extensions for JavaScript analysis

While standalone tools and bookmarklets are powerful, integrating JavaScript analysis directly into your primary testing environment can streamline your workflow. By adding dedicated Burp Suite extensions, you can automatically detect hidden endpoints and parameters as you proxy requests through Burp, keeping all your reconnaissance data in one place.

 is a popular Burp extension that parses JavaScript files intercepted by Burp. It identifies and reports parameters and endpoints directly in your Burp dashboard.

burp extension, meanwhile, specialises in parsing JavaScript for interesting endpoints and values. GAP can highlight unusual behaviour or sensitive variables within the code.

 offers a comprehensive approach to JavaScript analysis, revealing endpoints, parameters and potential vulnerabilities.

Fuzzing involves systematically sending varied, often unexpected inputs – such as paths, parameters or HTTP headers – to an application’s endpoints. Unlike conventional scanners that stick to known routes and values, fuzzing deliberately explores the unknown. By experimenting with large sets of inputs, you can trigger edge cases, uncover functionality never intended for public use, and reveal subtle weaknesses in the application’s logic.

One form of fuzzing, forced browsing, discovers hidden directories, backup files and development endpoints that developers never intended to expose. While forced browsing targets the structure of an application’s environment, fuzzing can apply the same testing principles to parameters, headers and more complex areas of the application.

In the context of Bug Bounty reconnaissance, fuzzing isn’t simply guesswork. It involves leveraging well-crafted wordlists, selecting the right tools (such as ffuf or dirb), and using structured approaches offered by platforms such as Burp Intruder. This informed methodology ensures efficiency and precision, broadening your search for hidden directories, parameters and routes that could lead straight to overlooked vulnerabilities.

probing unlisted directories, files or endpoints to reveal backups, test areas or deprecated components.

 By testing for undocumented or unexpected parameters in application requests, researchers can uncover weaknesses in how applications handle input. Parameter fuzzing serves two key purposes: discovering new parameters that the application processes, such as hidden or undocumented GET and POST parameters, and exploring the potential values of these parameters to identify vulnerabilities like injection attacks, logic bypasses or insecure data handling. This dual approach makes parameter fuzzing a versatile and powerful technique in bug bounty reconnaissance.

Tweaking HTTP headers to discover server misconfigurations, debugging information or services running behind the scenes. This provides intelligence that can shape your subsequent attack strategies.

Why Is fuzzing crucial for asset discovery?

Fuzzing significantly expands the scope of your reconnaissance. Instead of limiting yourself to known pages or documented endpoints discovered previously, you cast a wider net over the target’s infrastructure, looking for anything that responds in an unexpected way. This broader perspective increases your chances of uncovering meaningful, hitherto undiscovered bugs. More specifically, fuzzing enables you to:

: Many web applications and APIs contain paths not linked in the user interface – like old admin panels, forgotten test endpoints or development scripts. Fuzzing systematically tests for these, catching assets that would be invisible through traditional navigation.

Identify misconfigurations or access control issues

: Sometimes, unexpected responses like HTTP status codes (eg, a 200 OK on a directory that should be restricted) signal a configuration slip-up. Fuzzing makes spotting these anomalies straightforward.

Automate the exploration of application behaviour

: Checking each path or parameter by hand is impossible. Fuzzing tools let you run through extensive wordlists and payload sets automatically. This accelerates your workflow, ensuring you don’t miss critical targets that might yield valuable information.

Gain a deeper understanding of how the target application functions

: By watching how the app reacts to unfamiliar input, you gain insights into its underlying logic, error-handling routines and fallback mechanisms. These findings can guide more targeted attacks later, making your overall testing strategy smarter and more efficient.

With fuzzing, you’re doing more than just ‘poking around’ in a scattergun fashion. You’re methodically mapping the application’s structure to expand and understand its potential attack surface. Done properly, this process significantly increases your chances of discovering impactful vulnerabilities that could earn you juicy bounties.

: Start with endpoints you’ve already discovered through manual crawling, JavaScript analysis and forced browsing. Make a list of these URLs and note any parameters or query strings that might be worth exploring. Having a well-defined baseline ensures you focus on meaningful targets rather than blindly testing the entire application.

: Even well-protected applications sometimes rely on predictable naming conventions, leftover backup files or default directories that developers assume won’t be found. Taking advantage of these assumptions, forced browsing involves systematically guessing file paths, directories and extensions to access hidden or restricted resources. Rather than relying solely on automated tools with arbitrary wordlists, you can apply informed intuition – trying out common paths like /admin, testing for backup files by appending 

: After you’ve identified core files – like 

– consider probing for backup versions. For example, try appending common backup extensions or variations:

Sometimes these leftover files contain sensitive data, such as database credentials, API keys or configuration details. Combine this approach with your previous discovery methods: if JavaScript hinted at a config directory, test variations like 

Exploring common administrative or juicy directories

: Administrative panels or promising directories are frequently stored under predictable paths. Test common directory names such as:

If you know the target uses a particular technology (eg, WordPress), also try platform-specific directories like 

 Discovering these panels can reveal areas with weaker authentication checks or outdated management tools. Once found, you can inspect these endpoints for logic flaws, insecure defaults or old testing interfaces that developers never removed.

Wordlists: your irreplaceable tools for effective recon

Wordlists guide your fuzzing by providing inputs to test against endpoints and parameters. Using the right wordlist will be a game-changer for your recon. Use reputable collections of wordlists for paths, parameters and more such as 

: General-purpose wordlist for common endpoints.

: Tailored to the programming language of your target

: Tailored to specific technologies such as 

You can also refine these lists using data gathered in earlier steps – for instance, from JavaScript files, by adding parameter names or endpoint fragments found in the code, or from forced browsing, including any interesting directories or filenames that turned up as partial matches or hinted at backup files.

By customising your wordlists, you align your fuzzing efforts with the target’s unique environment rather than relying solely on generic guesses. You can also generate your own wordlists using tools like 

, which extracts keywords from a target’s website.

 are widely used for fuzzing because they are fast, flexible and easy to configure. For example, you can perform:

Use custom wordlists to brute-force paths and uncover hidden files or folders.

Identify undocumented GET or POST parameters by using specific parameter-based wordlists.

Before you hit ‘Run’, adjust your tool settings to maximise efficiency and relevance:

: Limit output to specific status codes or response sizes to highlight unusual findings.

: Set a comfortable number of parallel requests (eg, -t 10 in 

: Use refined wordlists that incorporate insights from previous discovery methods, ensuring that fuzzing inputs are both broad and targeted.

, which includes built-in wordlists and can quickly identify resources by simply inputting the target URL.

Burp Intruder is super-handy for parameter fuzzing, as you can send multiple payloads to known parameters and analyse how the server responds. You can also script custom fuzzing routines using Python tools or automation frameworks if you need more specialised testing.

In the Intruder section, you can set up custom fuzzing attacks by marking parameters, loading payloads and starting the attack. You can generate your own payloads, such as numeric ranges, character lists or even custom wordlists, directly in Burp.

: Intruder is particularly helpful for automating tests for vulnerabilities like IDOR (Insecure Direct Object References).

Analysing, iterating and integrating findings

Once you have gathered your results, sort through them to identify promising leads. Incorporate newly discovered endpoints or parameters back into your testing pipeline, for example by:

 Add unique filenames, directories or parameters that emerged.

 If certain responses hint at SQL injection, XSS or authentication bypass, tailor your next fuzzing round with more specialised payloads.

 Feed new findings into other approaches, like forced browsing of different directories or running advanced parameter fuzzing on newly revealed endpoints.

Bonus: exploring header fuzzing techniques

HTTP headers can also expose interesting information about the application, such as:

Bug Bounty Recon Series #1: Discover and Map Hidden Endpoints and Parameters

 extension that automates the assessment and exploitation of signed web tokens. Supporting various token types, including Django, Flask, and Express, it enables you to edit, sign, verify and attack these tokens. 

The extension features automatic detection and in-line editing of tokens within HTTP requests/responses and WebSocket messages. It includes prebuilt wordlists for default secret keys and salts, plus support for JSON-encoded strings and custom dictionaries. Users can save known keys for future attacks and modify signed tokens in Proxy and Repeater message editors.

Inline editing of tokens within HTTP requests/responses and WebSocket messages.

Includes default secret keys and salts, plus support for custom dictionaries and JSON-encoded strings.

Automates brute force attacks using known keys and different derivation techniques.

Supports multiple bypass attacks, including user claims, and Flask and Express claims.

 Detects and analyses unknown signed tokens using various hashing functions.

SignSaboteur can be installed from the BApp Store. A tab within the Repeater provides easy access to various functionalities, such as "Brute force", "Attack" and "Sign". The plugin settings, such as default implemented wordlists, can be found higher up in Burp Suite itself.

Case Study: Finding Secret Keys for Unknown Signed Web Tokens

Consider a scenario where you are testing an application that uses custom-signed web tokens for authentication. You need to determine the secret key used to sign these tokens to evaluate potential security flaws.

When dealing with unknown signed web tokens, SignSaboteur provides a robust method to identify and exploit potential vulnerabilities.

When you select "Unknown" in the "Enabled signers" menu, the extension looks for patterns that match the size of common hashing functions. Some message payloads might be incorrectly identified by SignSaboteur, and therefore require further manual inspection.

The extension supports various message and key derivation techniques used in brute-force attacks, eliminating the need for manual changes. To find the secret key of an unknown signed token:

Uses a combination of known key derivation techniques for a more efficient search.

 Includes slow hashing functions like Password-Based Key Derivation Function 2 (PBKDF2). Use this mode with caution, and only with small wordlists, as it can be time-consuming.

Account User Claims, Authenticated Claims, User Access Token Attacks

Some frameworks use account wrappers to store authenticated user information, which may require the use of authenticated claims for exploitation. SignSaboteur supports this by implementing 12 well-known authorisation flags.

Learn Bug Bounty

Top web hacking techniques of 2024, McDelivery hijack, 4D SOTA jailbreak – ethical hacker news roundup

XSS attacks and exploitation: The ultimate guide to cross-site scripting

Bug Bounty Recon Series #1: Discover and Map Hidden Endpoints and Parameters

PimpMyBurp #11 – Master Signed Token Exploits with SignSaboteur

Dom-Explorer tool launched to reveal how browsers parse HTML and find mutated XSS vulnerabilities

White-box penetration testing: How to debug for JavaScript vulnerabilities

PimpMyBurp #11 – Master Signed Token Exploits with SignSaboteur

Top 5 hacking tools for white-box pentesting

White-box penetration testing: Debugging for Python vulnerabilities

Limitations are just an illusion - advanced server-side template exploitation with RCE everywhere

Top 5 hacking tools for white-box pentesting

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

How to write an effective Bug Bounty report

Smart Automation With Burp Suite

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

Products

Researchers

Resources

Company

Follow us