Today, Checkmarx SAST provides tremendous flexibility  to scan applications based on how they are built. This is done using two constructs:

• Queries: essentially a rule that identifies a potential vulnerability. 
• Presets: a collection of queries optimized for a specific type of application (for example, a mobile app) that defines the scope of the SAST scan. We’ve written elsewhere about working with presets. 

Queries are building blocks for identifying potential vulnerabilities and critical for filtering through the noise to avoid sending false positives and false negatives to your developers. Understanding queries enables AppSec teams and developers to prioritize your efforts, and promptly address the most critical issues.  

Checkmarx SAST includes pre-built queries (and presets) written in the Checkmarx Query Language (CxQL). These identify common security issues such as SQL injection, cross-site scripting, and insecure access controls and provide an easy way to start securing applications out of the box.  

Customizing queries for your unique applications 

Checkmarx is the only solution in the market that allows for queries to be customized – either by creating new custom queries or customizing existing queries.  

Custom queries provide a uniquely flexible and powerful mechanism to tailor your SAST tool solution to specific application requirements. They provide the freedom to explore unique or specific code structures that pre-built rules may not cover adequately.  

For example, as we wrote in an earlier post: 

A common use case that neatly highlights the benefits of customizing queries can be found in cross-site scripting (XSS) vulnerability findings where a false positive may be occurring due to the use of an in-house sanitizer method that is not included in the Checkmarx One default out-of-the-box query. We can simply add this method to the appropriate CxQL query and rescan the project to remove the FP. 

AI enters the room 

Unless you’ve been living under a rock, you’ve probably heard about AI and the impact that it’s having across every industry. In tech, many developers have embraced AI and are already using AI to generate their code. But even more so, according to a recent IDC survey(1) , developers believe that software quality and testing (22.5%) and security testing and vulnerability management (21.5%) have the most potential to benefit from Generative AI. 

Making custom queries more accessible with AI 

Today, Checkmarx introduced AI Query Builder for SAST. This feature lets Checkmarx One users harness the power of AI to automatically generate new custom queries or modify existing ones. AI Query Builder builds on the custom query capability, allowing AI to help any AppSec team write new or edit existing custom queries. This allows every organization to tune SAST more easily for your applications, increasing accuracy and minimizing false positives and false negatives. 

AI Query Builder is an expert in the ins and outs of CxQL. You no longer need to be an expert in building a query when an AI can do the work for you! With this feature, a simple prompt such as, “Help me generate a Checkmarx query that will detect an authentication issue,” will immediately generate a new custom query.  

Benefits of AI-Generated Custom Queries 

 Some benefits of using artificial intelligence to generate custom queries include: 

• Comprehensive coverage: AI Query Builder can use existing public SAST documentation and security best practices to generate custom queries that cover a broader range of potential vulnerabilities. This reduces the risk of making mistakes or missing critical issues. 
• Enhanced efficiency: Save time and effort – instead of manually crafting queries, AppSec managers and developers can engage with AI Query Builder to generate tailored queries, reducing time spent on query development. 
• Fewer false positives: False positives are always a challenge for any AppSec solution, but AI-generated custom queries can improve accuracy and reduce false positives.  

• Everyone can use it : No longer are custom queries reserved for power users, but now every Checkmarx One user can now better tune their SAST solution using AI.  

Try it yourself.  

Interested in seeing for yourself?  

Join the Checkmarx Early Access program.  

We’re just beginning. Check in next week when we’ll have a new blog post taking us through AI Query Builder for IaC Security. 

(1) Source: IDC, Generative AI Adoption and Attitudes: A Survey of U.S. Developers, Doc #US50655123, May 2023 

Checkmarx Security Research team reached out to Ericsson’s Responsible Disclosure Program, notifying them of the the finding on 14th March 2023. Ericsson acknowledged the finding and replied  that the issue was fixed on 11th April 2023. 

ASP.NET web applications that run with tracing enabled, may publicly expose sensitive information. This feature allows any user to view diagnostic information about a single request for an ASP.NET page. When this feature is enabled,  Trace Viewer (Trace.axd) may be publicly accessible, without server’s root authentication. The Checkmarx Security Research team discovered this vulnerability and will explore what that means for users in this post.   

This research was conducted following Ericsson Vulnerability Disclosure Program. 

One of Ericsson’s subdomains is forecast.ericsson.net. However, when accessing it via a web browser it redirects to https:// forecast.ericsson.net /Login /Login. aspx. No complex reconnaissance process was required to understand that we were dealing with an ASP.NET web application. 

There are several, well-known endpoints/resources of interest to check for when dealing ASP.NET web applications, and  – /Trace.axd is one of them.  Trace.axd is a web-page that is intended to provide extensive logging information in regard to  web requests to the application. – If this is exposed, it may provide attackers unauthenticated access to the last 80 web requests made to the server. This has the potential to result in a  sensitive information, such as PII data, and session details being disclosed. This information may  then be used to potentially take over user accounts, and further compromise Ericsson’s applications. 

After finding Trace Viewer (Trace.axd) on our target subdomain (https://forecast.ericsson.net/Trace.axd), we checked what information was available. 

The picture above shows the Trace Viewer main page (Trace.axd), which is where the physical directory of the web application (E:webrootsSupplyExtranet) and the last requested web application files are printed (Supply/ChangePassword.aspx). 

As you can see, it is  possible to view additional details for each request. This potentially can allow malicious actors  access to sensitive information. The body of POST requests, especially those to the Login/Login.aspx endpoint, are good candidates to monitor for disclosure sensitive information,  including usernames and passwords. We can see    this scenario, where user account credentials, username and password, are both shown in plaintext in the figure below. 

Information disclosure via Trace Viewer (Trace.axd) for ASP.NET web applications is a high severity security issue that can lead to the compromise of sensitive information and online systems. This feature should not be enabled in production environments.