How to Perform Security Testing on SaaS Applications
SaaS ( Software as a Service ) applications have developed rapidly in the past few years . As of 2023, there are more than 30,000 SaaS startups in the world . SaaS applications have become an important part and the first choice for online businesses in countless industries . With simplified processes, convenient delivery and scalability, more and more application data and business logic have been migrated from local to SaaS cloud environments.
However, the growth and popularity of SaaS applications have naturally become an attractive target for numerous cyber threats and attacks. Faced with various security challenges, SaaS application providers and users need to actively analyze and respond through comprehensive security measures and testing.
The main risks faced by SaaS
Since SaaS applications are usually hosted on the service provider's cloud servers and accessed by user devices through the Internet , this delivery model has the advantages of lower costs and easier maintenance . However , once attackers discover security vulnerabilities in SaaS applications, they will try every means to obtain access to application services and obtain data information of users and customers in bulk.
At present, such risks generally include the following aspects:
Multi-tenant architecture flaws
In a multi-tenant SaaS architecture, data from different customers resides on the same server. Once the logical isolation between tenants is not in place, a tenant may accidentally or even intentionally access the data of another tenant, resulting in the leakage of private information and the loss of confidentiality.
Openness for any access
Since SaaS applications can be accessed by anyone from anywhere, attackers are no longer limited and can easily use phishing scams to obtain user credentials or directly gain unauthorized access by cracking weak passwords.
Integration with other applications
SaaS platforms often use APIs to integrate with other applications. If these APIs have security flaws in their design, attackers can use them as a gateway to penetrate multiple systems outside the SaaS application and steal sensitive data.
Failure resulting in data loss
Although SaaS cloud services guarantee the availability of applications, the data security on the cloud server may be lost or damaged due to network problems, equipment failures , or even natural disasters. Therefore, when inspecting SaaS services, the security team should pay attention to the reliability of the data backup strategy to avoid the lack of service integrity due to data loss .
Direct attack
According to the top ten typical web application and API risks listed by the Open Web Application Security Project (OWASP) , we know that once there are logical vulnerabilities and technical problems in SaaS applications , hackers will launch direct attacks and exploits through the Internet , which may cause adverse effects such as service interruptions, data leakage, and privacy violations .
Shared responsibility
Since multiple applications share the same cloud service system and backend logic , operational failures such as configuration errors and service interruptions on the part of the service provider may be amplified by the shared structure of the SaaS system , thereby affecting the user's business and even spreading phishing , malware, and ransomware attacks to the user's business data , forcing the user to passively assume corresponding responsibilities .
Lack of compliance and supervision
Even if the users of SaaS applications try their best to comply with compliance and regulatory requirements, if they neglect to check the compliance of the SaaS suppliers they use, they will face the associated regulatory risks , which will lead to huge fines or damage the company's reputation. In this regard , the security team should regularly review the compliance of SaaS suppliers with industry standards and laws and regulations .
The concept and benefits of testing
Given that SaaS applications simplify complex service processing and provision mechanisms for users, but they themselves usually retain a large amount of sensitive business information and personal data of users and end users , SaaS security testing can conduct in-depth scanning, utilization and evaluation of all components of the SaaS business to discover and repair security vulnerabilities in the application 's interface, network, communication , API, third-party integration, basic code, user input, and role permissions , thereby reducing the operational risks of SaaS applications and improving their security posture .
It can be seen that SaaS security testing not only helps to ensure the security of the company's cloud systems, applications and data , but also can meet various strict compliance requirements.
Test the component of interest
For security testing of SaaS applications , security teams usually need to focus on and check the following three basic components:
Security of the connection
The connection between client devices and SaaS applications is an important risk point that deserves attention . Given the characteristics of SaaS applications, service providers need to implement necessary channel protection, identity authentication, permission management, behavior monitoring and other connection access and guarantees for users . Based on the zero-trust principle of " never trust, always verify " , the security team of the application user needs to understand and plan for subsequent security testing .
Application service security
Although SaaS applications simplify the self-construction of users, users often use APIs and supporting management consoles to implement complex back-end call logic. However , before conducting application security testing, it is necessary for the user's security personnel to interact with the SaaS service provider to understand the basic business type of the platform application itself, the possible challenges of its technical architecture, API permission control, and the settings and operation logic of the management console.
Integrated Interaction Security
Users often need to integrate the services and data provided by the SaaS platform through APIs to provide extended functions, automated workflows , and interactions with other services for their front-end applications . Given that such integration is often completed in one go, the user's security team should review the necessity and controllability of the integration and interaction between the front-end application and the SaaS platform based on the principles of separation of duties (SoD) and least privilege (PoLP).
Testing Phases
In order to avoid the uncertainty of "blind box opening", the user's security team can refer to the following steps to carry out SaaS security testing in stages:
Collecting Information
Before the security team considers conducting security testing on SaaS applications , they need to understand the architecture, network, business logic, data flow, and role permissions of the application to be tested. This is the basis for formulating an effective testing strategy. Since the security team may not be involved in the application project at the beginning, we can obtain "first-hand information" through the following simple questionnaire list :
- What basic functions can the app provide ?
- Which teams will use the application in which scenarios ?
- How important is this application to the front-end business ?
- What types of business data will be stored in the application and how sensitive are they?
- Will end users access the application using managed devices or personal endpoints ?
- Will users access the application using a private, managed network or an internet connection ?
- Is the application accessed through a browser or through an application interface provided by the user ?
- Can the platform vendor provide information about the application's architecture, communications, and configuration ? In particular, the following security control information:
Cloud security components such as Web Application Firewall (WAF)
Available external ports
Load Balancing and DDoS Protection
Single sign-on ( SSO ) integration based on Identity and Access Management (IAM) or multi-factor authentication ( MFA ) access control
Data encryption at rest and in transit
Endpoint detection and response ( EDR ) and anti-virus ( AV ) solutions on servers
API key management and rate limiting
Data and code backup and service high availability (HA)
Logging and monitoring options
Make a plan
Based on the information and complexity of the application to be tested, the security testing team discusses potential limitations and estimated costs with various stakeholders, and ultimately creates a comprehensive security testing plan that includes: clear scope , standards , methods , depth, and system configuration, tools, and scripts required for testing .
Exchanges between the two sides
The security testing team communicates with the supplier of the application being tested to determine the personnel who will perform the test and their contact information, open ports for the testing tools to be used, put their IP addresses in the whitelist, open springboard hosts as needed, and activate installation permissions for the testing tools.
Automatic scanning
In this phase, the security team uses professional scanning tools in an automated carefully look for significant vulnerabilities in the application under test . Such tools are often somewhat invasive . That is, they can crawl every request in the application by simulating potential attackers , thereby quickly discovering potential security weaknesses and vulnerabilities.
Exploit Testing
For the vulnerabilities found by automated scanning, the security testing team needs to use various tools, Selenium scripts, and strategies in PoC (Vulnerability Verification Program) and EXP (Vulnerability Exploitation Program) in combination, and conduct black box, white box, and gray box (on-demand) exploitation and testing on the application in accordance with the standards and scope set by the plan through manual testing. Referring to OWASP Top 10, typical testing points include:
- Injection penetration
- Server Configuration Review
- Fuzzy Input
- Data tampering
- File upload
- Cross-site scripting (XSS)
By simulating real attack scenarios, we can learn about the anti-attack capabilities of the application under test, as well as the data that may be leaked, the system that may be tampered with, and the service that may be interrupted after the attack is successful . It is worth mentioning that in addition to using manual testing techniques , security testers can also use automated tools to simulate human interactions and illegally obtain application access authorization through social engineering .
Assessment Report
After completing the exploit test, the security testing team should calculate the potential system losses based on the recorded vulnerabilities , refer to the CVSS score, and check the following dimensions to implement vulnerability classification, impact analysis, priority assessment, and risk calculation as needed.
- IAM – Role-Based Access Control (RBAC), SSO, MFA
- Data security – data encryption, data classification, data leakage protection (DLP)
- Visibility – logging (SIEM), monitoring, alerting
- Configuration – security settings, access control lists (ACLs), IP whitelists, and third-party applications that are connected
- Network – WAF, intrusion detection, DDoS protection
- Compliance – Certification (ISO 27001, SOC 2 Type II, PCI DSS, etc.), Privacy (PII, HIPAA, GDPR, CCPA, etc.)
In addition, by saving results and taking screenshots on demand, the security testing team can ultimately issue a highly accurate report and provide remediation recommendations to stakeholders .
Correction and retest
For confirmed vulnerabilities , the application user team will work with the security team to rectify them. For those that are difficult to rectify, meta-security components such as cloud access security broker (CASB) and cloud security posture management (CSPM) can be introduced as needed to assist in reinforcement. After completion, the security testing team will enter the retesting phase to confirm whether the vulnerabilities have been fixed and no new vulnerabilities have been generated, thereby improving the overall security posture of the SaaS application.
Regular safety testing
We often say that "security posture is only a temporary, not a permanent one". This concept also applies to the field of SaaS application security testing. To this end, we need to verify the continued effectiveness of the application's security precautions by conducting security testing ( sometimes also called ethical hacking) on a regular basis .
At the same time, we also need to regularly collect and obtain other public reports, shared information, customer and partner feedback about the SaaS applications being tested from open source intelligence (OSINT) so as to carry out security assessment work in a timely manner according to various emergencies .
In general, our approach to SaaS application security is to proactively discover, timely manage, and evaluate on demand to ensure the security of SaaS applications throughout their entire life cycle .