 (IDOR) are still in the Top 10 OWASP in 2021 and there’s a good reason for that: IDOR vulnerabilities are common in web applications, especially in APIs. How do we find these vulnerabilities? How can you optimize your IDOR discovery time? How can you go further? Let’s see together!

First step, let me introduce you to PwnFox

 have been developed by our tech ambassador @Bitk.

 to hold multiple unique sessions in the same browser window.
(

TL;DR: no more need to have 3 Firefox instances opened in private browsing mode

For an optimal use of PwnFox, you’ll need two things:

 to proxy your web browser with Burp Suite and dispose of up to 8 different containers

 : to add beautifully highlight your requests in burp, and allow you to easily match them with your different containers sessions by colors (in HTTP History for example)

On the Firefox side, once the plugin is installed, you can open a new tab and each tab will be colored to easily recognize your different hunting perimeter segments.

On Burp Suite, once the extension is installed (

), you will automatically be able to match your different requests on the “

” tab. Each requests are grouped and highlighted using the same color as your corresponding containers tabs on Firefox.

From that point, you may already see this plugin’s goal and how it can be used to find 

On your target, open two and more PwnFox tabs with different users and roles in each containers. For example, one with “admin” role and two with a “member” role. Now carefully explore your target web app, try to enumerate the APIs endpoints you can discover for each role, and every method available: PATCH, GET, POST, PUT, DELETE…
Every requests you will make will be highlighted and colored in your [

, you can select a line (ex: green for the “admin” role) and send it to Burp’s 

. Then select another line, ( ex: red for “member” role) and send it also to the 

‘s authentication cookies and see what happens! Maybe luck will be with you!

Next  step, install and discover Autorize

is an automatic authorization enforcement detection extension for Burp Suite. It was written in Python by 

, an application security expert. Autorize was designed to help security testers to perform automatic authorization testing.

To install Autorize, open Burp Suite and go on the tab 

Once the plugin is installed, you should see a new tab in Burp Suite, called “Autorize”.

Left part: All requests which have been tested by Autorize will be displayed in this part;

Right part: The global configuration of the plugin (headers for cookie, filters, table, enforcement…) and also the request & response viewer;

 or URLs that are not inside your scope, we recommend to start by adding a new Interception Filters. Go on 

Interception Filters > Select “Scope items only: (Content is not required)

Once this is done, open your web browser and create two accounts on your target scope (

 session (this may also be a header string like JWT token) and paste the value to the configuration inside the Autorize tab.

You’re now ready to test for IDORs from your 

 to start. Autorize can do many things for you, but you also need to work for him 🙂

 account session, try as many things you can on your target: add new data, tamper with your data, delete them, test all the features, the goal here is to accumulate the maximum number of queries inside the Autorize tab.

What’s going on? It’s like a Christmas tree

To clearly identify potentials IDORs, Autorize use colors highlighting in 

Be careful, Autorize displaying many red highlight requests does not mean that all endpoints are systematically vulnerable. There may be false positives, it’s up to you to double-check the output.

Now compare the responses size between each query: if it’s the same, go deeper!:

: is also the same request as our victim account but without cookies session (to test if the endpoint is vulnerable to 

Click on the interesting request and check the 

 correspond to the server response to our 

 cookies. As we can see, many information are displayed and a vulnerability of the IDOR type seems to exist.

 correspond to the server response to our original 

 request. It’s useful to compare the response between our two accounts and to detect false positive.

 is the server response to the request but without any auth cookie.

By using these two plugins, you should have a better chance of finding 

 vulnerabilities. Moreover, it allows you to automate some queries and focus on the interesting ones.

We hope you liked this article, feel free to share with us your best Burp plugins and see you soon for the 

PimpMyBurp #1 – PwnFox + Autorize: The perfect combo to find IDOR

A year for resilience, 2020 has also been a year for the community. As an organisation, 

 has demonstrated once again its remarkable agility. As a community, YesWeHack continued to grow bigger and stronger.

Despite the challenges, we are proud to have seized many opportunities. 2020 ended with 20,000 ethical hackers hailing from all over the world. And 2021 starts with ever more organisations trusting our community. Startups, SMEs, multinationals across all industries trust YesWeHack to help their business grow safely. Crowdsourced security has so become the new cybersecurity standard.

The technology we build enables the community to instil the atmosphere of trust our customers seek. That ability to adapt quickly brings unrivalled value to all parties involved; Bug Bounty has entered the agile software development lifecycle. Vulnerabilities surface and are fixed faster; deliveries are more fluid. As organisations embrace digital transformation, crowdsourced security is the most capable of ensuring such hybrid environments’ security.

. Through the conversations we have with both ethical hackers and customers, we also learn how trust meets excellence. Programs get the high-quality management they deserve, transforming security into a real business enabler. As organisations and ethical hackers cosy up collaborating, a significant number of bugs are surfaced as valid vulnerabilities. With a lively 2021 ahead, digital resilience is here to stay.

Building an ever more robust community and technology to support our customers’ growth remains our priority. We embrace technological evolution with all its wits—evermore interconnected systems and an increasingly digitally-enhanced supply chain challenge every organisation. No matter the industry, the attack surface grows knotty.

For the most part, the top vulnerability types had stayed consistent over the years. Yet, 2020 has brought a sweeping digital transformation. With it, a steadily growing trend towards vulnerabilities originating from implementation or design flaws. That trend will only intensify as development frameworks are continuously hardened.

With the YesWeHack community’s support, the addition of innovative yet inescapably complex tools does not become an uphill security battle. Yes, Internet-exposed services will always be there. Yes, cyber-attacks are becoming more pervasive amid a growing attack surface. Our technology gives our customers the power to drive the business pace and harmony in today’s DevSecOps environments. Whatever the technical challenge, ethical hackers will hold off the threats.

Reflecting on what is to come in 2021 also lands us on our values. Technology pervades every part of our lives. Security does not exist in a vacuum. As we tango with new and subtle threats, maintaining trust and transparency in the technology is paramount. A resilient and robust community that walks the talk guarantees that democratic values prevail.

Vulnerability non-proliferation remains at the centre of the values that make YesWeHack what it is today: a team and a community committed to safer cyberspace for all. In 2021, it is ever more important to collaborate with ethical hackers and policy-makers to continue promoting socially-conscious security practices.

Ethical hackers play a central role in the future we build. Governments need to rely on them more, to ensure the security and integrity of public services and fundamental democratic processes alike. To match the massive use of connected devices, the massive adoption of vulnerability disclosure policies must follow.

2020 has been a year for the books. In 2021, we will continue building–robust community, robust technology and robust policies.

Resilience through community: Looking forward to 2021

Why did you launch a Bug Bounty program? 

As Europe’s leading publisher of cybersecurity solutions, we need to have peerless security ourselves. The strong cybersecurity practices we endorse to our customers must be reflected in our own operations. In the past, we relied on traditional methodologies, such as security audits, penetration testing and scans. However, these solutions were not only expensive, they were also only carried out periodically. About two years ago, we took the decision to move to continuous monitoring, both to improve the security of our applications and reassure our customers. 

was the natural choice to underpin this modern cybersecurity strategy.

During client engagements, we are often asked searching questions about our security guarantees. After all, we host sensitive information and our customers want to be certain that their data will not be compromised. We present all of our security processes and methodologies to clients, including non-regression testing, DevOps and others. The problem is that these practises are no longer sufficient to reassure customers. However, the conversation changes completely when we talk to clients about our Bug Bounty program. They are immediately reassured by the fact experts are continuously testing our applications. 

Bug Bounty is a real differentiating asset, and it’s a sales argument we promote every time.

What makes Bug Bounty so special? What does it offer over traditional approaches to cybersecurity?

 is the continuous applications security.

 Previously, we worked with an audit firm on a quarterly basis, and now we have ‘hunters’ tracking down potential vulnerabilities throughout the year.

There is also the follow-up aspect. If we perform a penetration testing,

 for example, and want the auditor to check the correction once a bug has been fixed, we have to undertake a new audit. With Bug Bounty, it’s much more flexible. When a hunter raises a vulnerability, we can exchange directly with that person, correct it and ask them to check it. We then pay the hunter once the correction has been confirmed. With a traditional auditor, there is no verification: it’s up to the developer to make sure that he or she has implemented the patch properly. Every time you deal with an auditor it can also feel like part of a contractual exchange.

Then, of course, there is the return on investment

. When you perform a penetration testing, you have to pay even if no vulnerability is identified. With Bug Bounty, when a product is added to the program, dozens of hunters – potentially many more in a public program – perform the test. If no vulnerability is found, there’s nothing to pay. It’s very rare to find a solution offering near-optimal security for such a low cost.This really resonates with senior management too. They can see directly that a Bug Bounty program costs much less than a penetration testing or an audit.

Bug Bounty also offers significant value in terms of efficiency and diversity of skills. 

When you carry out penetration testing for the first time, you typically don’t have trusted partners you can turn to, so you choose an auditing or consulting firm at random. It’s a bit like a lottery: the tests might be carried out by people who are familiar with the theory, but less familiar with the practice. They’ll run scans to see the installed versions, which will bring up all the vulnerabilities associated with these versions, but there will be no proof of exploitability. For example, these consultants may comment, “You have PHP 7.0 installed. We know there are all these vulnerabilities online, we’ll put them in the report and let you deal with it”.

From our experience with audit firms, we just end up with a report with no evidence of exploitable vulnerabilities. All too often, an auditor may fall short of expectations, but the final bill is the same.With Bug Bounty it’s different. If we come across hunters with a little less experience, it’s not a big deal, because there are more than a 

working on the project who will surface potential vulnerabilities. In addition, the reports written by the Bug Bounty researchers detail precisely the vulnerabilities found – and sometimes even how to fix them. 

That’s a key point compared to traditional approaches: Bug Bounty offers a very wide range of skills to ensure that applications are as secure as possible.

Has penetration testing been scaled back since introducing Bug Bounty?

Yes, we’re only doing one or two a year now. 

Honestly, penetration testing doesn’t interest us much anymore since we launched our Bug Bounty program.

One of the other attractions of Bug Bounty is the fact we can increase the price of the bounties over time if we choose, either to attract more hunters or draw in more qualified hunters. We can also vary different types of campaigns by introducing new scopes. Currently, for instance, we are in ‘grey box mode’, an authenticated mode. Last month however, we opened the ‘black box’ mode with more attractive pricing for hunters.

From time to time, we also do special campaigns. Not too often though, because it requires resources to follow-up with the reports.

How has bug bounty influenced your development team? Are they more aware of hacking, for example? Has it broadened their skill set?

Bug Bounty has really raised awareness among our developers

. The concept of ‘hacking’ is now a fun part of their role. It’s a bit ‘dark’ and certainly interesting for our technical teams. Developers learn how to be the ‘bad guys’, for example, and how to retrieve information they shouldn’t have access to. This aspect is really interesting for the development teams, raising their awareness of security and their engagement with it.

Most developers have already heard about various security breaches – XSS vulnerabilities, SQL injections – but don’t have the opportunity to practice. When they have to fix a vulnerability and have access to a well detailed POC done by a researcher, they have a real use case in front of them, and that makes all the difference.

all the teams that have been able to correct vulnerabilities have improved their skills and integrated good development practices.

How does Bug Bounty fit into your agile strategy?

. Before, we used to receive a PDF report with a list of vulnerabilities to fix. Now, we receive reports progressively, which makes the workload much easier for our teams to absorb.

In conclusion, what advice would you offer to your peers?

I would advise any organisation to implement a Bug Bounty program. For me, it is a mandatory step to achieving continuous, cost-effective application security. In my opinion, Bug Bounty should be implemented in every company that develops software. It’s a necessary step if you want to deliver both a secure and scalable software solution.

Interested in a demo or want to know how to implement a Bug Bounty program in your organisation?Get in touch with our team


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 (invitation based only) programs 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, 

How cybersecurity players gain customer trust with Bug Bounty

 was on finding a valid SQL injection to bypass inputs filter protection

that forbids the use of common SQL comments.

We are glad to announce the #6 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.

You had two input fields you can inject, but can’t use any comments to escape the query. Also, your inputs are stored in a separate table from where the displayed output is fetched.

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 particularly efficient in detailing the exploitation logic, we thus decided to reproduce it in here.
We only publish the best report, however we received an outstanding variety of payload, each one of it’s own genius and encodings tricks.
That was much fun to read.
Thank you!

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.


We have some SQL code that is taking user inputs. Theses inputs are not properly escaped. Indeed, the characters “‘” is not escaped, which enable an attacker to break the SQL Code.
Usually, an attacker use multiple statements or comments to easily customize the query without worrying about the application too much. But here some characters generally used in this purpose are blacklisted like /* — ; #

The challenge is to extract the admin password from the database. One solution would be to use a Union Select query. This query will query the users database (known from previous challenges) and extract the password. A code similar code would do it:

But here, our code is inserted into two statements. The “Insert” statement need a result with two columns and the “Select” statement needs only one column. Yes, we have spotted the major difficulty of this challenge.
The question is, how to inject a Union Select that could returned one column in one case and two in the other case from the same source code?
There is no easy answer (at least that i know).

Then by analysing the code, we can see that we have two inputs. Moreover, they are used in a different order…
By playing a little with these inputs, we can get an interesing result. Some text could be interpreted as a string in one statement and as SQL in the other statement… Great, we are close to a solution!

Then we need to be able to generate a valid SQL query. We need to customize it a little to get a working SQL query.
We have 3 requirements:

do not modify too much the last statement, but we want to test that we can execute SQL in it

In order to concat injected string, we can use “||”.

We will also use the function char() to test that we can properly execute SQL.

Now, we can customize the request with a Union Select request:

user the SQL operator IN to finish the request with ‘); properly

to avoid restriction from this operator add a 1=1 Or condition

Then remember the initial goal of the challenge: extract admin password. The request need some tunning:

If you try to do a username=’admin’, it will break the Insert statement. It is better to avoid ‘. We can generate the admin string by concatenating char(xx)

————– END OF smidthjohn886 REPORT ——————

. He also created the DOJO and this challenge.

For this challenge we received a lot of different payloads, here is two other solutions that use function call to get around the lack of comment. These are unintended solution, +1 for the imagination.

DOJO CHALLENGE #6 Winners!

 was about finding a valid XSS payload. The first five challenge solves and the five best write-up reports were rewarded with a nifty goodies pack.

 We had a great variety of working payloads, demonstrating the vibrant creativity of our community. Thank you all for playing with us!

 geared towards learning bug exploitation the fun and visual way.

The DOJO is three things in one: a learning tool, training platform and a playground.

The DOJO is the arena where the third challenge took place (see the 

We are glad to announce the #3 DOJO Challenge winners list. Everyone will receive a goodies pack.

Other contestants will be able to re-enter the race on the next challenge! Subscribe to our 

 feeds for the forthcoming challenge announcements.

 by exploiting two heavily filtered parameters. The execution context was also inside a conditional block that had to be bypassed somehow.

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

We publish here the best write-up report for this session with the permission of its author, 

The used vector also was not the simplest, but nonetheless unique across all the reports.

/—– SENSEI SAPIC’s REPORT ———————————————————–/

Cross-site scripting (XSS) is a vulnerability that allows an attacker to run javascript in a victim browser context. The attacker can thus leverage it to take action on behalf of the victim. Most of the time, an XSS allows to steal a session and to take over an account.

As per the description of the challenge, the goal is to trigger an XSS in the DOJO Playground using two parameters: 

Here is the source code of the challenge:

Let’s have a look at the code… We have two inputs with the following constraints:

The code also has other interesting elements:

Thus, we will not be able to escape the code logic from the 

 is working and make the rest of the code interpreted as template literals.

We will use the template literals placeholder to trigger our XSS. As per the documentation:

 : is the placeholder to be interpreted as javascript

 : is the requested payload to validate the challenge

 : to comment the ” coming present in the code

Thanks for the challenge!! It’s the first challenge I am doing with YesWeHack and it’s a good experience. The DOJO Playground interface makes it fun to play with and it is very good for learning. Thanks, 

/—– END of SAPIC’s REPORT ———————————————————–/

 is the Technical Ambassador at Yes We Hack. He also created the DOJO and this challenge.

Using backticks was not the only possible solution. You could use comments as well with $age = /* and $name starting with */.

Another solution would be to make $age = ", as this would escape the endline character and make a multiline string ending just where our $name start.

DOJO CHALLENGE #3 Winners!

A Vulnerability Disclosure Policy (VDP) helps organisations be more secure. Yet, still too few still understand what a VDP is and why every organisation needs one. Let’s see the value of VDP through the eyes of an ethical hacker. We chat with SaxX, who shares his thoughts and experiences about vulnerability disclosure.

Hello SaxX! Please introduce yourself in a few words. 

. I am a cybersecurity engineer, bug hunter and I am part of the 

I started doing Bug Bounty four years ago now – I was completely unfamiliar with the concept until I met 

”. After quite some discussion, one thing led to another, and they eventually told me, “Hey, why don’t you try Bug Bounty?”.

I quickly got into it and became very active for three years. Since last year, I’ve been taking it easy and getting involved in other projects. However, I plan to gradually get back into it, as I don’t like seeing myself ranked 4th on the platform! 

Today’s topic is Vulnerability Disclosure Policy (VDP) rather than Bug Bounty. Can you tell us in your own words what a VDP is?

First of all, VDP has nothing to do with Bug Bounty. When we talk about responsible disclosure, we actually have to ban the term Bug Bounty

A VDP, to put it very simply, is a communication channel, that an organisation can set up on its website (whether a simple text file or a more detailed web page), through which vulnerability reports would be submitted.

You’ve probably already seen numerous articles in the media explaining the same story over and over again: “Company X has been hacked. However, we’ve learned that 6 months ago, a cybersecurity researcher had tried to contact this company to point out the critical vulnerability exploited today by malicious hackers. Unfortunately, he never managed to get in touch with the right person at the company.”

is a communication channel allowing researchers to submit vulnerabilities they wish to report.

Thank you, that’s very clear. Still, many people confuse Bug Bounty and VDP. Can you explain, in your words, the difference between these two approaches?

The first thing is the monetary aspect. When we talk about Bug Bounty, we automatically draw the parallel with cash. Bug Bounty is all about money, about the bounty.

On the contrary, with VDP, there is no financial reward. When you report a vulnerability as part of a Vulnerability Disclosure Policy, it is your moral and civic consciousness that drives you to do so. Therefore, you don’t expect any rewards, you are only doing this so the company can be aware of the vulnerability, qualify it and correct it as quickly as possible. 

So the major difference between VDP and Bug Bounty is about money!

Another difference is time investment when doing Bug Bounty. You’re invited to a program by a platform and you’re going to spend time on it to find a vulnerability.

VDP is more a matter of coincidence, a “one-shot deal”. You are using a product on the Internet, in your everyday life, and you see something suspicious. Being a cybersecurity researcher, you’re going to want to go further, understand this vulnerability to see what you can do with it. And then, if this vulnerability is valid, and is critical for the company but also for you since you use this product, you will try to get in touch to report it to them.

We made a short video to clearly explain the differences between Bounty Bug and VDP.

So a Vulnerability Disclosure Policy, as you said, is a channel that organisations set up to hear from well-intentioned people. May we then assume that all companies have a VDP in place?

This is quite far from reality, I’m afraid. In an ideal world, yes, every company (from small businesses to multinationals) should have a VDP. But today, in fact, in France and throughout the world, we realise that many, many companies have absolutely no VDP.

Fun fact, I had a look at the top 30 Alexa sites in France before our chat: only three of them have a Vulnerability Disclosure Policy… And out of the 30, there are about eight or nine that have a Bug Bounty program. 

Therefore, if we extend this to a sector of activity, to a city or a country, we realise that much remains to be done.

Why do you think the majority of companies don’t have a VDP? Perhaps they simply don’t know what it is?

The first point, as you mentioned, is that very few companies know exactly what a VDP is. And more surprisingly, only a few researchers know exactly what it is. There is a lot of confusion on the subject.

This confusion is often caused by the publication of Bug Bounty programs next to a VDP by some Bug Bounty platforms. From time to time, we can see on Twitter some “conflicts” between researchers and companies: researchers complain about having received only a t-shirt as a reward for a vulnerability when they were expecting to receive a bounty. There is a huge amalgam.

Not so long ago, for instance, an energy drink company launched a wild card program 

a Bug Bounty platform. It was a huge scope and a big company, so naturally, you’d think there would be some big rewards at stake. And yet, no, it was a “disguised” VDP, without rewards. Quite a few researchers were fooled and were a bit upset then. Understandably, as they invested time in finding vulnerabilities to receive nothing in return…

There is a real lack of communication, visibility and transparency on the subject. We still need to raise awareness over the topic and help all parties, companies and hunters, understand what VDP is all about.

You said earlier that reporting a vulnerability you identified while using a service is a civic duty. Please elaborate on what you do in such a situation.

The first thing is going directly to the website, try to see if there’s a 

 or a page saying, “contact us here”. If there is no information, I go on Twitter and send them a DM (direct message). In half the cases, I get an answer. When I don’t, the third step is to ask fellow ethical hackers to get contacts in the company. And if I still don’t have any result, I post a message on Twitter.

Let me explain through a few stories that have happened over the last few months.

The first one happened at the beginning of the first lockdown (mid-March 2020). I was developing an OSINT tool and I tried to run it on a West African government. Pretty soon, I came across something quite big. After 30 minutes, with a small Python script, I had access to all the information of this service which provided: name, first name, email address, postal address, national identity card number of citizens – to sum up, sensitive data.

I found a generic email address on their official website, so I sent an email. No answer came through. Then, I activated my network, messaging a few groups I belong to. I got a lot of feedback, but I was given contacts of engineers who themselves didn’t know whom to contact internally. There was a real lack of visibility about who were the right people within the organisation.

The last step was posting a message on Twitter. I got a lot of replies, but mostly from people who just wanted to know what it was about. In these cases, I don’t give any information to avoid compromising the affected organisation.

Today, more than 6 months after my first contact attempt, I have had no “serious” contact. The vulnerability is still there. This is a rather crazy and negative experience which shows that even government institutions are far from the mark. Here, it was Africa, that’s another subject, but this example is worth mentioning.

The second experience I want to share is a bit funnier and I was pleasantly surprised. I was invited by a friend to online fundraising to buy a gift for another friend. Before giving my bank account details, I took a look at the application. Soon enough, I realised that with a little vulnerability, I could have access to the contacts of all the people who had participated in this fundraiser.

So, the first thing I did: I went on Twitter and sent a DM to the company. The guys got in touch with me fairly quickly and, above all, put me in contact with the head of the cyber team. I spoke to him on the phone to explain my findings and the next day, they sent me a voucher to thank me, as the vulnerability I had found was quite critical. The company didn’t have a Bug Bounty program or VDP. Yet, their Twitter account was quite effective as they were able to redirect the information to the right person quite quickly.

We have a dedicated White Paper to guide you thanks to best practices and a thorough examination of available tools. 

And the last anecdote is about a city, Rennes. Again, I was testing the new tool I am developing. I was quickly drawn to a subdomain on a high school website. I realised that I could reinstall the website, and by doing so I could put a webshell that gave me a foot in their server. From their server, I would bounce back to the main site, with all that it entails.

I looked for contact details on the high school website but found no mention on how to report a vulnerability. I found a phone number and tried to call, especially as the vulnerability was critical, I got the voicemail and left two messages but didn’t hear back. Then, I sent a message to the generic email address. No answer.

As this is a religious institution and I have acquaintances in this community, I quickly received contact details, including the headmaster’s. Despite our best efforts, we couldn’t get a hold of each other.

The next day, since I had posted a message on Twitter in the meantime, people sent me the number of the school administrator. The guy had already been alerted by others (I must have been the fifth person to call him). I was shocked: the guy didn’t care. I especially think that he didn’t know what we were talking about and, above all, he wasn’t in charge of this website. It was another provider who had to handle it.

End of this unlikely story: a journalist I know wrote a paper about it and was ultimately able to get the information back to the right people. And finally, after this article, the vulnerability was taken into account and corrected…

Absolutely. I have the feeling that, sometimes, organisations deliberately do not have a point of contact for researchers, because they still have that old fear of having to deal with people who might be a threat.

However, nowadays, there are a lot of good-faith researchers who just want to help these organisations protect themselves.

Patience has limits. As a researcher, you spend a couple of hours or even days to find the right contact, who will then have to agree to listen to you and take your remarks into consideration… All this is very frustrating and, at the end of the day, it doesn’t really make you want to help them.

Yes, clearly, this has happened more than once. When I engage in these steps, it’s only when I find something really critical. I’m not going to disturb people for something minor. But yes, I’ve sometimes given up over the years because I’ve never had a response.

The YesWeHack Blog

PimpMyBurp #1 – PwnFox + Autorize: The perfect combo to find IDOR

Resilience through community: Looking forward to 2021

How cybersecurity players gain customer trust with Bug Bounty

PimpMyBurp #1 – PwnFox + Autorize: The perfect combo to find IDOR

DOJO CHALLENGE #6 Winners!

DOJO CHALLENGE #3 Winners!

Vulnerability Disclosure Policy through the eyes of a bug hunter

DOJO CHALLENGE #6 Winners!

DOJO CHALLENGE #2 Winners!

Practical vulnerability disclosure: VDP made easy

YesWeHack joins Tech4Trust, Switzerland’s cybersecurity accelerator

DOJO CHALLENGE #2 Winners!

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous