 publishes articles on exploitation techniques, tools and tips to help hunters find vulnerabilities in their reconnaissance process and hunting routine. The goal is to provide ideas and keys to attack and understand the various web technologies hunters may face on their private programs.

Web applications & APIs are often the highly exposed asset of any organization. With the use of modern frameworks, the development process becomes handy and faster. However, often the developers leave some 

unlinked, unreferenced or unintentionally/accidentally open for use. Often, attackers may utilize these to perform attacks such as Cross-Site Scripting (XSS), Open Redirection, Server-Side Request Forgery (SSRF), SQL Injection and others.

In this article, we will be discussing identifying the hidden attack surface by identifying the hidden parameters.

The process of identifying unlinked, unreferenced or simply hidden parameters that are accepted by the application and could allow a user to control the behaviour of the application using these hidden parameters is often known as 

As mentioned, the hidden parameters may allow an attacker to control the behaviour of the application and may result in the execution of successful attack scenarios such as Cross-Site Scripting, Open Redirection, SQL Injection, Local File Inclusion, Command Injection, Server-Side Request Forgery, Server-Side Template Injection and other security vulnerabilities such as an IDOR.

Hence, it is an essential step to perform 

as part of your Recon process for building an attack surface that is inclusive of the Hidden Attack Surface through these parameters. This often helps bug bounty hunters and security professionals to find unconventional and high reward paying bugs.

Since the purpose and motivation behind identifying the 

is now clear, let’s look for different tools & methodology to perform parameter discovery.

Tools for performing Parameter Discovery:

Arjun is a python based command-line tool that helps in the detection of the parameters present in the application. By default, the tool utilizes a custom wordlist to check for the parameters but this can be modified by the user to set their own parameters.

Detailed information and installation instructions can be found on the official repository of the Arjun tool:

Run the following command: arjun -u https://demo.testfire.net

Observe the parameters returned by the tool.

Note: By default, the tool uses GET request method but you can define other methods such as POST by using -m flag. Ex: python3 arjun.py -u https://target.com/test -m POST

ParamSpider is a python based command-line tool that helps in the identification of the parameters. It has the ability to find parameters from web archives, subdomains and other sources as well. This is one of the most effective tools to identify the parameters.

Detailed information and installation instructions can be found on the official repository of the ParamSpider tool:

 https://github.com/devanshbatham/ParamSpider

Finding Hidden Parameters with ParamSpider

Run the following command: python3 paramspider.py -d <target_domain> –level high

Param-Miner is a Burp Suite Extension that is handy and useful to find hidden and unlinked parameters that are specifically useful while looking for the Web Cache Poisoning related vulnerabilities.

Detailed information about the extension can be found here:

 https://github.com/PortSwigger/param-miner

As per the official GitHub Repository, the tool combines advanced diffing logic from Backslash Powered Scanner with a binary search technique to guess up to 65,000 parameters names per request. Param names come from a carefully curated built-in wordlist, and it also harvests additional words from all in-scope traffic.

To use it, right-click on a request in Burp and click “

”. If you’re using Burp Suite Pro, identified parameters will be reported as scanner issues. If not, you can find them listed under Extender -> Extensions -> Param Miner -> Output

In this section, we will look at a simple example of chaining multiple tools to perform parameter discovery and further utilize the identified parameters to check against cross-site scripting using tools such as KXSS.

First, let’s perform parameter discovery using ParamSpider:

Now, We have all the parameters identified, let’s run XSS GF patterns to extract the parameters that could be vulnerable to XSS:

on the URLs that are potentially vulnerable to XSS:

Observe that we have found some valid Cross-Site Scripting Issues

As we were able to find valid cross-site scripting issues, you can also attempt to write your own one-liners or small scripts to automate other security vulnerabilities as well.

Thank you for reading the article till the end and we hope you have learned something new. Make sure to check out the programs on the 

 platform and apply your newly learned skills to find some interesting security vulnerabilities. We will be back with some other interesting articles soon.

