Need for AppSec exposed by the ‘ResumeLooters’ SQL Injection & XSS Attacks

Need for AppSec exposed by the ‘ResumeLooters’ SQL Injection & XSS Attacks

Understanding SQL injection & XSS attacks

SQL Injection and XSS attacks exploit vulnerabilities in web applications to execute malicious scripts or queries, granting attackers unauthorized access to sensitive data. These methods remain prevalent due to their effectiveness in bypassing traditional security measures, exploiting weaknesses in code and third-party components.

The ResumeLooters attack, explained  

The hacker group known as 'ResumeLooters' exploited SQL injection and XSS vulnerabilities to compromise 65 legitimate job listing and retail websites, ultimately stealing the personal data of over two million job seekers across the APAC region. This breach included sensitive information such as names, email addresses, phone numbers, employment history, and education details. The group aimed to monetize this stolen data by selling it on Telegram channels, showcasing a concerning blend of technical prowess and criminal intent. This incident underscores the critical need for enhanced security measures across digital platforms to protect against such invasive threats.

How to Defend Against SQL injection & XSS Attacks  

Commodity scanners can easily identify the vulnerabilities

SAST tools analyze source code to detect security vulnerabilities early in the software development lifecycle (SDLC). By scrutinizing code without executing it, SAST identifies potential security flaws like SQL Injection and XSS vulnerabilities, enabling developers to address them before deployment. This preemptive approach is vital for creating robust applications resilient to exploitation. In the context of the reported attack, SAST could have identified and highlighted vulnerable code segments, allowing developers to rectify them and mitigate risk.  

A less common yet popular approach would be using a dynamic scanner, a.k.a. DAST. However, we will focus on the low hanging fruit in this post.

The mitigation of code vulnerabilities is hard

While Static Application Security Testing (SAST) plays a pivotal role in detecting vulnerabilities like SQL Injection and XSS attacks early in the Software Development Life Cycle (SDLC), the main challenge is with the mitigation, as developer adoption is required.  

The common ways to integrate SAST are IDE plugins, CLI within CI/CD pipelines, or running Status Checks on Pull Requests. Each approach has its own challenges.  

IDE Plugins

The adoption of Integrated Development Environment (IDE) plugins presents a direct method for developers to identify vulnerabilities as they code. However, challenges persist:

• Coverage Problem: Based on multiple customer conversations we had, the adoption rate of IDE plugins is around 15% among developers, indicating a significant gap in potential security coverage.
• Lack of Context: Developers often see vulnerabilities without sufficient context, making it difficult to understand what needs to be fixed, e.g. which high severity vulnerability is more important and which one was introduced by the developer in the current feature branch.  
• Managing False Positives: The process to mark issues as false positives often requires accessing external tools, disrupting the developer's workflow and decreasing the likelihood of consistent use.

CI/CD Pipelines

Incorporating security tools within Continuous Integration/Continuous Deployment (CI/CD) pipelines ensures that code is automatically scanned for vulnerabilities before deployment. However, this approach has its limitations:

• Dependency on Engineering Teams: Requires active involvement from engineering teams and code modifications, which can slow down the integration process across repositories.
• Challenges in Coverage: The dependency on specific team actions makes it difficult to achieve widespread implementation.

Status Checks on PRs

Implementing status checks on pull requests can serve as a final gate before code is merged and released. Yet, this method introduces its own set of challenges:

• Late in the Process: By the time developers are ready to merge their PRs, introducing new "tech debt" in the form of security findings is often seen as an unwelcome delay. This can lead to vulnerabilities being introduced into the codebase due to time constraints.  
• Post-Factum Remediation: Even with 100% tool adoption, if a code vulnerability ends up as an issue (e.g. Jira ticket), it will take time until the issue will be prioritized, picked up and addressed by the developer that is equipped to fix it.

Conclusion

To address these challenges, a pipelineless security approach offers a novel solution. By removing the dependency on traditional CI/CD pipelines and integrating security directly into the developer's environment, pipelineless security facilitates immediate and context-rich feedback on vulnerabilities. This approach ensures developers have the necessary information to remediate issues without leaving their workflow, significantly increasing the adoption and effectiveness of security practices. Pipelineless security not only bridges the gap in coverage but also aligns with developers' routines, making security a seamless aspect of software development rather than an external imposition.

Learn more about Arnica’s pipelineless approach to SAST!