, the leading European drone group, is launching its Bug Bounty program with 

, the first European crowdsourced security platform.


Through this partnership, Parrot benefits from 

’s vast community of cybersecurity researchers to identify potential vulnerabilities in its drones, mobile applications and WebServices.

 will initially give exclusive access to selected security researchers and will include future Parrot drone models. The expertise and diverse skills of the researchers will confirm the high level of security of the products before they are marketed, for the greater benefit of Parrot users’ security and the protection of their data.

– After a first phase in a private Bug Bounty program, and after being commercialized, the products will enter a

. Their security will then be scrutinized by the entire YesWeHack community, representing more than 22,000 cybersecurity researchers.

Cybersecurity is a priority for Parrot. Parrot provides its users with full transparency on the security of their data and has conducted numerous security audits on its products, both internally and by its customers. The complete assessment conducted by Bishop Fox, one of the most recognized private companies for professional offensive security services, is published on its 

“After the integration of cybersecurity from the initial design phase of Parrot drones, the Bug Bounty launched with YesWeHack completes the audits and brings an additional step of control. In the event of a flaw, YesWeHack’s community of cybersecurity researchers will detect it and allow Parrot to correct it, before real attackers can misuse it.”

, Chief Security Officer and CTO Cybersecurity of the Parrot Group.

“We are delighted to support Parrot in its commitment to the drone and user’s data security. The richness and diversity of the YesWeHack community offers the spectrum of skills required to cover the full range of perimeters, whether hardware or applications. The public Bug Bounty phase, which will take place in a second phase, will allow Parrot’s products to be confronted with the expertise of several thousand researchers, thus reinforcing its transparency in cybersecurity.”

Founded in 1994 by Henri Seydoux, Parrot is today the leading European group in the fast-growing industry of drones. Visionary, at the forefront of innovation, Parrot is the only group to be positioned across the entire value chain, from equipment to services and software. Parrot, the world’s number 2 of the consumer drone market, designs drones known for their high performance and ease of use. Parrot has a portfolio of outstanding companies and interests in commercial drones, covering equipment, software and services. Its expert capabilities are focused primarily on three vertical markets: (i) agriculture, (ii) 3D Mapping, Surveying and Inspection, and (iii) Defense and Security.

The Parrot Group designs and engineers its products in Europe, mainly in France and Switzerland. It currently employs over 500 people worldwide and makes the majority of its sales outside of France. Parrot, headquartered in Paris, has been listed since 2006 on Euronext Paris (FR0004038263 – PARRO). Financial information can be found on http://corporate.parrot.com. For more information: 

Founded in 2013, 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 

, a learning platform for ethical hackers called 

 and a training platform for educational institutions, 

Parrot launches its Bug Bounty in partnership with YesWeHack

 was on finding a way to bypass 3 security mechanisms to prevent a SSRF and to retrieve a secret flag.

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

 feeds to be notified of the upcoming challenges.

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

EvilCorp2.0 has a script to check the current state of an internal service. They want to make sure that this script, with all its security, cannot be used to retrieve the 

 path…Find a way to bypass all security mechanisms to retrieve the /secret.

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.

‘sreport was detailed, informative, and good at explaining the logic to bypass every security mechanisms in script to finally obtain the secret flag hidden in /secret.

