Fixed issues related to -android flag

dakshscra.py

@@ -69,8 +69,8 @@
 
 # Check if results.file_types is set to "auto"
 if results.rule_file and results.rule_file.lower() == "auto":
-    # Set file_types to the output of getAvailableRules()
-    results.rule_file = rutils.getAvailableRules(exclude=["android", "common"])
+    # Incase any rule is not stable that can be excluded from 'auto' mode using - exclude=["notsostable", "common"]
+    results.rule_file = rutils.getAvailableRules(exclude=["common"])
     results.file_types = results.rule_file.lower()  # Override filetypes argument 
 
 # Remove duplicates in rule_file and file_types

rules/scanning/platform/c/c.xml

@@ -165,12 +165,39 @@
 
     <category name="Sensitive Information Handling">
         <rule>
-            <name>Insecure Handling of Sensitive Information</name>
-            <regex>\b(memset|mlock|setrlimit|unlink|remove)\s*\(</regex>
-            <rule_desc>Detects functions used to handle or erase sensitive information improperly.</rule_desc>
-            <vuln_desc>Failure to securely erase or restrict access to sensitive information (e.g., passwords, cryptographic keys) can lead to unintended leaks.</vuln_desc>
-            <developer>Store sensitive information in heap buffers, not stack buffers. Overwrite sensitive data before deletion using `memset()`. Use `mlock()` to prevent swapping and `setrlimit()` to disable core dumps.</developer>
-            <reviewer>Ensure sensitive data is managed securely, overwritten before deletion, and not stored in plaintext unnecessarily.</reviewer>
+            <name>Improper Use of `memset` for Sensitive Data</name>
+            <regex>\bmemset\s*\(\s*(password|key|secret|token|sensitive_data|.*_buffer).*?,.*?\)</regex>
+            <rule_desc>Detects potential improper clearing of sensitive data.</rule_desc>
+            <vuln_desc>Using `memset` for clearing sensitive data can be optimized away by compilers, leaving data in memory.</vuln_desc>
+            <developer>Ensure to use a secure method, such as `explicit_bzero` or similar, to clear sensitive data. Verify that sensitive variables (e.g., passwords, keys) are securely erased before freeing memory.</developer>
+            <reviewer>Check if the data cleared using `memset` is sensitive (passwords, keys, etc.) and confirm if a secure clearing method (like `explicit_bzero`) is implemented to prevent compiler optimizations.</reviewer>
+        </rule>
+
+        <rule>
+            <name>Improper Use of `mlock` for Sensitive Data</name>
+            <regex>\bmlock\s*\(.*?\)</regex>
+            <rule_desc>Detects improper use of `mlock` for securing sensitive data.</rule_desc>
+            <vuln_desc>Failure to lock sensitive data in memory may expose it to swapping, potentially leaking to disk.</vuln_desc>
+            <developer>Use `mlock` on sensitive data buffers to prevent them from being swapped to disk. Ensure sufficient permissions and memory limits are set for the application.</developer>
+            <reviewer>Verify that sensitive data buffers are locked using `mlock` to prevent swapping. Confirm that the application handles cases where `mlock` fails gracefully.</reviewer>
+        </rule>
+
+        <rule>
+            <name>Improper Use of `setrlimit` for Core Dump Prevention</name>
+            <regex>\bsetrlimit\s*\(\s*RLIMIT_CORE\s*,\s*0\s*\)</regex>
+            <rule_desc>Detects improper handling of `setrlimit` for preventing core dumps.</rule_desc>
+            <vuln_desc>Failure to disable core dumps might expose sensitive data during application crashes.</vuln_desc>
+            <developer>Use `setrlimit(RLIMIT_CORE, 0)` to disable core dumps for applications handling sensitive data. Test for successful application of limits.</developer>
+            <reviewer>Check if core dumps are disabled using `setrlimit(RLIMIT_CORE, 0)`. Ensure no sensitive data can leak through crash dumps in production environments.</reviewer>
+        </rule>
+
+        <rule>
+            <name>Unsafe File Deletion Using `unlink` or `remove`</name>
+            <regex>\b(unlink|remove)\s*\(\s*(".*(password|key|secret).*?"|sensitive_file.*)\s*\)</regex>
+            <rule_desc>Detects unsafe deletion of sensitive files.</rule_desc>
+            <vuln_desc>Files containing sensitive data might still be recoverable after deletion without secure erasure.</vuln_desc>
+            <developer>Implement secure file deletion methods, such as overwriting the file contents before deletion. Avoid plain `unlink` or `remove` for sensitive files.</developer>
+            <reviewer>Ensure sensitive files are securely deleted using overwriting methods before unlinking or removing. Check if sensitive files are flagged correctly and handled securely.</reviewer>
         </rule>
     </category>
 

rules/scanning/platform/common.xml

@@ -78,15 +78,17 @@
             <reviewer>Reviewers should verify the secure handling of RSA private keys and assess if adequate measures are in place to safeguard their confidentiality and integrity.</reviewer>
         </rule>
     </category>
+
     <category name="Information Disclosure">
         <rule>
-            <name>Information Disclosure: Stack Trace or Error Messages</name>
-            <regex>(?i)Stacktrace</regex>
-            <rule_desc>Detects potential information disclosure due to stack traces or error messages.</rule_desc>
-            <vuln_desc>If this rule matches, it indicates the potential presence of stack traces or error messages in the code, which can provide valuable information to attackers and facilitate targeted attacks.</vuln_desc>
-            <developer>Developers should ensure that error handling mechanisms are properly implemented, and sensitive information is not exposed in error responses.</developer>
-            <reviewer>Reviewers should check for the presence of sensitive information in error responses and verify the implementation of proper error handling.</reviewer>
+            <name>Insecure HTTP Communication</name>
+            <regex>http://</regex>
+            <rule_desc>Detects the use of insecure HTTP communication.</rule_desc>
+            <vuln_desc>Using HTTP exposes the application to man-in-the-middle attacks, allowing attackers to intercept or manipulate traffic.</vuln_desc>
+            <developer>Use HTTPS for all network communication to ensure secure data transmission. Avoid using HTTP unless explicitly required and justified by the use case.</developer>
+            <reviewer>Review all URLs or network requests across source code, configuration files, and external API references to ensure HTTPS is used instead of HTTP.</reviewer>
         </rule>
+
         <rule>
             <name>Sensitive Debug Information</name>
             <regex>(?i)\.debug\s*=\s*True|\$debug\s*=\s*true|DEBUG\s*=\s*True|IsDebuggingEnabled\s*=\s*true</regex>
@@ -96,6 +98,7 @@
             <reviewer>Reviewers should check for debug-related configurations in application settings and ensure that they are disabled or set to false in production environments to protect sensitive information.</reviewer>
         </rule>
     </category>
+
     <category name="Dynamic SQL Queries">
         <!-- Unsafe string concatenation in SQL queries -->
         <rule>

rules/scanning/platform/dotnet/dotnet.xml

@@ -83,6 +83,7 @@
             <reviewer>Reviewers should check for the presence of untrusted data output involving HttpContext.Current.Request.QueryString. They should verify if developers have implemented proper input validation, output encoding, and secure data handling techniques to prevent security vulnerabilities. Reviewers should also assess the sensitivity of the output data and confirm the presence of appropriate security controls.</reviewer>
         </rule>
     </category>
+
     <category name="File System Vulnerabilities">
         <rule>
             <name>Path Traversal: Directory.GetFiles</name>
@@ -93,6 +94,7 @@
             <reviewer>Reviewers should examine the usage of Directory.GetFiles and verify if proper input validation is performed to prevent path traversal vulnerabilities. They should assess the file path handling and confirm that user-supplied input is restricted to authorized directories, preventing unauthorized access to sensitive files.</reviewer>
         </rule>
     </category>
+
     <category name="Insecure Method/Function Call">
         <rule>
             <name>Unsafe Method: Command Execution</name>
@@ -103,6 +105,7 @@
             <reviewer>Reviewers should ensure that proper input validation and sanitization techniques are implemented for command execution methods. They should verify that developers have taken appropriate measures to prevent command injection vulnerabilities, such as using parameterized queries or prepared statements. Reviewers should also assess the sensitivity of the commands executed and confirm that relevant security controls are in place.</reviewer>
         </rule>
     </category>
+
     <category name="Trust-boundary Validation or 3rd-Party Interactions">
         <rule>
             <name>Unvalidated Redirects and Forwards</name>
@@ -154,14 +157,15 @@
 
     <category name="Information Disclosure">
         <rule>
-            <name>Information Disclosure: Stack Trace</name>
-            <regex>(?i)Response\.Write\s*\(.*StackTrace</regex>
-            <rule_desc>Detects the usage of Response.Write method that may inadvertently expose stack trace information.</rule_desc>
-            <vuln_desc>If this rule matches, it indicates the potential vulnerability of using Response.Write method that may inadvertently expose stack trace information. Stack trace details can provide valuable information to attackers, aiding them in identifying potential vulnerabilities or weaknesses in the application.</vuln_desc>
-            <developer>Developers should avoid using Response.Write method to output stack trace information in a production environment. Stack traces should only be displayed for debugging purposes and should be properly handled and logged in an appropriate manner. Instead of using Response.Write, developers should consider using custom error pages or appropriate logging mechanisms to capture and handle error information securely.</developer>
-            <reviewer>Reviewers should ensure that Response.Write method is not used to output stack trace information in a production environment. They should verify that developers have implemented proper error handling and logging mechanisms to prevent the inadvertent exposure of sensitive information. Reviewers should also assess the sensitivity of the information exposed and confirm that relevant security controls are in place.</reviewer>
+            <name>Stack Trace or Error Disclosure</name>
+            <regex>(?i)(Response\.Write\s*\(.*StackTrace|ex\.ToString\(\)|Console\.WriteLine\(.*Exception.*\)|throw new Exception\(.+\))</regex>
+            <rule_desc>Detects unsafe error handling and stack trace exposure in .NET applications.</rule_desc>
+            <vuln_desc>Using `Response.Write`, `ex.ToString()`, or similar methods to output exception details can expose sensitive stack trace information, aiding attackers in identifying vulnerabilities.</vuln_desc>
+            <developer>Developers should avoid exposing stack traces or detailed exceptions directly to users. Use secure logging frameworks (e.g., Serilog, NLog) and custom error pages in web applications.</developer>
+            <reviewer>Reviewers should ensure that stack traces and exceptions are not exposed to users and are logged securely. Verify proper error handling mechanisms in both web and non-web contexts.</reviewer>
         </rule>
     </category>
+
     <category name="Insecure Configuration">
         <rule>
             <name>API Route Prefix: Improper Usage</name>
@@ -172,6 +176,7 @@
             <reviewer>Reviewers should check for the presence of [RoutePrefix] attribute in API controllers and assess the configuration for proper route prefixing. They should verify that developers have followed established routing conventions and consider any potential conflicts or security risks. Reviewers should also ensure that the routing configuration has been thoroughly tested to avoid functional errors.</reviewer>
         </rule>
     </category>
+
     <category name="Disabled/Missing Security Controls">
         <rule>
             <name>Request Validation: Disabled Configuration</name>
@@ -190,6 +195,7 @@
             <reviewer>Reviewers should check for the presence of insecure configuration of the ServerCertificateValidationCallback. They should assess if developers have followed best practices for certificate validation, such as verifying the certificate's chain of trust, checking for revocation status, and validating the server's hostname. Reviewers should also verify the usage of well-established libraries or frameworks that provide robust certificate validation mechanisms.</reviewer>
         </rule>
     </category>
+
     <category name="Effective/Standard Mitigations Implemented">
         <rule>
             <name>XSS Mitigation: HTML Encoding using Razor</name>

rules/scanning/platform/java/java.xml

@@ -170,6 +170,7 @@
             <developer>Developers should ensure that the logger functions (error, warn, info, debug, trace) in Java code are used securely. They should carefully validate the logged data to prevent the inclusion of sensitive information. Additionally, developers should review and configure the logging framework to avoid the exposure of sensitive data through the logs.</developer>
             <reviewer>Reviewers should verify that the usage of logger functions (error, warn, info, debug, trace) in Java code is appropriate and adheres to secure coding practices. They should assess if proper validation mechanisms are in place to prevent the logging of sensitive information. Reviewers should also review the log configurations to ensure that log levels are set appropriately and sensitive data is not leaked through the logs.</reviewer>
         </rule>
+
         <rule>
             <name>Debugging and Logging Statements</name>
             <regex>(System\.out\.print|System\.err\.print|System\.out\.println|System\.err\.println|log\.(debug|trace))</regex>
@@ -178,14 +179,16 @@
             <developer>Developers should ensure that debugging and logging statements are not present in production code. They should review and remove or disable any logging statements that may log sensitive information. Additionally, developers should follow secure coding practices to prevent the accidental inclusion of debugging statements in production code.</developer>
             <reviewer>Reviewers should verify that debugging and logging statements are appropriately handled in production code. They should assess if sensitive information is inadvertently logged and if proper mechanisms are in place to prevent it. Reviewers should also evaluate the code review and release processes to ensure that debugging statements are removed or disabled before deploying to production environments.</reviewer>
         </rule>
+
         <rule>
-            <name>Stack Traces in Error Messages</name>
-            <regex>(e\.printStackTrace|e\.getCause\.printStackTrace)</regex>
-            <rule_desc>Detects the usage of printStackTrace() method in exception handling, which can expose sensitive information through error messages.</rule_desc>
-            <vuln_desc>If this rule matches, it indicates the use of printStackTrace() method in exception handling, which can include detailed stack trace information in error messages. Stack traces may contain sensitive data or implementation details that could aid attackers in identifying vulnerabilities or understanding the system's internal structure.</vuln_desc>
-            <developer>Developers should avoid including stack traces in error messages displayed to users or logged in application logs. They should handle exceptions appropriately by providing meaningful error messages without revealing sensitive information. Developers should implement proper exception handling and logging practices.</developer>
-            <reviewer>Reviewers should verify that stack traces are not included in error messages presented to users or logged in application logs. They should assess if proper exception handling practices are followed, and error messages are appropriately sanitized to prevent the disclosure of sensitive information. Reviewers should also evaluate the logging mechanisms to ensure that stack traces are logged securely.</reviewer>
+            <name>Stack Trace or Error Disclosure</name>
+            <regex>(?i)(e\.printStackTrace\(\)|e\.getCause\(\)\.printStackTrace\(\)|System\.out\.print\(.*Exception.*\)|throw new \w+Exception\(.+\))</regex>
+            <rule_desc>Detects unsafe stack trace logging or error handling in Java code.</rule_desc>
+            <vuln_desc>Directly printing stack traces or detailed exceptions (e.g., via `e.printStackTrace` or `e.getCause().printStackTrace`) can expose sensitive information, such as implementation details and file paths.</vuln_desc>
+            <developer>Developers should replace direct stack trace printing with centralized logging frameworks like Log4j or SLF4J, ensuring sensitive information is excluded from logs.</developer>
+            <reviewer>Reviewers should check for improper use of `printStackTrace` and `getCause().printStackTrace` and ensure exceptions are logged securely and not exposed in production environments.</reviewer>
         </rule>
+
         <rule>
             <name>Unencrypted Data Transmission over HTTP</name>
             <regex>new\s*HttpGet|new\s*HttpPost|new\s*HttpPut|new\s*HttpDelete|new\s*HttpURLConnection</regex>