Qualys offers a wide array of security and compliance solutions for your organization. All capabilities are delivered from Qualys Cloud Platform. Visit Qualys Cloud Platform Apps to learn more.
But let’s narrow the discussion to web application security. To have a complete webappsec program, it’s important that ALL of your web applications have some level of security testing. Automated scans using Qualys Web Application Scanning (WAS) are perfect to meet this need given its cloud-based architecture, accuracy, and ability to scale. However, performing manual penetration testing against your most business-critical applications is highly recommended to supplement automated scanning. Manual analysis complements scanning by identifying security holes such as flaws in business logic or authorization that an automated scanner would be incapable of detecting.
One of the most popular tools for manual testing of web apps is Burp Suite Professional. This month Qualys introduced a Burp extension for Qualys WAS to easily import Burp-discovered issues into Qualys WAS. With this integration, Burp issues and WAS findings can be viewed centrally, and webappsec teams can perform integrated analysis of data from manual penetration testing and automated web application scans. The combined data set may also be programmatically extracted via the Qualys API for external analysis.
In the world of application security, testing REST APIs for security flaws is important because APIs can have many of the same application-layer vulnerabilities as browser-based web applications. Examples are SQL injection, command injection, and remote code execution. With the recent release of Qualys Web Application Scanning (WAS) 6.0, testing your REST APIs is easier than ever thanks to support for Swagger.
Swagger is a widely-adopted specification that allows for programmatically describing REST APIs. This is accomplished via a Swagger file, which may be in either JSON or YAML format. The Swagger file provides all the details about the APIs and how to invoke them. This includes information like the HTTP verbs to use (GET, POST, PUT, etc.), the URL paths, allowable parameters and types, authentication mechanisms, and so on.
A decade ago, cross-site request forgery (CSRF, often pronounced “c-surf”) was considered to be a sleeping giant, preparing to wake and inflict havoc on the Worldwide Web. But the doomsday scenario never materialized and you don’t even seem to hear much about it anymore. In this blog post, part 1 of 2, I will explore this idea and try to understand why the CSRF giant never awoke. First we’ll cover the overall threat landscape, trends, and some notable CSRF exploits throughout the years, including one from personal experience.