‘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 the latest addition to the Dojo series, we’re faced with the challenge of fetching the secret that EvilCorp2.0 is storing on the /secret endpoint. To obtain this secret, we need to find a way through the security mechanisms that EvilCorp2.0 has put in place for their small app. Their app is created using Deno (https://deno.land/) and allows us to specify a URL as a string, which the server will fetch for us if it passes the security mechanisms.

The security mechanisms are implemented as a function called waf. The function takes a parameter of type ‘string’ called str. The function starts by creating a URL object named url by using the user-provided string:

The rest of the function implements 5 security mechanisms which do the following:

Skips all security checks if str (not the URL object) is equal to http://127.0.0.1:5000/ping

2. Makes sure that the port from url.port is 5000

4. Makes sure that url.pathname starts with /ping

 contain the substring /ping<ANY_CHARS>/.
The following would eg. not pass: http://example.com/smth/pingblabla/hihi

We now have a basic understanding of the app, so let’s exploit it! Let’s start by providing the string http://127.0.0.1:5000/ping which we now will pass the security mechanisms because of check 1 in waf

Cool, we got a ‘pong’ from the /ping endpoint. Let’s now bypass some of the security mechanisms! There doesn’t seem to be a reason we would want to bypass the ‘port’ check since we assume that the /secret endpoint exists on port 5000, so let’s move on to check 3. Hmm, this seems to be a pretty insufficient way to avoid requests to localhost. While we can’t use 127.0.0.1 or localhost, there's plenty of other options out there that will resolve to localhost. Simply '0' would often do! Let's try using the payloadhttp://0:5000/ping` to see if we can bypass this check and receive a ‘pong’:

Yup, it worked! Nice, let’s move on then. Check 4 ensures that the pathname property of the url object starts with the value /ping. This seems pretty hard to work around, but there’s one important thing to notice in the app’s logic! Notice that the url object only exists within the scope of the waf function, and that it’s actually the string, which is also named url (confusing, huh?) that’s provided as a parameter to fetch after the waf function is passed.

So why care about this? Well, wouldn’t it be nice if there was some inconsistency between the URL object in Deno and the user-provided string! What if eg. the pathname property of the URL object didn’t match the actual path being fetched when sending a request to the user-provided string? In other words: Can we craft a payload, which when used to create a URL object, causes some unexpected behavior?

Let’s create a test environment to test for inconsistencies in the Deno URL object. To do so, we can simply use the Dojo Playground!

We now have a simple app that logs the value of url.pathname for us. Time to test! Maybe some simple path traversal trick will do the job?

Hmm, sadly no. But maybe we could try and do some URL-encoding? But first, a quick example. Visting a URL like: https://example.com/ping/%2e%2e%2fhihi from most browsers would result in the following:

As we can see, we didn’t end up on /hihi but /ping/..%2fhihi instead. But the notice how the period chars were decoded… What would happen if we instead visited https://example.com/ping/%2e%2e/hihi? You guessed it:

The path was resolved to /hihi. Let’s try to apply this knowledge to our Deno test set-up and use the payload: http://0:5000/ping/%2e%2e/secret:

Would you look at that! Deno didn’t seem to care about our URL encoded period chars, and tells us that the pathname is simply /ping/%2e%2e/secret. But what will happen when we fetch this payload..?

Let’s head back to the challenge and find out!

Oh, we forgot about the last check… We can’t use any / chars after the string /ping. But could we maybe just use something else than / ? Well, how about some nice \ ! Let’s try with the payload http://0:5000/ping\%2e%2e\secret:

Voilà!🎉 We solved the challenge and retrieved the secret: flag{You just found a secret !}

Thanks for reading along!
Happy hacking,
holme

DOJO CHALLENGE #8 Winners!

You don’t stay ahead by standing still. Here at 

 we are continually innovating, exploring new ways to enhance the 

 platform, so you can identify, track, and triage bugs faster and more securely. And ultimately launch smarter software solutions ahead of rivals.

 introduces several new features, strengthening the platform’s position as a best-in-class vulnerability management and bug tracking integration solution.

First and most importantly, we’ve added even more flexibility into the reporting capability. In YesWeHack Tracker 2.1, we are closing the DevSecOps loop flow with feedback from development teams to security teams. Previously in 

, information flowed only in one direction – from security teams to development teams. Now it is bi-directional, enabling teams to collaborate seamlessly with one another on vulnerability reports, comments, feedback, and other insights.

Development teams, for example, can now share insights that confirm a problem is fixed and closed. That way, the researchers who discovered the bug can move on to test it – attempting to find a workaround that exploits the vulnerability. They may report that the fix works, or that there’s still a bypass that compromises the application. Agility is the watchword here: making it faster and easier for DevSecOps teams to collaborate and build a security foundation into DevOps initiatives.

Release 2.1 takes this control and collaboration into other dimensions too. Managers have complete control over who sees what and when. The manager can decide, for example, whether or not comments derived from the development team are included in the reporting. Researchers only see what the managers sanctions. This way, teams are not overwhelmed with irrelevant insights – they only see the issues relevant to their role, streamlining the vulnerability management process.

 Tracker is as intuitive as always – everything you need is available in a single, unified interface for faster, more intuitive DevSecOps. You simply set your credentials, and YesWeHack Tracker connects to your chosen bug tracker(s), whether it is GitHub, GitLab, Jira, or Jira Cloud. For example, you can set one program to connect with Jira, another to go to GitLab. You can select all comments to be posted to the GitLab bug tracker. Likewise, on one of the bug trackers, you could choose to synchronise only comments and not feedback. It’s all about total control from one interface.

2020 was a year of unprecedented change and uncertainty. 2021 is quickly evolving into more of the same. In this dynamic landscape, you need the trusted technologies at your fingertips to develop secure, customer-focused applications at the speed of business. The 

 Tracker 2.1 offers turnkey, seamless, and secure integration with your preferred bug tracking toolset, boosting the strength and scope of your vulnerability management strategy.

With the latest release – and still more features in the pipeline – your business is uniquely positioned to connect with deployed bug trackers more easily and communicate vulnerabilities, remediate issues, and ensure swift bug resolution and closure.

’s plug-and-play bug tracking integration solution can help drive smarter DevSecOps communication and collaboration

Please visit our Changelog for all feature updates

Interested in knowing more about our vulnerability management integration solutions?

 offers companies an innovative approach to cybersecurity with 

 (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 (invitation based only) programs and public programs for hundreds of organizations worldwide in compliance with the strictest European regulations.

 platform, YesWeHack also offers: support in creating a 

YesWeHack Tracker 2.1 – it’s all about communication and collaboration

From many years, GraphQL has been presented as a good alternative for REST APIs. We will not debate if this is true or not, what are con or pro, but we will see how we can proceed when we found a GraphQL endpoint in our target. How GraphQL works? How to perform Introspection? How to use Mutations? Exploitation of GraphQL endpoint can have a big impact and can bring high rewards, let’s take a look!

Just for a history part, GraphQL is a query language developed by Facebook and used internally since 2012, it has been open-source licensed since 2015. For technical reasons, more and more company use GraphQL and switch their backend to this new system, but, while this query language can have many advantages, it also has a number of security issues as the queries become more complex. Information Disclosure (PII leak), Business Logic Errors, IDORs and Improper Access Control are the most vulnerabilities which can be found on GraphQL endpoint.

This article aims to list some possible attacks on GraphQL and is not a development tutorial, if you want to learn more, I invite you to read 

It’s difficult to list all possible endpoints to find a GraphQL instance but many of them use a framework like “Appollo” and they use common GraphQL endpoints:

. Another way to identify an hidden endpoint by searching some keywords in JavaScripts files like “

” and it could be reveal the presence of GraphQL decommissioned/unofficial endpoint.

Now, you have identified a GraphQL endpoint, the first attempt that you can do and which could be helpful is: 

Introspection is the ability to query which resources are available in the current API schema. Given the API, via introspection, we can see the queries, types, fields, and directives it supports.

So, if introspection is authorized on your target it’s a good news, you will have the possibility to see all useful information to inspect and go deeper on it.

How to perform introspection in GraphQL ?

This is the full request to perform you GraphQL introspection on your target (if enabled):

The server should response with the full schema (query, mutation, objects, fields…). Even if schema is displayed in JSON, it can be quickly unreadable. In my opinion, once you have the schema, the best way is to import it in a tool like “

I talk about below in “Tools” chapter

If introspection is disabled on your target (

), this is a good opportunity to start finding out what they don’t want us to see. By default, GraphQL backend have a feature for fields and operations suggestions. If you try to query a field but you have made a typo, GraphQL will attempt to suggest fields that are similar to the initial attempt.

Field suggestions is not a vulnerability, but from hacker’s side, this feature can be abused to gain more insight into GraphQL’s schema, especially when Introspection is not allowed.

To perform this suggestion abuse, I highly recommend to use tools. You could use Intruder tool in Burp Suite but not always appropriate for this step.

https://github.com/nikitastupin/clairvoyance

https://github.com/swisskyrepo/GraphQLmap

The principal problem in GraphQL is: by design, you don’t have any control access system, developer has to write “resolvers” which will map the data to the queries for the database of his choice.

This is why the most commons issues which happens in Query are authorization logic flaw like Improper Access Control and IDOR.

For example, you have a initial legit Query called “

“. This request should only return information from current connected user.

 by another one, and check if you can fetch information from another users. Classic IDOR, but common in GraphQL.

Query are also interesting, as it is sometimes possible to use a legitimate query and add fields to get juicy stuff. For example, you have a Query “listPosts” which is used by a newsletter web application.

) or fuzzing, you could also discover a “user” object in this Query. Which could be used to fetch additional information:

Mutations are used when web application perform modification actions on data. And like Query, mutations suffers of same problems and can also have others flaws, like 

Let’s assume you have a mutation called “

” which is used by your target to create a simple user account. This mutation have these fields: 

In addition, we can also observe that a field “role” is on returned values by GraphQL in “user” object once the mutation is sent.

In this case, it’s a good opportunity to see what happen if we add a field “role” in our mutation!

As mentioned earlier, the most difficult part of GraphQL for developers is having a granular access control for each request and implementing a resolver for that will integrate with the appropriate access controls.

SQL injection, debug information, batching attack (brute force and rate-limit bypass)

: simple but classic, try SQL and NoSQL injection in fields values,

: Insert bad characters in object or fields name, sometimes DEBUG mode is activated and even if you have a 403 status, you could have a good surprise,

Batching is the process of taking a group of requests, combining them into one, and making a single request with the same data that all of the other queries would have made (

. When authentication process is used with GraphQL, 

 can be performed to simultaneously sending many queries with different credentials, it’s like a bruteforce attack but only with one request. Also, batch attack can be used against 2FA authentication, to bypass rate-limit (if it’s based on number of query by IP for example).

If you want to know more about Batching Attack, I invite you to read 

More and more tools dedicated to GraphQL attacks are developed, but I would like to recommend two of them in addition to those I’ve indicated in the previous chapters.

Event if you’re a master of JSON, I think we will be OK to said when you have a GraphQL schema in front of your eyes, to have a clear idea about each object, each mutation and each query, it’s not the simplest.

I think this screenshot is enough to understand the point.

InQL is originally a command line tool to facilitate certain attacks against a GraphQL endpoint. Luckily, a Burp Suite extension has also been developed and I recommend you to install it (available in BurpApp Store).

It allows you to directly perform an introspection query (if authorized, of course) and to have all the queries and mutations in Burp, in a readable format.

If you need to practice with GraphQL before you start digging into your target, I highly recommend using these docker projects “

” which are two great projects available on GitHub. They will allow you to use many different attacks and approaches with GraphQL that I mentioned in this article.

https://github.com/dolevf/Damn-Vulnerable-GraphQL-Application

https://raz0r.name/articles/looting-graphql-endpoints-for-fun-and-profit

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/GraphQL%20Injection

https://labs.detectify.com/2018/03/14/graphql-abuse

https://lab.wallarm.com/graphql-batching-attack

How to exploit GraphQL endpoint: introspection, query, mutations & tools

Tesla upending more than a century of automotive tradition. Uber redefining the taxi market. Airbnb reinventing the way we book vacations. Each one disrupting the market it operates in – not in decades, but in years. The lesson to learn? For a business to survive, it needs to be infinitely agile and adapt at pace to market change.

However, there’s a balance to be struck between speed and security. To deliver those trusted applications more quickly, organisations need to bake robust application and infrastructure security at the start, closing the vulnerabilities criminal hackers will target across the expanding attack surface.

Until now, most organisations have relied on penetration testing or ‘pen-tests’, to search for vulnerabilities in applications. However, the approach is proving itself increasingly obsolete in today’s dynamic, digital world.

First, pen-tests are limited with regards to the skills mobilized. The consultants involved typically lack the relevant skills and struggle to master the technical environments associated with the tests and the potential attack techniques. Second, most pen-tests are invariably one-off, time-boxed processes, performed one or two weeks per year – not practical when serious or critical vulnerabilities often take several weeks to be discovered. Finally, annual (or even biannual) audits do not meet the growing need for speed and continuity that is typical of agile approaches.

A European financial institution, for example, recently reported, “We can’t be agile when we’re doing pen tests; it doesn’t work. There are too many projects to follow, and we can’t do one before each roll-out owing to the lack of time, responsiveness, and means. The deadlines are too tight and the tests have to be scheduled several times a year.”

A transformative cybersecurity approach is disrupting pen-testing, just as Tesla, Uber, and others have disrupted their respective markets. It’s called 

A Bug Bounty platform provides augmented crowdsourced pen testing as a service. It is an agreement whereby organisations reward ethical hackers – or ‘researchers’ – for reporting bugs, especially those pertaining to security exploits and vulnerabilities. The more severe the reported bug, the higher the reward.

The market is marching towards Bug Bounty platforms too: 

 predicts that by 2022 -that’s next year-, 50% of organisations will be using this modern approach to cybersecurity.

So how does a Bug Bounty platform provide the operational agility to cope with today’s ultra-fast pace of change?

A Bug Bounty platform delivers flexibility, streamlining trusted cybersecurity processes, so organisations can release applications into production more quickly. Take the example of a company using DevOps. They need continuous testing alongside continuous integration/delivery since they’re delivering code every day. A Bug Bounty program provides that continuous testing: surfacing bugs at the same speed as they are inadvertently created by the development teams.

Likewise, organisations using the more traditional waterfall methodology are under pressure to release code in weeks not months as before. Scheduling old-school pen-tests so frequently is not an option. Now, they can use a Bug Bounty platform to mobilize a hand-picked team of ethical hackers to surface bugs during the pre-production acceptance or testing phase.

A Bug Bounty platform increases agility by empowering security and development collaboration. It’s a given that organisations are growing their development community to meet the demand for faster application delivery. In turn, developers are being given more autonomy and typically outnumber security professionals by a significant margin. Unless the security team can find a way to embed security early in that development process, they end up losing control of the security process, with all the inherent risk of vulnerabilities.

Here, a Bug Bounty platform embeds security processes directly into development, increasing collaboration. For example, developers can communicate directly with the researchers who find the bugs – increasing awareness of security and enabling skills transfer between the hunters and the developers. Organisations can ultimately create security champions among the development teams.

A Bug Bounty platform automates multiple vulnerability management processes, increasing speed and agility. With pen testing, for example, organisations only receive a static pdf report. With a Bug Bounty platform, security and development teams can easily 

 all the data into their chosen bug tracker to manage vulnerabilities at scale and speed. There’s no manual ‘copy and pasting’ of content – teams are connected to a single, complete view of the workflow and data.

 is a leading global Bug Bounty & VDP Platform. More than 400 programs – private and public – are in operation, spanning 30+ countries. 

 is also number one among the research community: tens of thousands ethical hackers rely on the platform, in more than 170 countries.

To learn how YesWeHack’s Bug Bounty Platform can help your organization deliver agile digital transformation and pivot to growth, book a free consultation with one of our experts.

Achieve Agile Transformation with a Bug Bounty Platform

 was on finding a valid WAF bypass to exploit an XSS on prototype pollution vulnerability.

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

You had an input field that you could inject, but many characters were sanitized and the WAF could detect them. The goal was to get around that WAF and find a way to exploit an XSS.

‘sreport was detailed, informative, and good at explaining the WAF exploitation logic.
The others reports, notably 

‘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.
Thank you all for playing with us!

Website allow user to control a JavaScript variable named “config” which can be used to perform reflected XSS.
It is noted that a “WAF” is in place to avoid XSS but can be bypassed.

Website allow user input with almost no restriction to take place in a JavaScript variable.

User input is expected to be valid JSON which restricts a bit the allowed charset and forbid usage of JavaScript features such as functions.

The “WAF” in place forbid characters such as ["<", ">", "'", '"', "?"], which would be enough to restrict XSS if previous checks were not hijackable.

The main issue lie in the function isObject() which is bypassable because user can modify the JavaScript object prototype and masquerade as another type by declaring a property
__proto__ such as config = {"__proto__": {}}

Once type check bypassed, the control loop over forbidden characters was not working anymore because of missing includes function on object. This could be fixed by using Array prototype on config object such as
config = {"__proto__": []}, which has an includes function (See [1]) and is then inherited by config object allowing to bypass the loop.

Now that the config object can pass through the “WAF” without issues, we can add a payload with JavaScript code execution inside name property such as
{"name": "<script>alert(1)</script>".

Input following payload in $config field:
{"__proto__":[], "name": "<script>alert(1)</script>"}

JavaScript has a lot of quirks and will have many more, it is generally unsafe to consider that you can “control” an almost fully controlled user input variable. Though, to fix the isObject function it might be better to rely on instanceof JavaScript keyword.

In all case, use a sanitization library such as DOMPurify before returning/interpreting user controlled input. See [3].

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes

[2] https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Operators/instanceof

DOJO CHALLENGE #7 Winners!

 with a new article about an extension known by many hunters but still (too) rarely used, AutoRepeater. If you use Burp Suite for your hunting session, you probably already know the “

” feature. This one is useful, but with the AutoRepeater add-on, you can extend the possibility of automation to focus more on research and exploits.

” functionality in Burp Suite works fine and can do the job in many cases. But when you need to go deeper in your testing phase, you are limited to some basic features. We will try to see how we can improve this!

The plugin is available on BApp Store but we recommend downloading and installing it directly from the GitHub repository which have a more recent version: 

Once you have downloaded the package, unzip it. Now, open Burp Suite: 

. After the installation, you should see a new tab, we can now start to use the plugin!

The interface is pretty clear and we rapidly understand how this plugin works:

: request header, body, param name, but also, cookie name, cookie value, string, first line, remove parameter by name, by value, matching param name and replace value…

: boolean operators, multiple match type (domain name, HTTP method, protocol, file extension, URL, sent from tool… and many more)

: add a filter to show only interesting requests with a specific behavior in your testing process (filter can be applied on URL, request header, request body, file extension…)

: adding colors on specific requests which match with a string, request, param, extension, HTTP method…

Request & Response viewer with original and modified request

Diff between (for requests and responses)

Let’s imagine we have a target with a UUID or an userId: as a hunter with eagle eye, you will probably want to test if two accounts can use or access the IDs from another account, and vice versa. Depending on your target, these IDs can appear multiple time in your requests, so when you want to test IDOR and 

 bugs, you will perform multiple tests by replacing all IDs or just the first one.

How to do thin on AutoRepeater? Add a new 

and select the type of string that you want to replace in “Match”. Choose the value that you want to replace. Select “

” to choose the replacement mode. And that’s all.

Be as creative as possible, here are examples of which rules can be created:

Add new headers (x-forwarded-for, x-forwarded-host, origin…),

Remove authentication header or cookie (JWT for example),

Change HTTP Method (PUT to POST or vice versa),

Math parameters for Open Redirect, reflected XSS or SSRF

Try to bypass “403 Forbidden” by adding specific headers or things like “.;/” in URL

Chain AutoRepeater with Hackvertor extension

: for each replacement configured in AutoRepeater, a new request will be generated, this can therefore quickly become unreadable. Luckily, there is a feature to highlight requests, and this is what we will see right now.

AutoRepeater has a “Log Highlighter” feature which can be used with conditional match, to highlight only what you exactly want. For example, only match “200 OK” status or if HTTP method is “PUT” or “POST”. To configure this, go on 

. You will be able to configure a new rule with specific match conditions.

The “Log Filter” feature can be used to have a clearer view on your requests. As others features, you can add a new rule but with a “Blacklist” or “Whitelist” mode.

Now all you have to do is go ahead and test your rules on your favorite target. I hope you liked this article and realized the potential of this plugin! Enjoy!

https://twitter.com/ngkogkos/status/1350498063555719175

PimpMyBurp #3 – AutoRepeater: add automation to your beautiful hunter life

 vulnerabilities. In the follow-up of this article, today we’d like to introduce you to the 

 plugin. This plugin enables the creation of multiple sessions simultaneously to help you test horizontal and vertical privilege escalation.

The Burp extension helps you to find authorization bugs. Just navigate through the web application with a high privileged user and let the Auth Analyzer repeat your requests for any defined non-privileged user. With the possibility to define Parameters the Auth Analyzer is able to extract and replace parameter values automatically. With this for instance, CSRF tokens or even whole session characteristics can be auto extracted from responses and replaced in further requests. Each response will be analyzed and tagged on its bypass status.

The plugin interface is really crowded and you can quickly get lost in the different options. Let’s get to the point:

Sessions panel: this section is dedicated to your different users’ sessions and which header you want to replace.

” button can be used to automatically replace the parameters value which can be in your path requests, URLs, headers, cookies…

” to see which requests have been tested and which one could be bypassed.
When you select a particular request you can examine the request and the response on the lower right quadrant.

 extension. After a successful installation, you should see it appear in a new tab.

 as needed in Auth Analyzer by clicking on the button 

 then copy/paste cookies and headers for auth. Alternatively, for each session, you can also go on your 

The YesWeHack Blog

Parrot launches its Bug Bounty in partnership with YesWeHack

DOJO CHALLENGE #8 Winners!

YesWeHack Tracker 2.1 – it’s all about communication and collaboration

Parrot launches its Bug Bounty in partnership with YesWeHack

How to exploit GraphQL endpoint: introspection, query, mutations & tools

Achieve Agile Transformation with a Bug Bounty Platform

DOJO CHALLENGE #7 Winners!

How to exploit GraphQL endpoint: introspection, query, mutations & tools

PimpMyBurp #3 – AutoRepeater: add automation to your beautiful hunter life

PimpMyBurp #2 – Auth Analyzer : How to test horizontal and vertical privileges escalation

Sound policy for a vulnerable-by-default cyberspace

PimpMyBurp #3 – AutoRepeater: add automation to your beautiful hunter life

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us