Parameter Discovery: A quick guide to start

, is launching the first live Bug Bounty event dedicated to European scale-ups and unicorns!

The idea was born in September 2021, during the 

Why not organise an event that would encourage all French scale-ups and unicorns to collaborate with ethical hackers, all in a fun and friendly atmosphere?

After some discussions with the unicorn Blablacar, already familiar with Bug Bounty with its 

 on the YesWeHack platform, then with Malt, the idea became a reality! The first edition of Hack Me I’m Famous will happen on 13 & 14 April 2022 at the 

13 & 14 April 2022 – A Promising First Edition

For this first edition, YesWeHack called on around fifty of the best European hackers to come and challenge the information systems of Doctolib, Blablacar and Malt. For more than 30 hours, day and night, the hunters will try to find vulnerabilities in the partners’ information systems. If they succeed, they will receive rewards based on the reward grids as well as unique goodies and special prizes!

For corporate security teams, it’s a unique and invaluable opportunity to discuss their findings with researchers, and better understand security bugs. For hackers, it’s an easy way to ask live questions to program managers and YesWeHack’s teams to get more information about the programs and thus go even further in their research. Furthermore, researchers may collaborate with each other to pool their skills and expertise and thus go further in the hunt for new vulnerabilities and exploitation. 

In a nutshell, a live Bug Bounty is an amazing experience for everyone to get to the top!

Alongside the live Bug Bounty, a workshop of the 

, of which YesWeHack is a member, will take place on the first day of the event. The SPARTA project is a novel Cybersecurity Competence Network supported by Horizon 2020, aiming to develop and implement excellent R&I actions and to ensure digital security and strategic autonomy of the EU. Strongly guided by concrete challenges, this workshop aims to gather the European ethical community to discuss their contribution to the European cybersecurity. 

You can download the SPARTA workshop programme here

This event aims to be replicated every year, with new scale-ups and unicorns joining every year. If you are interested in the initiative and would like to discuss with our teams, we invite you to contact us.

This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 830892.

Founded in 2015, YesWeHack is the #1 European Bug Bounty & VDP Platform. YesWeHack offers companies an innovative approach to cybersecurity with bug bounty (pay-per-vulnerability discovered), connecting tens of thousands cybersecurity experts (ethical hackers) across 170 countries with organizations to secure their exposed scopes and reporting vulnerabilities in their websites, mobile apps, infrastructure and connected devices. YesWeHack runs private and public programs for hundreds of organizations worldwide in compliance with the strictest European regulations.

In addition to the Bug Bounty platform, YesWeHack also offers support in creating a Vulnerability Disclosure Policy (VDP), a learning platform for ethical hackers called Dojo and a training platform for educational institutions, YesWeHackEDU. For more information: 

The first live Bug Bounty for European scale-ups and unicorns

Smart contracts security has had an increasingly bad reputation over the last few years, with over 

 worth of cryptoassets stolen in this first quarter of this year alone. The need for whitehat hackers to help protect smart contracts has never been higher.

This article is a guest blog post written by 

Smart contracts are blockchain computer programs that execute when established conditions are met by some counterpart. The typical real-world analogy for smart contracts are 

. When a customer sends money to the vending machine, and some indication of which snack to dispense, the machine validates that certain pre-established conditions are met before dispensing the snack. In this case, the machine validates that the money received for the selected snack was enough, and that there is sufficient stock of the selected snack. The vending machine’s internal validation and processing removes the need for a shopkeeper to perform the same actions, and this idea is generalised to smart contracts to execute arbitrary actions such as exchanging and transferring assets, taking out a loan and more, each action with their own set of pre-determined conditions.

For this post, I’m going to be talking about smart contracts in general, but I’m referring to contracts that run on the EVM, the Ethereum Virtual Machine. The EVM is a virtual machine that enables the execution of smart contracts and is what updates the state of smart contracts as transactions are processed. There are several EVM-based blockchains, and the information in this blog can be used interchangeably.

Why are smart contracts good targets to hack?

Compared to Web3 vulnerabilities, a blackhat will generally need to make an extensive effort to find a way to monetize their Web2 vulnerabilities, such as setting up a spear-phishing campaign in hopes to trick victims into sending them money. In the case of smart contracts, a single mistake in a smart contract could lead to irreversible theft of millions of dollars, which has already happened 

. Smart contracts are excellent targets for hackers due to it’s ability to 

, and with the complex smart contract code 

 being immutable, it may take just one error to compromise the entire protocol. To reflect the growing need for whitehat hackers, project teams have stepped up and have started to offer larger and larger bounties, with bounties 

up to $10m offered for critical vulnerabilities

The most popular smart contract language for smart contracts is 

. Since most protocols open-source their smart contract code, there is less need to rely on intermediary steps like reconnaissance, compared to traditional web bug hunting. This means that being able to read and understand the code will be your most powerful tool to find bugs, more so than any kind of automated tooling. To this end, you should spend plenty of time with smart contract development. This means following beginner syntax tutorials like 

. Understanding the basics such as the importance of correct function visibility, or why private state variables can still be freely read beyond the smart contract level, are vital to building a solid foundation.

As you start reviewing code for bugs, you’ll want to test out any leads you may have. However, since smart contracts live on blockchains, it’s very important to not test out any potential exploits on mainnet or testnets. That’s because blockchains are very transparent, in the sense that anyone can read exactly what you’re trying to do when interacting with a smart contract. A bad actor may notice what you’re attempting to do and front running to exploit the issue you’ve picked up. To get around this, most researchers make use of mainnet forks: a simulated environment that replicates blockchain state up until some block height. This allows anyone to test their exploits with existing contracts in their current state, without broadcasting what they’re doing to the actual blockchain. I’ve already written a separate blog post on how to do this, which can be found 

Once you have the basics down, the next step should be upskilling yourself to learn about the different security practices and common vulnerabilities related to smart contracts. The best way to do this would be to play CTFs (

) and wargames to learn how to exploit intentionally vulnerable smart contracts. There 

, with one of the most popular materials being 

 due to its easy setup and progressive difficulty. Other popular training materials are 

Beyond training, there are some other general tips to stay up to date with the smart contract security scene. Since the space is incredibly fast-paced, it’s helpful to always get updates in real time from projects. This means following prominent personalities on Twitter (I’ve found Twitter to be the most up-to-date and reliable source of news), as well as joining the local hacker communities on Telegram, Discord etc. Beyond community, it’s important to take initiative wherever possible. Learning about how the latest exploits work under-the-hood will give you a notch above hunters who aren’t familiar with the new pattern. For example, trying to replicate exploits detailed on 

 is an excellent way to keep your skills sharp.

Lastly, once you have the basics and some training under your belt, I’d recommend just diving into some targets from a smart contract 

. This where you’ll gain the most experience compared to any of the above tips, since you’d be reviewing production code (or staging code, occasionally) and you’ll hopefully be stumbling on some bug leads that you’d want to test on your local fork. Many of your bug leads may lead to dead ends, but each dead end should come with a valuable lesson that you can take with to your next hunting session. For example, you may think you’ve found a way to drain assets from a Uniswap V2 pool, only to realize how the constant product formula was enforced in the code. Each failure should teach you something, even if it’s not obvious at the time.

I thought it would be interesting to detail what a bug hunting session might look like, so I’ll demo a walk through of a simple (but critical) vulnerability I 

. To find interesting targets, I’m usually looking through 

, but I also enjoy keeping an eye out on Twitter for interesting opportunities. I stumbled on this 

 and got the 3 relevant contract addresses after DM’ing abwagmi. The 3 contracts are AxonsToken, AxonsAuctionHouse and AxonsVoting. Immediately, we can see what the contracts inherit and we can start asking the following questions:

Are the parent contracts (ERC20, Ownable) standard contracts (e.g. written by OpenZeppelin), or are they custom written contract by the dev?

Are any of the ERC20 functions overridden?

Where is the owner role used? Are there any functions that should have made use of the owner role, when it didn’t?

Are the parent contracts standard contracts or are they custom written contract by the dev? (This question should be asked for pretty much all contracts)

Which functions does the important pause function affect? Is there relevant access control to prevent attackers from pausing the contract?

Where is the reentrancy guard used? Why is it necessary? Was it implemented correctly, and does it handle reentrant tokens?

Where is the owner role used? Are there any functions that should have made use of the owner role, when it didn’t? (Again, any time access control roles are imported they should be inspected closely for their intended use compared to what was actually implemented)

Are the parent contracts standard contracts or are they custom written contract by the dev?

You should notice that even by inspecting just a few contracts we already have some overlap in things to check with regards to access control, reentrancy and custom imported contracts.

After starting to answer the above questions, you’ll notice that our second question for AxonsToken has an interesting answer: The transferFrom function is overridden. Immediately, an overridden function that handles token transfer should be inspected closely. To understand any issues relating to the transferFrom function, you’ll need to understand how transferFrom works in 

The transferFrom function is used to transfer tokens on behalf of another user, provided they set some prior allowance on the number of tokens to transfer. In the case of the AxonsToken transferFrom function, the dev was hoping to circumvent the need to approve the auctionHouse contract to save on gas costs and immediately proceed with a transfer if the sender or recipient was the auctionHouse contract:

While the function is ‘functional’ in the sense that it does circumvent the need to approve the auction house, there is a flaw in the way we validate that the sender is who they say they are. Right now, there is no check that the person performing the transfer is the sender or the auctionHouse. This means we should be able to do 2 things:

We can move tokens from any user to the auctionHouse contract: transferFrom(victim, auctionHouse, balance).

We can move tokens from the auctionHouse contract to any user: transferFrom(auctionHouse, attacker, balance).

Putting these to points together means we can sweep all user balances to the auctionHouse contract, and then move it back to ourselves to steal the entire token balance! Of course, this seems great on paper, but we need to validate it with a 

 and use your Etherscan key from the previous step.

Once setup, your hardhat config should look similar to the following:

Note that since the contracts were deployed on Rinkeby, we need to specify chainId: 4 and a relevant block number to Rinkeby. In this case, any block number after the contract was deployed will work, but in general it will depend on the state you want to test against. (e.g. something happened after block x, so fork from block x+1)

Before we write the POC, we want to test that the fork is working as intended and that the correct state is being fetched. A simple way to do this is to create a file in the test folder and print some state, such as the current owner:

Run the test and confirm that it matches the correct owner (e.g. by reading the owner from Rinkeby Etherscan):

The owner address matches the state of the chain, so we can start building our POC. We want to code the following steps:

Move both accounts’ balance to the auction house contract

Move the auction house contract balance to some third address

A successful test confirms that we can move arbitrary token balances to and from the contracts. Start by funding 2 accounts through the devmint function (Note that this function was confirmed to be used on testnet only, so this arbitrary mint is not a bug).

Then, from the context of a different account (see that accounts[3] is used), move the tokens from account 1 and 2 to the auction house contract:

And finally, pull the auctionHouse balance back. In this case, account 3 is pulling the balance back to their own account:

And the test confirmed our idea – we can arbitrarily move anyone else’s token balances around, leaving everyone’s balances vulnerable to theft. The 

 would be to check that the sender is indeed the msg.sender, or that the auctionHouse is performing the transfer.

An actual hunting session should then end by writing a report for the dev – this is easily the most important part of effective bug hunting since it should precisely detail the issue, impact and fix. Unfortunately, report writing is out-of-scope for this tutorial 🙂

Over time, everyone develops their own techniques for hunting. There is no single correct technique, but I think it’s important to identify the style of hunting you prefer, and optimize for it. For example, you could prefer to hunt for bugs in a staging environment, in which case you’d prefer to find bugs on projects hosted on 

. In this case, it would make sense to read 

 to get a sense of the type of bugs other wardens have found. Alternatively, you may prefer to find bugs on deployed contracts, in which case you may look for targets hosted on 

. In this case, getting comfortable with mainnet fork testing, or quick heuristic testing with 

 will help your test your ideas quicker than other hunters, and prevent the chance of getting duped.

You could refine your hunting style further to look for common code-level bugs, or dig deeper to find contextual bugs. If you prefer to find common code-level bugs, such as an 

, it would make sense to iterate through all available targets as opposed to diving deep to fully understand all of a project’s nuances. On the other hand, if you are looking to find contextual bugs, it would make sense to read available audit reports to see what auditors have already highlighted as sensitive points. Even if the bugs are patched, you’ll get a sense of critical functionality, which may have changed since the code was frozen for an audit. Finding deep contextual bugs for a project has an additional advantage for hunters since many 

, meaning that your report will be valid across multiple targets from just one bug.

Lastly, as with traditional Web2 bug hunting, it’s important to just keep going! Keep testing and reviewing code, keep learning what new exploits are in the wild and you’ll come across valid bugs very soon. GLHF! 🙂

Getting started with smart contract in Bug Bounty

iOS is a widely used platform and in the previous article 

Getting Started with iOS Penetration Testing (Part 1)

, we discussed basic concepts of the iOS platform, different attack scenarios in static analysis and touched on the basic concepts to get started with the iOS penetration testing.

In this article, we will focus on a more advanced approach and continue solving other challenges available in our test application DVIA-v2, some important tools, and also look at the OWASP Mobile Top 10. This article will give you good knowledge to confidently perform a penetration test on an iOS application.

a list curated from research and feedback that identifies types of security risks faced by mobile applications

. The current version of OWASP Mobile Top 10 at the time of writing this blog is 

The first category in the list of OWASP Mobile Top 10 covers the aspects where an attacker can abuse the security control features provided by the iOS platform. In addition, sometimes due to failure in the proper implementation of platform features, multiple security issues could arise.

There are multiple components that are required to be analyzed under this category such as 

Biometric Authentication, Keychain, Platform Permission, etc.

Some of the general risks that occur under this category are:

Bypassing Local Biometric (Touch/Face ID) Authentication [Explained in Part-1]

The iOS applications often store some data locally in different components. There is a chance of getting sensitive data stored in the local storage that could be exploited if an attacker has access to the physical device of the user.

Most of the above-mentioned test cases were discussed in part-1 of the series.

The iOS application communications on a client-server architecture. Due to improper/weak implementation of the communication standards such as communication over HTTP, an attacker can attempt to steal sensitive information over unencrypted checks, perform Man-in-the-Middle or attempt to analyze the request/response by capturing them with proxy tools such as Burp Suite.

Communication over HTTP [Unencrypted Communication]

Plain-Text Submission of Sensitive Information

Logging Sensitive information in the Logs

When an application fails to properly perform the authentication checks or allows an attacker to manipulate the login/authentication requests to gain access to the victim user’s account, it is generally considered under the Insecure Authentication category.

Authentication Bypass using attack such as Injection Attacks

The iOS applications tend to store the user data or utilize the user data in different client-server requests. Due to a lack of strong cryptography, an attacker may attempt to access the data that is encrypted using the weak cryptographic method and gain hold of sensitive information.

Accessing Encrypted Client-Server Request Endpoints

The insecure authentication and insecure authorization are usually two checks which cause confusion. This attack talks about abusing the weak implementation of user authorization checks to perform attacks out of the user’s privilege and access level.

Due to the poor code quality, often, an attacker may attempt to pass the crafted inputs to function calls made within an app in an attempt to execute them or observe the application’s behaviour. It may lead to some mal-function and exploitable scenarios in the application.

If the application does not implement the code tampering checks, an attacker may attempt to modify the application code and inject malicious code such as a backdoor and distribute it using App Store and other methods that could lead to stealing sensitive information and comprising the user’s device as well.

The reverse engineering approach involves analyzing the binary and it’s code using tools such as Hopper, otool, IDA Pro in order to understand the application’s code patterns, various function implementation and performing bypass/attacks using runtime & dynamic instrumentation approaches.

One of the common examples is to analyze the implementation of SSL Pinning logic and understand the functions that are responsible for pinning checks and using tools such as Frida to bypass it by writing a custom logic script.

In general, before pushing an application to production, the development team keeps code to have easy access to the backend server, create logs to analyze errors or carry staging information and testing details. This code is extraneous to the functioning of the app. Basically, It has no use for the intended use once the app is in production and it is required only during the development cycle.

In certain cases, this code can carry information related to databases, user details, user permissions, API endpoints, etc. or disable functionalities like two-factor authentication.

Since we are now aware of the common security vulnerabilities that are often found in the iOS application, next we will be looking at some of the attack vectors using the 

application and also attempt to see how API analysis looks for the APIs originated from iOS devices.

It is recommended to read the attack description for each section provided in the application to understand the scenario we will be exploiting.

Launch the DVIA-v2 application and navigate to the 

Now, run the fridump tool on the application to extract the information from memory


https://github.com/Nightbringer21/fridump

Command: python fridump.py –usb -s DVIA-v2

file and search for sensitive information such as passwords and observe that the sensitive information was found in the application memory.

provide a malicious cross-site scripting payload such as 

Observe that the webview unsafely rendered the input and resulted in Cross-Site Scripting (XSS).

Ghidra to bypass the Anti Hooking and Debugging controls is nicely explained in the following blog:

https://philkeeble.com/ios/reverse-engineering/iOS-Anti-Anti-Hooking/

Launch the DVIA-v2 application and navigate to Side Channel Data Leakage > App Screenshot.

Add Some Information in the input field and background the application

/var/mobile/Containers/Data/Application/DVIA-v2/Library/SplashBoard/Snapshots

Open the SceneId and observe that the screenshot is present containing the information.

Launch the DVIA-v2 application and navigate to Side Channel Data Leakage >Pasteboard

Hook the application using objection and run the following commands:


Now, add some input in the input box, copy it and observe that the content is visible on the objection console.

Getting Started with iOS Penetration Testing (Part 2)

 consisted in bypassing different security levels simulating the behavior of a WAF in order to execute JavaScript code in an arbitrary way. This DOJO was created by one of our community members. Thanks to Brumens for this great challenge!

 You want to create your own DOJO and publish it? Send us a message on 

We are glad to announce the #14 DOJO Challenge winners list.

The best writeups reports were submitted by: 

 feeds to be notified of the upcoming challenges.

Read on to find the best write-up as well as the challenge author’s recommendations.

Tell me a WAF that never been bypassed…?

We asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.

‘s report was well detailed and really useful to understand the logic and to get around the different filters. All the steps are clearly explained and it is very helpful for everyone to understand how they went about solving this DOJO.

‘s were also very nice, we’re sorry can’t publish them all because that’s where you clearly witness the outstanding creativity of our community. 

For DOJO Challenge #15, we are tasked with setting settings.user to Admin, and alerting or logging that value to the console.

Our injection point is inside of the alt attribute of a <img> element. Our input is filtered by Brumens “Firewall” before being injected. This “Firewall” filters many characters and keywords, but as we have seen so many times, it can be bypassed.

Source Code for the Challenge, with our filtered input being placed at $inject:

From the source code alone, this challenge seems pretty straight forward. Just get some javascript execution, then set settings.user = 'Admin';

The filters highlighted in yellow above the “URL Decode” filter, can simply be bypassed using URL encoded characters. The characters below the “URL Decode” filter can possibly be bypassed using hex or unicode characters, depending on where exactly we are trying to replace those characters.

Here I will talk about the development of the payload and show how it grows progressively.

Looking at the WAF, we will not be able to inject new HTML 

, but that is fine because we have event handlers still. First, we will need to get out of the alt attribute. We can simple do this by adding a " or %22 because it will be replaced with ", but that will not escape the quote in this case.

Now to inject our event handler, we will need a space, but all spaces are not allowed by the s filter. Luckily we can use a forward slash / and space interchangeably in HTML. The / is not allowed, but since it is not URL decoded first, we can use %2f.

Now, naturally, we need a event handler to execute our javascript. We will use onload. We can see that the WAF filters event handlers with this filter: on.*=, but since our payload isn’t decoded before checking for this, we can again just use a URL encoded character to bypass this.

Next, we need to set settings.user to Admin. We cannot access the user property of settings this way: settings.user because the . is filtered. But there is another way to access properties of an object like this settings['user']. But here we come across another problem. ' and " are replaced with ' and " respectively. Quotes worked to escape the alt attribute, but will not work here. But they left out the backtick within the WAF, which we can replace the quotes with backticks. We can also use the backticks for the Admin string as well.

Also, now that we are executing javascript, we need to make sure that it doesn’t produce an error with the " that is appended to our payload because of our injection point being inside of an attribute. We can simply add %2f%2f to the end of our payload, which is converted to //, in order to comment out the appended "

 %22%2f%6fnload=settings[`user`]=`Admin`;%2f%2f

After executing this, we can see that we have now set settings.user to Admin! If you are checking in the console, make sure you are executing the javascript within the iframe for the challenge.

Our next task is to pop an alert with that value. Let’s start with just a simple alert(1). From the WAF, we can see that we cannot simply use alert, but we can convert on of the character values to unicode as a bypass alu0065rt. But again, the WAF will escape the backslash like: alu0065rt. But we can just URL encode the backslash to get past this: al%5Cu0065rt. But the WAF blocks ( and ), so we cannot just do: al%5Cu0065rt(1). But we can replace the parentheses with backticks!

 %22%2f%6fnload=settings[`user`]=`Admin`;al%5Cu0065rt`1`%2f%2f

This alert with backticks will only work with strings though, and we need to alert some form of settings.user. One way to still use backticks instead of parentheses and access variables, is to use setInterval. And we can hex encode special characters inside of the backticks for them to be evaluated: setInterval`alertx28settings.userx29`;. This will work in the console, but there are still problems we have to bypass. We already know that we can use settings[`user`]=`Admin`; instead of settings.user. But if we put that inside of the setInterval, the nested backticks will cause a problem. So we can just set a variable equal to that.

 %22%2f%6fnload=settings[`user`]=`Admin`;temp=settings[`user`];%2f%2f

Now that we don’t have to worry about nested backticks, our setInterval looks like setInterval`alertx28tempx29`;. We know we have to replace alert with al%5Cu0065rt. The last thing that is causing a problem is the for the hex encoded parentheses. For this, we can simply URL encode the backslashes. Then we have our final payload!

DOJO CHALLENGE #15 Winners!

Subdomains Tools Review: a full and detailed comparison of subdomain enumeration tools

 gave the opportunity to perform a SQL injection where the 

The YesWeHack Blog

Parameter Discovery: A quick guide to start

The first live Bug Bounty for European scale-ups and unicorns

Getting started with smart contract in Bug Bounty

Parameter Discovery: A quick guide to start

Getting Started with iOS Penetration Testing (Part 2)

DOJO CHALLENGE #15 Winners!

Subdomains Tools Review: a full and detailed comparison of subdomain enumeration tools

Getting Started with iOS Penetration Testing (Part 2)

DOJO CHALLENGE #19 Winners!

DOJO CHALLENGE #18 Winners!

Demand for crowdsourced security booms: YesWeHack bug bounty platform continues to thrive

DOJO CHALLENGE #19 Winners!

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous