With more web applications exposing RESTful (or REST) APIs for ease of use, flexibility and scalability, it has become more important for web application security teams to test and secure those APIs. But APIs (including REST APIs) introduce some behaviors that make it difficult for web application scanners to test them for vulnerabilities.
New features in Qualys Web Application Scanning (WAS) overcome these difficulties.
Web application scanners often struggle to scan applications that incorporate parameters into their URL paths, specifically web apps that use URL-rewrite techniques or web apps with REST APIs that take URL parameters. One key approach is to fuzz the application’s URL parameter inputs in order to identify possible injection points for malicious code. But without knowledge of the URL structure, it’s difficult for scanners to fuzz those parameters efficiently and with full coverage, which is required for an effective scan.
On March 8, 2017, Qualys published a detailed blog to describe a critical vulnerability in Apache Struts2 Jakarta multipart parser that exposes vulnerable applications to Remote Command Execution attacks. Exploits of this vulnerability can allow attackers to steal critical data or take control of your application servers.
Qualys Web Application Firewall (WAF) 2.0 allows you to create custom security rules to detect and block attacks that try to exploit this vulnerability.
Recently Qualys extended the cross-site scripting (XSS) detection capabilities of Qualys Web Application Scanning (WAS) by adding a new mechanism for detecting DOM based XSS (DOM XSS) vulnerabilities. The new mechanism works in an automated manner with no special setup or knowledge requirements, enabling security teams to greatly reduce the risk from these typically hard-to-detect vulnerabilities. Because of the technique Qualys WAS uses, it also indicates the location in your code of any XSS bugs found, which is pretty convenient for your development teams.
The completely redesigned Qualys Web Application Firewall (WAF) 2.0 provides greater confidence in application security through increased customization, one-click virtual patching ability, simplified controls and stronger security rules. Available now with these and other improvements, WAF 2.0 helps customers fend off hackers’ increasingly common, aggressive and destructive web app attacks.
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.
With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.