Ready to level up your ethical hacking and Bug Bounty skills?

 challenges in Ruby code within a dedicated new sandbox environment! Read on to discover how to leverage the new feature and the bug-hunting benefits of mastering Ruby and its common security pitfalls. Let's dive in!

Step-by-Step: Getting Started with a Ruby CTF

Benefits for Bug Bounty Learners & Challenge Creators

YesWeHack’s Dojo platform is a versatile CTF and learning platform aimed at Bug Bounty hunters and anyone else who wants to sharpen their hacking skills and get involved in the hacking community. It offers 

 with practical labs on common vulnerabilities, as well as monthly 

CTF challenges featuring realistic vulnerabilities

 that boost the bug-hunting skills of both experienced and inexperienced hackers, with swag and leaderboard points awarded to the overall winners.

You can also write your own code in a wide range of programming languages (even wider now!) in order to test attack techniques or create your own CTF challenges (which you can submit to YesWeHack for consideration as a potential monthly CTF challenge).

how to use the recently-revamped Dojo here

At first glance, Ruby might not be the most obvious choice as a language for learning the latest hacking techniques. After all, it’s less prevalent in modern stacks than JavaScript or Python.

But from a hacker’s perspective, Ruby still offers advantages that make it worth knowing about. For instance, Ruby has a mature and battle-tested ecosystem, with a significant number of web applications still relying on it. 

 apps, in particular, have a long history of interesting security issues, from mass assignment and deserialization bugs to SSRF and command injection vulnerabilities. Knowing how Ruby handles data flows, templating and object instantiation gives you an edge when targeting these applications.

You then land on the main challenge page, where you can write your Ruby code, set up filters and test your code!
Start writing your code in the 

 tab at the bottom-centre of the page. Insert user input to your code within the 

 panel on the left-hand side by setting the placeholder 

Now you’re set to start testing out attacks or creating your very own CTF challenges!

Benefits for Bug Bounty learners & challenge creators

If you’re an experienced hacker, then you’ve probably faced web applications running on Ruby – and will surely do so again. Understanding Ruby and the most popular Ruby framework, 

, as well as the pitfalls that lead developers to inadvertently create vulnerabilities in Ruby code, will help you make the most of the hacking opportunities offered by this programming language.

Dojo’s new Ruby integration is a great way for ethical hackers and Bug Bounty hunters to achieve this in a risk-free but realistic way – whether by testing out attack methods, building custom CTF challenges or trying to solve challenges created by others.

Unveiling Dojo v2: Our new CTF and realistic challenge-building framework

New Dojo sandbox environment for creating Ruby CTF challenges

, challenged the participants to exploit a JavaScript prototype pollution to trigger a catch exception handler and execute arbitrary JavaScript code to capture the flag.

Want to create your own monthly Dojo challenge? Send us a message on X!

 feeds to be notified of upcoming challenges.

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

We want to thank everyone who participated and reported to the Dojo challenge. 

There where a ton of great reports this time. 

You find the best write-up overall below:

The application allows a user to build a hacker profile combining the details of a random Profile (if all details of a hacker not provided) and the user input by the hacker. However, the application suffers from the prototype pollution and unsafe code evaluation. The vulnerable code path allows an attacker to modify JavaScript's Object prototype and inject malicious code that is subsequently executed via an 

 function. This occurs due to the improper validation or sanitization of the user-supplied JSON data. This vulnerability enables unauthorized access to sensitive information, including environment variables, and potential complete system compromise.

We are presented an application that allows a user to build a profile using the JSON input. A thorough code analysis was performed during the initial reconnaissance phase which revealed the underlying tech-stack. The application uses JavaScript, Node JS and EJS templating. Various utility functions are implemented to handle the user input and manage application.

The first step in analyzing the user input handling is to examine the entry point where the input is processed. In this case, the user input undergoes a transformation by a Web Application Firewall (WAF), which URL-encodes the input to mitigate any malicious payloads.

 function. This essentially reverses the encoding performed by the WAF, converting URL-encoded characters back to their original form. If the decoded input is empty (i.e., the user does not provide any input), the 

 variable is set to a default value of an empty JSON object (

). This ensures that the application always operates on a valid object. The decoded and validated input is then parsed using 

. This step implies that the input is expected to be a valid JSON string.

