Fuzzing is a software security testing technique that automatically provides invalid and random input to an application to expose bugs. The goal of fuzzing is to stress the application to cause unexpected behavior, crashes, or resource leaks. It allows us, as developers, to understand the behavior and vulnerability of applications more comprehensively. We use fuzzing tools, referred to as fuzzers, to perform this kind of testing.
The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up later during runtime. Once this happens, it falls on the shoulders of the Ops team or SREs to engage in firefighting.
Cross-site scripting has been at the top of the OWASP Top 10 for nearly a decade. In this article, we'll explore everything you need to know about XSS, the associated risks, and countermeasures you can take.
In the past, teams incorporated security testing far after the development stage of the Software Development Lifecycle (SDLC). Security testing would influence whether the application would to proceed to production, or get passed back to the developers for remediation. This process caused delays while teams worked on remediation or, worse yet, it increased security risks when teams released software without applying the necessary security measures.
Today I want to show you a way to simplify fuzz testing for your C++ applications. If you read this article to the end, you will learn about an automated testing approach that can protect your applications against all sorts of memory corruptions and other security vulnerabilities.
19.10.2022 - As part of our goal to continuously improve our vulnerability detectors, we continuously test various open-source projects with Jazzer within OSS-Fuzz. In this case, a test run yielded a severe finding with a potential remote code execution in a HSQLDB (CVE-2022-41853).