In the next step, a random Profile is selected with a 

 function call which selects a random profile from the 

 variable as provided in the set up code. The selected random profile is assigned to 

 method then combines the properties of the 

 input to create the final user object. It iterates over each key in the 

 is used instead. This method enables the user input to override default values, giving the attacker control over the profile's properties.

 method iterates over the keys of the user input and merges them with the target object. This raises concerns about potential prototype pollution, where an attacker could inject properties that affect the object’s prototype, potentially altering application behavior in unexpected ways.

Then comes the main block of the application logic. This code block attempts to convert all user properties to strings before rendering the template. It iterates through each property of the user object, handling dates specially by formatting them without the GMT timezone. If any error occurs during this process, the application enters an error handling path where it checks for debugging configuration. When debug mode is active, the application dangerously evaluates arbitrary code specified in 

, creating a potential execution point for attacker-controlled code. This means if an attacker can cause the 

 block to execute with a crafted payload, he can probably attain Remote code execution. The results are then passed to the template renderer.

After the initial analysis and an initial idea of what block of code could be vulnerable, we now proceed with how the application behaves with different inputs. Starting with the normal input with how the application is supposed to behave, it builds the normal hacker profile. The below is a screenshot with all the key-value provided as input.

 (incomplete details), the details get populated with a random profile from the set up code.

The goal was to identify and extract the 

 stored in an environment variable. Based on the analysis, the critical point was reaching the 

 block of the application, which contained insecure code execution via the 

 function. This was possible due to improper handling of user input and reliance on dynamic evaluation, where the 

 could be manipulated to execute arbitrary code.

To trigger the vulnerable path, we identified that prototype pollution was necessary. By manipulating the user input to include a property like 

, we could force an error in the string conversion process, specifically within this block:

 function, we observed that it recursively merges the user input with the default user object without proper safeguards. This allowed for unsafe property assignments, including critical keys like "constructor" or "proto," which are crucial for prototype pollution. This vulnerability could enable an attacker to inject properties that influenced the eval function and ultimately expose the FLAG. However on further inspection the WAF blacklist contained the keyword 

 meaning it couldn't be used on the payload.

To exploit the vulnerability, a payload was crafted that both causes prototype pollution and triggers an error in the code flow. The crafted payload is as follows:

" portion of the payload manipulates the global Object.prototype to add a debug property with 

 is a plain JavaScript object, it inherits from 

. By polluting the prototype, we can inject a 

 is set to null. This forces an error when the code attempts to call 

 block, and the application checks if debugging is active:

, retrieving the flag from the environment variable.

This executes the code that exposes the environment variable containing the flag and you've pawned it modal.

The proof of concept (PoC) involves injecting a JSON payload that causes prototype pollution and triggers an error in the application. The payload sets the 

 is called in the application code. This error activates the catch block, where the insecure eval() function executes the injected code from 

. The injected code retrieves the flag from the environment variable using 

The above payload resulted in the FLAG to display the log in the application UI as

The vulnerability presents a significant risk as it allows attackers to exploit prototype pollution to manipulate application behavior. By injecting malicious properties into object prototypes, attackers can alter critical application logic and trigger the execution of arbitrary code. The use of the insecure 

 function further amplifies this risk, as it allows an attacker to execute injected code, potentially leading to the exposure of sensitive information, such as environment variables (e.g., the flag in this case). This type of vulnerability can be used for remote code execution and data leakage, posing a severe threat to the application's security.

To remediate this vulnerability, sanitize user inputs to prevent prototype pollution, avoid using 

, and use safe alternatives for dynamic code execution. Implement object property filtering to block dangerous keys, and use trusted libraries for deep object merging. Regular security audits will help identify and address such issues early.

Dojo challenge #40 - Hacker profile winners & writeup

Ever wondered if you’ve overlooked an open port that is hiding a service vulnerable to exploitation?

Port scanning is an invaluable reconnaissance technique for ethical hackers because every undiscovered service is a potential gateway to critical vulnerabilities!

In this article, you will learn passive and active port scanning techniques for revealing open ports and hidden services on a target’s infrastructure.

We’ll explain the advantages of various scanning methods, recommend the most effective port scanning tools, and provide practical examples based on real Bug Bounty targets. Understanding these techniques will empower you to make informed decisions that enhance your recon strategy.

Gathering service information from public databases

Identifying exposed services with banner grabbing

Port scanning is a technique for identifying open ports – virtual endpoints that are configured to accept incoming network traffic – on a target system.

Identifying open ports helps you to determine which services are running and therefore to map the attack surface – a crucial first step before uncovering potential weak points.

Port scanning is typically performed against a specific domain or IP address, or a defined range of IPs. Bug Bounty Programs that permit port scanning should detail clearly what you are allowed to scan. 

It’s essential to verify what is permitted before launching any scans to stay compliant with program rules.

Port scanning is often permitted on self-hosted infrastructure (meaning the company owns the IP ranges), but rarely allowed on third-party services such as cloud-hosted apps, SaaS platforms or where scopes include web applications but not IPs or network infrastructure.

Once you’ve mapped your target’s active services, you can search for vulnerabilities arising from outdated software, misconfigurations, weak authentication mechanisms and so on.

Port scans need not directly interact with the target to produce useful results. Passive port scanning gathers valuable intel on your target without alerting its defensive mechanisms, which eliminates the risk of detection. This is achieved by drawing on public sources that have already scanned the internet.

By querying platforms like Shodan, Censys, or SecurityTrails you can access historical records of open ports and associated services across various domains and IP ranges. You can identify:

Services that were once publicly accessible

Hosts that are inadvertently exposing ports

And forgotten assets that are no longer monitored

This information allows you to understand the historical context of a target’s exposure, often revealing legacy systems that might be otherwise overlooked.

A simple Shodan query can reveal open ports on a target domain:

Quickly highlighting which ports are publicly accessible, this query enables you to focus your efforts on potentially vulnerable entry points.

Recon Series #2: Subdomain enumeration – expand attack surfaces with active, passive techniques

After gathering a high-level view with passive methods, it’s time to delve deeper. Active port scanning interacts directly with the target’s network, revealing live services and open ports that might not appear in public records.

These techniques involve sending crafted packets (such as SYN, ACK or UDP probes) to the target host and analysing their responses. Tools such as Nmap, Masscan or Naabu can scan IPs or domains to uncover:

Services that are live but not publicly indexed

Ports that are selectively open to specific IP ranges

Temporary or forgotten services still running internally

Active scanning is more precise and comprehensive than passive scanning, but introduces risk because it can trigger firewall alerts or intrusion detection systems (IDS).

Effective countermeasures include reducing scan speeds to evade rate-based detection, and employing evasion techniques like fragmentation and decoy scans. 

If you’re probing a Bug Bounty target, you should also ensure that you are explicitly authorised to conduct the scans you intend to run.

 in Nmap) is a popular active port-scanning method in part because of its stealthy nature: it sends a SYN packet and awaits a SYN-ACK response without establishing a full connection.

), which does establish a full connection, is a viable alternative when firewalls block SYN packets. This method provides a more definitive answer on port status when stealth is not your primary concern.

UDP scanning is useful for services running over UDP (such as DNS or SNMP) and for bypassing TCP-based defenses. Since UDP is connectionless, it’s also harder to detect than TCP scans that require handshakes.

However, the absence of a handshake mechanism means UDP scans sometimes generate ambiguous responses from closed ports and might be ignored by open ports. Moreover, many UDP services only respond to probes customised to their target, making them harder to detect with generic scans – so hunters need relevant expertise.

Because UDP traffic is often rate-limited or dropped by firewalls, it’s crucial to apply rate limiting and enable retries to improve reliability and accuracy.

Once open ports are identified, banner grabbing is used to extract details about the services running. This technique provides insight into the software version, configuration and potential vulnerabilities that could be exploited.

Banner grabbing involves connecting to a service and reading the initial data it sends back – often a welcome message or banner. Knowing why this matters allows you to quickly assess if a service is using outdated or misconfigured software.

This command prompts the target to reveal its banner, potentially disclosing critical information such as the software name and version.

Nmap can also perform banner grabbing with its version detection feature using the 

 flag. This not only confirms the service’s identity but also provides additional details like SSL support or custom configurations.

This output shows how Nmap identifies exact versions of services – a crucial prerequisite for pinpointing vulnerabilities in outdated or misconfigured software:

For more detailed detection, you can increase the intensity with:

 flag attempts to identify the operating system based on TCP/IP stack behaviour. Knowing the OS can help tailor further exploitation or remediation strategies.

⚠️ Bug hunters beware: Always ensure you have proper authorisation and that your actions comply with a Bug Bounty Program’s rules.

Port scanning can trigger security defences, so employing stealthy scanning techniques is often necessary to avoid detection.

An IDS (intrusion detection system) monitors network traffic to detect suspicious activity, including port scans. Knowing how an IDS might flag your actions as potentially malicious can usefully inform your recon strategy to mitigate these risks.

: Sends fake scan traffic from spoofed IPs along with your real scan, making it harder for detection systems to pinpoint your activity. For example:

This method obscures the true source of your scan, reducing the chance of being blocked.

: Introduces a delay between probes to prevent triggering threshold-based IDS rules. For example:

A slower pace mimics regular traffic, lowering the risk of detection.

: Splits TCP packets into smaller fragments, which can bypass simple IDS/IPS that do not reassemble packets properly. For example:

Fragmenting packets can confuse basic detection mechanisms, though it may not work against more advanced systems.

While traditional tools like Nmap might prove too slow for large-scale reconnaissance, there’s generally a trade-off between scan speed and thoroughness. Striking the right balance is therefore key to ensuring you do not miss any open ports.

Masscan, the fastest internet port scanner, sends asynchronous TCP packets, which allows you to scan massive IP ranges quickly – a boon for initial recon. Consider the following example:

 sets scan speed to 10,000 packets per second. This high rate facilitates a rapid assessment, though you may need to recalibrate based on bandwidth and target limitations.

Inevitably, this rapid speed means scans are less thorough. Therefore it’s wise to supplement Masscan probes with Nmap scans in order to gain deeper insights.

Recon series #4: Port scanning – uncovering attack vectors by revealing open ports and hidden services

“Security by obscurity” is no longer a viable strategy in a world of internet-facing assets and expanding attack surfaces, attendees at a YesWeHack Bug Bounty Summit in Qatar were told.

Gaurav Kumar Sharma, assistant director for security architecture and planning at Ooredoo Qatar, was reflecting on the thought processes that led to a partnership between Ooredoo and YesWeHack. Serving 121 million customers with a variety of telecommunications services, Ooredoo had complex cyber, compliance and insurance risks to mitigate, he said. “From an insurance perspective this security control is very important for us,” he said of their Bug Bounty Programs.

When it came to hardening its eclectic mix of internet-facing assets, Gaurav continued, Ooredoo sought continuous, scalable testing, leaner vulnerability management processes, and access to a diverse range of offensive security skills.

As a candidate for helping the Qatari multinational achieve these goals, YesWeHack stood out by dint of its platform, operating model and end-to-end service, Gaurav recalled

Oreedoo always goes with best-of-breed solutions. I’m happy we went with YesWeHack,” he told the audience of security professionals gathered in Doha in September.

The YesWeHack partnership began in 2022 with private programs for Ooredoo’s three primary customer-facing assets. The scopes, comprising web, mobile and API assets, were tested in production environments with real world conditions (so web application firewalls and other protections were in place). A 

, which Gaurav said was a governance requirement and something demanded by investors, was also launched – enabling his team to benefit from the expertise of any security researchers worldwide.

The Bug Bounty Program had a fast start, with the first reports arriving within minutes of launch and dozens arriving within the first week. There were high severity and critical vulnerabilities among them. Gaurav detailed one critical bug where the hunter had achieved account takeover by manipulating an API’s reset password request to trigger a forged post request, which forwarded the new password to an email address under his control. This potentially calamitous flaw was found and fixed for the sum of $1,500.

Fortunately, Ooredoo and YesWeHack were well prepared for the fast start. YesWeHack’s triage team swiftly reproduced and assessed the vulnerabilities, Gaurav recalled, while Ooredoo’s existing process for handling vulnerabilities withstood the demands of the new testing medium. “Bug Bounty was just an additional input,” he said. That said, the experience did lead to improvements in their vulnerability management process, while the hunters’ findings generated actionable insights about their security tools.

A KPI review was conducted after the first few weeks, after which the security team opted to persist with black-box testing but increase testing coverage. They also resolved to make the 

 public by the end of the year – a goal they went on to achieve.

At the time of the presentation, around two years after the partnership had begun, 319 Bug Bounty reports had been closed, while the VDP had delivered 40 reports.

Echoing sentiments expressed in many of our 

, Gaurav urged his peers in other organisations to launch their own Bug Bounty Programs on a small scale, but to do so as soon as possible. Since Bug Bounty is inherently agile and adaptable, rules and scopes are readily finetuned post-launch, as programs grow.

However, Gaurav advised against starting a Bug Bounty Program before ensuring security, development and other affected teams understand their roles, perhaps with the help of an RACI (responsibility assignment matrix). Mindful of Ooredoo’s busy start, Gaurav also emphasised the importance of being ready to handle reports and mitigate bugs in a timely fashion from the get-go.

Otherwise, the launch process is reasonably straightforward, he insisted – so long as you have a clear idea of your testing goals and strategy. Your customer success manager (CSM) can support you a great deal in this regard.

Crowdsourcing their access to hacking skills had proven especially invaluable given it had hitherto been difficult to find testers with the right competences for Ooredoo’s multifarious technologies and use cases. “Pentests might involve just 2-3 consultants; here I have access to thousands of hackers who are ready to go,” said Gaurav.

Given their contribution, which also includes advising on and validating fixes, hunters’ happiness should be top priority for program managers, said the security exec: “Make sure your SLAs and KPIs are met. Sometimes hunters get frustrated if they don’t get rewarded on time because they’re working day and night to give something back.”

So far “YesWeHack is living up to our expectations,” enthused Gaurav, “because we’re getting certain things that we would not have [otherwise] managed with the resources we have.”

In particular, he appreciated “the always-on dashboard and real-time understanding of my threat exposure made possible by a continuous testing scenario”.

Year-round testing coverage was a huge boon given the pace of release schedules. “Things are changing very fast,” said Gaurav. “Every month or week there is some change in our services, so one pentest cannot be good enough.”

The speaker said this cost-effective and continuous testing layer freed up internal resources to test more specific scenarios or implement other compliance-oriented initiatives.

Notable time-saving benefits included automated risk-scoring and YesWeHack’s triage service, “so that burden is always offloaded to YesWeHack”. Gaurav said the triagers’ initial severity calculations were valuable, but that he also appreciated the fact that Ooredoo was given the final say on CVSS scores, given their exclusive knowledge about whether vulnerabilities were truly critical within the context of their environment.

The CSM team also brought value in terms of notifying Ooredoo of actionable developments and helping them handpick the right hunters.

In fact, Ooredoo would not have so rapidly launched their public program, which further increased the volume of findings, without this wide-ranking support from YesWeHack, insisted Gaurav.

‘Think about your strategy in a changing world’

Gaurav dismissed concerns about any supposed risks entailed by inviting freelance hackers to probe your digital assets. After all, all organisations have vulnerabilities, he pointed out. Either you recruit ethical hackers to help you identify and eliminate those attack vectors – or you leave malicious hackers to find them instead.

YesWeHack’s managing director, Rodolphe Harand, interjected to add that hunters are vetted and held liable for violations by the platform’s terms and conditions. Customers (or, on their behalf, CSMs) can also handpick hunters according to a variety of parameters, such as relevant skills, performance metrics (points awarded for their findings) or country/region, as well as monitor hunters with user agents or VPNs for extra peace of mind.

As his presentation approached its conclusion, Gaurav implored his fellow InfoSec decision-makers to “think about your strategy in a changing world. The world has moved on,” he said. “Organisations are investing more in resiliency because they know that attacks will happen.”

 for further details on rules, rewards and scopes.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management platform? 

 to schedule a demo with one of our experts.

‘Continuous testing and a real-time understanding of my threat exposure’ – Ooredoo exec on the benefits of Bug Bounty

The UK’s planned overhaul of legislation designed to protect critical national infrastructure (CNI) will apply to a wider range of sectors and introduce tough new incident reporting requirements.

These measures accord with a promise to align the Cyber Security and Resilience Bill, “where appropriate”, with the EU’s NIS 2 regulation, made in a 

 issued by the Department for Science, Innovation & Technology (DSIT) on 1 April.

 (PDF) in July 2024 shortly after the Labour government entered office, will supersede the EU’s Network and Information Systems (NIS) Regulations 2018. Although the 2018 NIS regulation was 

, the first NIS framework has continued to apply in the UK due to the country’s departure from the trading bloc in 2020.

The policy statement for the bill says it will draw on “insights we have gathered from our international partners, including valuable lessons from the European Union on the implementation of its NIS2 regime”.

The bill “will address the specific cyber security challenges faced by the UK while aligning, where appropriate, with the approach taken in the EU NIS 2 directive”. With Prime Minister Keir Starmer having declared growth his defining mission, the policy statement adds that “this strategic approach ensures we can be flexible and responsive to cyber threats in a proportionate way that balances the impact on business”.

Data centres, managed service providers in scope

Incident reporting obligations will, in alignment with NIS 2, require in-scope entities to notify relevant authorities of significant security incidents within 24 hours, and then submit a more detailed report within 72 hours.

Also mirroring NIS 2, the bill will bring managed service providers (MSPs) into scope, with the policy statement noting their “unprecedented access to clients’ IT systems, networks, infrastructure and data”.

 in September 2024, will also be in scope. Those above a certain capacity threshold will have to share information with authorities, and comply with obligations around risk management and “reporting significant incidents”.

Supply chain security will also become a focus of UK cyber law – another similarity to NIS 2 – through the mechanism of secondary legislation that will introduce new duties for operators of essential services (OES’) and relevant digital service providers (RDSPs). These duties will include “appropriate and proportionate measures [...] to prevent vulnerabilities in suppliers from undermining essential or digital services”. 

Regulators will also be empowered to “designate specific high-impact suppliers as ‘designated critical suppliers’ (DCS)”, which will be subject to “core security requirements and incident reporting obligations”.

Recognising the fast-evolving nature of cyber threats, the legislation will grant the DSIT Secretary of State powers to rapidly update regulations without needing fresh primary legislation.

While the policy statement repeatedly hints at less onerous business-friendly regulations, the need to minimise compliance burdens and facilitate cross-border cooperation and information-sharing will surely ensure a high degree of alignment with NIS 2.

NIS 2 has broadened the range of in-scope sectors

, divided them into “essential” and “important” categories, strengthened information-sharing measures, and introduced various measures for facilitating coordinated vulnerability disclosure (CVD).

To find out how YesWeHack can help you comply with UK and European cyber regulations, 

 of our Bug Bounty, vulnerability management and attack surface management platform.

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

Did you know that manipulating a single HTTP header can unlock high-impact security flaws hidden within a web application?

HTTP headers control how browsers and servers interact with data, so these vulnerabilities can affect the entire application stack.

In this comprehensive guide, we share techniques – both simple and advanced – for exploiting vulnerabilities in HTTP headers, ranging from abusing custom headers to leveraging cache poisoning and reverse proxy misconfigurations.

With real-world examples and easy-to-follow tips, this article will help you spot weaknesses faster and boost your Bug Bounty and ethical hacking skills.

Let's dive in and uncover how minor modifications to request headers can reveal major security issues!

CPDoS via Akamai: caching error responses

CPDoS on Cloudflare: infinite redirect loop

Common HTTP headers used by reverse proxies

General HTTP headers used by reverse proxies

Mitigation & best practices for HTTP header exploitation

Analysing HTTP response headers provides valuable information about the web application. Headers can reveal running services, software versions, and programming languages employed by the application. Such details help in tailoring payloads and selecting appropriate attack methods for further testing or direct HTTP header exploitation.

Inspecting custom HTTP headers in both responses and requests is a valuable first step when scanning a target. Customised headers often reveal sensitive information – such as internal system information or framework identifiers – or inadvertently expose pieces of code that can be leveraged for further reconnaissance.

An attacker can harness custom headers as keywords for open source intelligence (

) recon, potentially uncovering source code leaks and other technical information related to the application.

' responses, as they often expose headers that are not typically visible in server responses. These error responses often include default configurations as well as internal debugging information and naming conventions:

 can potentially retrieve fragments of source code that handle custom headers. For instance, source code in Github repos sometimes includes elements that interact with custom headers. So if you identified the header ‘X-Internal-Token: secret-value’, you could use Google to search (ie, dork) "X-Internal-Token" site:github.com”, which might then reveal hardcoded references in backend code, sample configs or .env files, or middleware or route handlers checking for the header.

The YesWeHack Blog

New Dojo sandbox environment for creating Ruby CTF challenges

New Dojo sandbox environment for creating Ruby CTF challenges

Dojo challenge #40 - Hacker profile winners & writeup

Recon series #4: Port scanning – uncovering attack vectors by revealing open ports and hidden services

New Dojo sandbox environment for creating Ruby CTF challenges

‘Continuous testing and a real-time understanding of my threat exposure’ – Ooredoo exec on the benefits of Bug Bounty

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

HTTP header hacks: basic and advanced exploit techniques explored

‘Continuous testing and a real-time understanding of my threat exposure’ – Ooredoo exec on the benefits of Bug Bounty

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

Hacking GraphQL endpoints with introspection, query, mutation, batching attacks

EUCC cyber certification scheme enters early adopter phase after vulnerability disclosure rules issued

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous