Post

OWASP Top 10 - 2021

OWASP Top 10 - 2021

2021 Top 10 Web Application Security Risks

A1:Broken Access Control (was A5)

Description

Access control is a security mechanism that enforces policies to ensure users can only act within their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of data, or performing business functions outside the user’s limits. This can happen in the following scenarios:

  • Issues arise when users can manipulate system functions in unexpected ways. This vulnerability often occurs when resources that should only be accessible to specific users or roles are set to ‘allow’ by default, or when ‘deny’ rules are not properly configured.
  • Attackers can modify URLs to view information of other accounts or use attack tools to manipulate API requests to bypass access control.
  • This occurs when there is no proper access control for HTTP methods like POST, PUT, and DELETE on APIs.
  • This includes cases where an unauthenticated user can act as a regular user without logging in, or a user logged in with standard privileges can access administrator (admin) functions.
  • This happens when JWT (JSON Web Tokens) used as access control tokens are replayed or tampered with, or when cookies or hidden fields are manipulated to attempt privilege escalation.
  • CORS (Cross-Origin Resource Sharing) misconfiguration allows unauthorized API access.
  • When unauthenticated users can perform force Browse to access resources they are not authorized to view.

Prevention

Access control should be effectively applied only by trusted server-side code or serverless APIs, where attackers cannot modify access control checks or metadata.

  • All resources, except public ones, should be ‘denied’ by default. This means applying the deny-by-default principle.
  • Implement mechanisms to minimize CORS usage. If necessary, use a whitelist approach that allows access only from a minimal set of permitted origins.
  • Access control models should enforce that only the record owner has permissions to create/read/update/delete specific records, rather than allowing any user to do so.
  • For business applications, specific requirements should be limited by the Domain Model (e.g., limiting purchase quantity, number of purchases within a certain period).
  • Disable directory listing on web servers and ensure that metadata files like .git or backup files are not present in the web root.
  • Implement proper logging for access control failures, warnings, and other relevant events. This helps detect and respond to suspicious activities.
  • Apply appropriate rate limits to API calls related to access control to prevent attack tools from making excessive unauthorized requests.
  • JWTs should be immediately invalidated after logout and it is recommended to set a short validity period for them.

Attack Scenarios

  • Scenario #1: Unauthorized Account Information Access An application uses code that does not properly validate the acct parameter provided by the user in an SQL query to retrieve account information. An attacker can easily modify the acct parameter, for example, https://example.com/app/accountInfo?acct=notmyacct, to request information for other users’ accounts. The server’s code, if structured as follows, is vulnerable:

    1
    2
    
    pstmt.setString(1, request.getParameter("acct")); // User input used without validation
    ResultSet results = pstmt.executeQuery();
    

    In this case, it’s not an SQL injection, but an access control issue arising from missing authorization validation for the acct parameter.

  • Scenario #2: Admin Page Access via Force Browse An attacker simply force-browses target URLs. For example, if logged in as a regular user, the attacker tries to access an admin-only page like https://example.com/app/admin_getappInfo. If access is granted despite lacking administrative privileges, this indicates an access control vulnerability.

    1
    2
    
    https://example.com/app/getappInfo
    https://example.com/app/admin_getappInfo // Accessible even without admin privileges
    

A2:Cryptographic Failures (was A3 - Sensitive Data Exposure)

Description

Cryptographic Failures occur when sensitive data is not properly protected while in transit or at rest. This vulnerability is closely related to the previous ‘Sensitive Data Exposure’ vulnerability and specifically arises when the data’s protection requirements are not adequately understood. For example, data such as passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws like the EU’s GDPR (General Data Protection Regulation) or regulations such as the PCI DSS (Payment Card Industry Data Security Standard) for financial data.

Vulnerabilities can exist in the following situations:

  • Is any data being sent in clear text? Are unencrypted protocols like HTTP, SMTP, or FTP being used?
  • Are old or weak cryptographic algorithms or protocols being used from default settings or legacy code?
  • Are default cryptographic keys generated from weak random number generators or being reused? Is key management properly implemented? Are cryptographic keys exposed in source code repositories?
  • Are server-side certificate validation or trust chains being properly validated?
  • Are Initialization Vectors (IVs) not being used, reused, or generated in an insecure manner, preventing their proper use in cryptographic operations? Is it certain that insecure modes of operation like ECB (Electronic Codebook) are not being used?
  • Are deprecated or insecure hash functions like MD5 or SHA1, or non-cryptographic hash functions, being used?
  • Are deprecated cryptographic padding methods like PKCS #1 v1.5 being used?
  • Are cryptographic error messages or side-channel information that could be exploitable, such as through Padding Oracle Attacks, present?

Prevention

The first thing to consider when protecting data is to classify whether it is being processed, stored, or transmitted, and to first identify which data is classified as sensitive by privacy laws, regulations, or business needs.

  • Do not store sensitive data if it is not needed. Data that leaves no trace cannot be stolen. Promptly discard unnecessary data.
  • Always ensure sensitive data is encrypted.
  • Verify the use of modern standard algorithms, protocols, and keys, and ensure proper key management. Keys should be stored securely with restricted access.
  • Transmit data using encrypted protocols like TLS (Transport Layer Security) and enforce encryption using directives like HTTP Strict Transport Security (HSTS).
  • Disable caching of responses that contain sensitive data.
  • Do not use legacy protocols like FTP and SMTP for transmitting sensitive information.
  • For passwords, use strong salted hash functions like PBKDF2, bcrypt, scrypt, and Argon2.
  • Use cryptographically secure pseudo-random number generators (CSPRNGs) to select appropriate IVs. IVs should not be reused more than once.
  • Use authenticated encryption rather than simple encryption. This ensures not only confidentiality but also the integrity of the data.

Attack Scenarios

  • Scenario #1: Exposure of Stored Data During Transmission An application uses a database that automatically encrypts card information. However, this data is decrypted automatically upon retrieval, making it possible to exfiltrate the card information in plain text due to an SQL injection vulnerability. In this case, encryption at rest is secure, but encryption during transmission is not properly implemented.

  • Scenario #2: Session Hijacking via TLS Downgrade On a website that does not enforce TLS, an attacker performs a TLS downgrade attack (e.g., SSL Stripping) to downgrade HTTPS to HTTP, then steals the user’s cookies. Subsequently, the attacker can hijack the user’s session using the stolen cookies and modify the user’s personal information. If the data is particularly sensitive, such as financial information, the attacker might even alter values and submit the modified data.

  • Scenario #3: Weak Password Hashing and Brute-Force Attacks If a password database does not use salts, an attacker might be able to retrieve information from the password database through vulnerabilities like file upload flaws. Subsequently, the attacker could easily decrypt the passwords using Rainbow Table Attacks or Brute-force Attacks.


A3:Injection (was A1 - Injection)

Description

Injection vulnerabilities occur when an application interprets untrusted data as part of a command or query and executes it. This allows attackers to execute unintended commands or access, modify, or delete data.

Vulnerabilities exist in the following cases:

  • This occurs when user-supplied data is not validated, filtered, or properly sanitized.
  • It’s vulnerable when dynamic queries without context-aware escaping or non-parameterized calls are directly executed by an interpreter.
  • When hostile data is added to Object-Relational Mapping (ORM) search parameters to extract sensitive information.
  • This happens when hostile data is used directly or concatenated into strings.
  • Common injection attacks include SQL Injection, NoSQL Injection, OS Command Injection, ORM Injection, LDAP Injection, and Expression Language (EL) or Object Graph Navigation Library (OGNL) Injections.
  • Source code review is one of the best ways to find injection vulnerabilities, and automated tools must check all parameters, headers, URLs, cookies, JSON, SOAP, and XML data inputs.
  • Organizations can integrate SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and IAST (Interactive Application Security Testing) tools into their CI/CD (Continuous Integration/Continuous Delivery) pipelines to detect injection flaws before product release.

Prevention

The most crucial aspect of defending against injection attacks is separating data from commands/queries.

  • Use safe APIs. For example, use Parameterized Queries for SQL queries and pass arguments through safe APIs when executing OS commands.
  • Use whitelist-based server-side input validation. While not a perfect defense, it provides an additional layer of protection. Blacklist approaches are often bypassable and should be avoided.
  • Use dynamic queries that employ specific escape syntax to escape special characters. This ensures user input is not interpreted as part of the code.
  • Use LIMIT or other SQL control statements to prevent large amounts of data disclosure due to SQL injection (e.g., limiting the number of returned records).

Attack Scenarios

The following two scenarios can apply to both types of attacks:

1
http://example.com/app/accountView?id=' or '1'='1
  • Scenario #1: Using Untrusted Data Directly (SQL Injection) An application is vulnerable if it directly concatenates user-provided id parameters into an SQL query string.

    1
    
    String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
    

    If an attacker enters id=' or '1'='1', the query becomes SELECT * FROM accounts WHERE custID='' or '1'='1', which could return all account information.

  • Scenario #2: ORM (Object-Relational Mapping) Injection Similarly, if an application uses an ORM framework and directly passes user input to the createQuery method, a blind trust issue arises.

    1
    
    Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
    

    In this case, too, an attacker can manipulate the id parameter to execute unintended queries or extract data.


A4:Insecure Design (New)

Description

Insecure Design goes beyond simply missing or ineffective control designs; it refers to a system or software that is fundamentally designed in a way that it cannot defend against certain attacks. This is different from insecure implementation.

Insecure design is a problem that arises because, from the outset of building software or a system, there was no proper consideration of the level of security required or a proper understanding of the specific characteristics of the business.

  • Requirements and Resource Management: Business requirements for the application must be collected and negotiated. This must include confidentiality, integrity, availability, and authenticity for all data. It should include functional and non-functional security requirements, as well as planning for the budget related to all design, build, testing, and operational security activities.
  • Secure Design: Secure design is a culture and methodology that continually evaluates and tests for threats, ensuring code that prevents known attacks. Threat Modeling should be included in refinement sessions, and potential vulnerabilities should be discussed during user story development. It’s crucial to define how appropriate behavioral conditions will be validated and to document the results of user stories. Secure design is not about adding tools or bolting them on later, but rather something that must be integrated from the beginning of the project.
  • Secure Development Lifecycle: Secure software requires a Secure Development Lifecycle (SDLC), secure design patterns, secure component libraries, tooling, and threat modeling. It’s advisable to engage security professionals at the start of the overall project and software maintenance.

Prevention

  • It is recommended to establish a Secure Development Lifecycle (SDLC) and to collaborate with experts who can help evaluate privacy-related controls and design security.
  • Conduct threat modeling for critical authentication, access control, business logic, and key flows.
  • Integrate security language and controls into user stories. For example, clearly state security requirements such as “Users must use an encrypted connection when entering sensitive data.”
  • Write unit and integration tests to validate all critical flows.
  • Segregate network and system layers at all tiers that could pose a risk (e.g., placing database servers and web servers in different network segments).
  • Limit consumption by users or services (e.g., API call rate limits, resource usage limits).

Attack Scenarios

  • Scenario #1: Insecure Credential Recovery Workflow A credential recovery workflow might include a question-and-answer flow. If the system allows more than one person to validate credentials with the same answer, an attacker could easily figure out the answer and gain access to another user’s account. Such code should have been removed from a secure design from the outset.

  • Scenario #2: Mass Booking Using Business Logic Vulnerabilities Imagine a movie theater website that allows a maximum of 15 reservations, with discounts for group bookings. An attacker might implement a threat model for this business logic and attempt to reserve 600 seats. If the system fails to block such abnormal reservation attempts, it would result in significant financial loss for the movie theater. This is not a bug in implementation, but a problem that arises because this threat was not considered during the design phase.

  • Scenario #3: Auction Manipulation by Bots If an e-commerce auction website lacks proper bot defenses (e.g., CAPTCHA, abnormal activity detection), a malicious hacker could use bots to unnaturally inflate auction prices or make fraudulent purchases that harm other users. This is because the system’s design is inherently vulnerable to bot attacks.


A5:Security Misconfiguration (was A6 - Security Misconfiguration)

Description

Security Misconfiguration vulnerabilities occur when security features are unintentionally disabled, insecure default settings are maintained, or unnecessary functionalities are enabled. This can happen at any layer of the application stack.

Vulnerabilities occur in the following cases:

  • This happens when proper security hardening is missing in any part of the application stack, or when permissions for cloud services are inadequately set.
  • It becomes vulnerable when unnecessary functionalities (e.g., unnecessary ports, services, pages, accounts) are enabled or installed.
  • This occurs when default accounts and their passwords are not changed or remain in their original state.
  • When error handling or more information than just an error (e.g., stack traces, component version information) is shown to the user.
  • When latest security features are disabled or not securely configured for an upgraded system.
  • This arises when the security settings within application servers, frameworks, libraries, databases, etc., are configured to insecure values.
  • When the server does not send secure headers (e.g., Content-Security-Policy, X-Content-Type-Options) or directives, or when they are not set to secure values.
  • When software is outdated or contains known vulnerabilities.
  • Without a consistent and repeatable security configuration process, systems become highly exposed to risks.

Prevention

  • Create a repeatable hardening process to allow for quick and easy deployment to different environments. Development, QA, and production environments should all have the same configuration values, and each should use distinct certificates. These processes should be automated whenever possible, to minimize the cost of installing new secure environments.
  • Remove or do not install unnecessary components. Aim for the minimum necessary platform.
  • Implement tasks to review and update appropriate configurations for all security notes, updates, and patches. Also, periodically review cloud storage permissions.
  • A segmented application architecture helps components operate effectively and reliably (e.g., logically/physically separating web servers, application servers, and database servers).
  • Configure logic to send security directives, such as Security Headers, to the client.
  • Build automated processes that effectively verify each setting’s value across all environments.

Attack Scenarios

  • Scenario #1: Undeleted Sample Application and Default Account An application server operates with a sample application that was not removed from the production server. This sample application is known to have security vulnerabilities, and an attacker exploits it to compromise the server. If this application is an admin console and the default account and password have not been changed, the attacker will take full control of the system using the default password.

  • Scenario #2: Directory Listing Enabled and Code Reverse Engineering The directory listing feature is not disabled on the server. An attacker can easily browse the server’s directories. The attacker will find and download compiled Java class files, then decompile and reverse engineer the code. Through this, the attacker will discover and exploit vulnerable access control flaws.

  • Scenario #3: Information Disclosure via Detailed Error Messages If an application server exposes overly detailed error messages to users, it reveals information about component versions or internal structures, making it easier for attackers to identify and exploit vulnerabilities.

  • Scenario #4: Cloud Service Misconfiguration Leading to Sensitive Data Theft If a cloud service provider sets the Content Security Policy (CSP) header to a default value that allows users to open permissions, it could enable access to storage within the cloud, leading to the exfiltration of sensitive data. (e.g., Public Read/Write permissions set for an S3 bucket).


A6:Vulnerable and Outdated Components (was A9 - Using Components with Known Vulnerabilities)

Description

Vulnerable and Outdated Components vulnerabilities occur when applications use libraries, frameworks, and other software components that have known vulnerabilities but are not updated or properly patched. Attackers can exploit these vulnerabilities to compromise the application.

Vulnerabilities exist in the following cases:

  • This is a vulnerability when you do not know the versions of all components used on both the server-side and client-side.
  • It is vulnerable when software is vulnerable, no longer supported (End-of-Life), or outdated. This includes all components such as the OS, application server, DBMS, APIs, libraries, and runtime environments.
  • This occurs when you do not regularly scan for vulnerabilities or stay updated on new security news (e.g., CVEs) related to the components you are using.
  • This happens when frameworks or platforms with known risks are not upgraded or fixed. This is often more frequent if patching occurs only monthly or quarterly, or only on the first day of each month (i.e., if the security patching cycle is too slow or irregular).
  • This occurs when software developers do not test newly upgraded libraries. (This can lead to reluctance to update due to compatibility issues.)
  • This is a vulnerability when the configuration of each component is not secured.

Prevention

  • Remove unused features, dependencies, components, files, and documentation. Maintain only the bare essentials.
  • Continuously monitor databases like CVE (Common Vulnerabilities and Exposures) and NVD (National Vulnerability Database) to stay informed about new security news related to your components. Consider subscribing to email alerts if vulnerabilities are discovered in components you use.
  • Obtain components from official sources through secure links. Be careful not to acquire components through paths that might contain malicious code.
  • Monitor libraries and components that are not being maintained or are not receiving security patches. If patching is not possible, consider Virtual Patching to address known vulnerabilities.
  • All organizations must continuously perform monitoring, update checks, and configuration changes throughout the application’s lifecycle.

Attack Scenarios

  • Scenario #1: System Compromise via Vulnerable Component Components often run with the same privileges as the application. Therefore, a vulnerability in any component can lead to severe issues. For example, if a Remote Code Execution (RCE) vulnerability is found in a specific library used by a web server, an attacker could completely take over the server through this vulnerability. For IoT devices, regular patching may be difficult or impossible, but for biomedical devices, patching is absolutely crucial. A lack of patches could lead to serious harm or personal data breaches.

A7:Identification and Authentication Failures (was A2 - Broken Authentication)

Description

Identification and Authentication Failures are vulnerabilities that arise when the identity, authentication, and session management functions of users, systems, or services are not properly implemented. This is a very critical area for protection against authentication-related attacks.

Vulnerabilities can exist in the following areas:

  • This occurs when automated attacks like credential stuffing are allowed. - An attack technique where account information obtained from other websites is indiscriminately entered.
  • This happens when weak and well-known default credentials, such as admin/admin, are permitted.
  • This occurs when recovery and “forgot password” processes use insecure methods like knowledge-based answers. (e.g., questions like “What is your mother’s maiden name?” or “What is the name of your elementary school?”)
  • It is vulnerable when passwords are stored or transmitted in plain text, or when weak encryption algorithms are used to protect them.
  • MFA (Multi-Factor Authentication) is insufficient or not used, making automated attacks more likely.
  • When session information is exposed directly in the URL (e.g., jsessionid as a URL parameter), leading to session hijacking vulnerabilities.
  • When session identifiers can be reused after successful login (vulnerable to Session Fixation attacks).
  • When session IDs are not properly invalidated after logout or a certain timeout period, or when authentication tokens like SSO (Single Sign-On) tokens are not properly invalidated, making the system vulnerable to session hijacking attacks.

Prevention

  • Use MFA whenever possible to prevent automated attacks and stolen credential reuse attacks.
  • Administrator accounts should be shipped or deployed without using default values. That is, the system should enforce password changes upon deployment or require strong passwords during user creation.
  • Check for weak passwords and implement a policy that disallows passwords found in the top 10,000 worst password lists. Providing a password strength meter is also a good practice.
  • Set appropriate password length, complexity, and rotation policies. (e.g., minimum 12 characters, mix of uppercase/lowercase letters, numbers, and special characters, change every 90 days).
  • Log failed access attempts, and to prevent automated attacks, limit the number and time of login attempts, and prevent DoS (Denial of Service) attacks. (e.g., account lockout after N failed attempts, apply a cooldown period).
  • After login, use a secure session manager that generates random session IDs with high entropy. Session information should not be exposed in the URL, and sessions should be invalidated after login or after a specific period of inactivity.

Attack Scenarios

  • Scenario #1: Credential Stuffing Attack Credential stuffing is a common attack method. Without defense against it, the application can be used by attackers as a channel to determine whether stolen credentials are valid. Attackers can try numerous accounts to find valid ones.

  • Scenario #2: Use of Weak Passwords Most authentication attacks occur because users use weak or reused passwords. Therefore, MFA should be used, or the system should enforce strong password policies to prevent the use of easy passwords. For example, a system that allows passwords like 'password123' is highly vulnerable to brute-force attacks.

  • Scenario #3: Improper Session Timeout Assume a user logs into a public computer, then simply closes the browser tab or leaves the computer without logging out, because the session timeout is not properly set. If an attacker uses the same computer an hour later and opens the browser, the previous user’s authenticated session might still be active, allowing the attacker to access the service. Proper session settings (e.g., short inactivity timeouts) should be implemented even when users close tabs instead of logging out.


A8:Software and Data Integrity Failures (New)

Description

Software and Data Integrity Failures are vulnerabilities that arise from insufficient integrity verification for software updates, critical data, CI/CD pipelines, and crucial code. This occurs when untrusted data flows into critical parts of the application and is then exploited.

  • Software updates, critical data, libraries, and dependencies obtained from untrusted sources are vulnerable if they execute automatically without code or configuration changes. This can occur due to insufficient security in the CI/CD pipeline.
  • Vulnerabilities exist when there is insufficient integrity verification for external components or modules like plugins, libraries, and modules.
  • This occurs when an application stores user-provided data on the client side and uses this data in critical business logic without proper integrity validation. (e.g., shopping cart price information can be manipulated on the client side).
  • When relying on open-source software and external libraries, if integrity verification for these dependencies is not properly performed, the application can be exposed to backdoors or malicious code.

Prevention

  • Use digital signatures or other integrity verification mechanisms for software updates, critical data, libraries, and dependencies to prevent changes from untrusted sources.
  • Manage automatic update features carefully and include a process to validate the authenticity of updates.
  • Secure the CI/CD pipeline and perform integrity checks throughout the build and deployment processes. Track and review changes to all scripts and configuration files.
  • Always re-validate data that can be manipulated on the client side on the server side. This is especially critical for data important to business logic, such as prices, permissions, and quantities.
  • Use Software Composition Analysis (SCA) tools to identify and manage known vulnerabilities in open-source and third-party libraries.

Attack Scenarios

  • Scenario #1: Software Update Process Tampering A software vendor provides security updates, but there is a lack of integrity verification mechanisms (e.g., hash value checks, digital signature verification) for these updates. An attacker compromises the vendor’s website or update mirror to upload malicious update files, and users unknowingly download and install them. This allows the attacker to gain full control over the user’s system.

  • Scenario #2: CI/CD Pipeline Integrity Compromise A company’s CI/CD pipeline is not properly secured, allowing an attacker to tamper with scripts or configuration files within the pipeline. As a result, a version of the application containing malicious code is deployed to the production environment. The development team remains unaware of this tampering, and users end up using the compromised application.

  • Scenario #3: Client-Side Data Manipulation In an online store, a user attempts to manipulate the price of items in their shopping cart using client-side scripts to purchase them at a lower cost. If the server-side does not re-verify the integrity of this price information, the attacker could purchase items at a significantly lower price than intended.


A9:Security Logging and Monitoring Failures (was A10 - Insufficient Logging & Monitoring)

Description

Security Logging and Monitoring Failures occur when insufficient logging and monitoring are combined with a lack of integration with incident response. This allows attackers to further compromise systems, maintain persistence, pivot to more systems, and tamper with, extract, or destroy data. According to most breach studies, the average time to detect a breach is over 200 days, and breaches are typically detected by external parties rather than internal processes or monitoring.

  • Insufficient logging and monitoring are foundational to all significant security incidents. These vulnerabilities enable attackers to further compromise systems.
  • While logging too much unnecessary data is not ideal, critical events (e.g., login attempts, access control failures, data modifications) must be recorded.
  • If logs for important activities like login and failed login attempts are not monitored, or if there are no log messages for warnings and errors, or if API call logs for suspicious activities are not monitored, the system can be exposed to these vulnerabilities.
  • If logs are stored only locally, and logging or alert events can be visible to users or attackers (e.g., error logs directly displayed on a web page), then this vulnerability exists.

Prevention

  • Log all suspicious or malicious account activities, including all logins, access control failures, and server-side input validation failures, to enable identification of such accounts.
  • Ensure logs are generated in a format that can be easily used by a centralized log management solution (e.g., SIEM) to implement security measures.
  • Logs should contain sufficient contextual information (e.g., timestamp, user ID, source IP address, requested URL).
  • Protect log integrity. Prevent attackers from modifying or deleting logs (e.g., using WORM storage, hash chains).
  • Establish near real-time monitoring and alerting systems to receive immediate notifications when suspicious activities occur.
  • Regularly analyze log data to identify patterns and detect abnormal activities.
  • Develop an Incident Response Plan and integrate logging and monitoring systems into this plan.

Attack Scenarios

  • Scenario #1: Persistent Attack Undetected Due to Lack of Logging An application has an SQL injection vulnerability, which an attacker exploits to access the database and extract sensitive information. However, the application server’s logs lack records of SQL query failures or abnormal database access, or relevant alerts are not configured. Consequently, the attacker can continue to exfiltrate data from the system for months without being detected.

  • Scenario #2: Information Leakage and System Reconnaissance via Error Logs A web server stores detailed error logs in a publicly accessible directory or displays them directly to users. An attacker obtains sensitive system information, such as database connection strings, internal IP addresses, and vulnerable library versions, by examining these logs. This information can then be used as a springboard for further attacks.

  • Scenario #3: Account Compromise Unnoticed Due to Insufficient Monitoring An attacker performs numerous login attempts on user accounts through a credential stuffing attack. However, there is no monitoring or threshold setting for failed login attempts, so the abnormal login attempts go undetected. Eventually, the attacker finds a valid user account and successfully logs in, but the system administrator remains unaware of the compromise.


A10:Server-Side Request Forgery (SSRF) (New)

Description

Server-Side Request Forgery (SSRF) is a vulnerability that occurs when an application fetches external resources (external servers or internal networks) without properly validating user-supplied URLs. This allows an attacker to force the vulnerable application to send manipulated requests to an unexpected destination, even if those systems are protected by firewalls, VPNs, or other types of network access control lists (ACLs).

  • Modern web applications commonly feature URL fetching scenarios (e.g., fetching images from URLs, importing remote files) to provide convenient functionality to end-users. As a result, SSRF vulnerabilities have increased. The complexity of cloud-based architectures will further contribute to the rise of this vulnerability.

Prevention

The approach to defending against SSRF attacks can be divided into network layer and application layer strategies.

  • From Network Layer

    • To reduce the impact of SSRF, separate remote resource access functionalities in separate networks. (e.g., place a proxy server for external resource access in a dedicated network segment).
    • Set the default policy for firewalls and network access to ‘deny’ and only allow essential intranet traffic.
    • Log all network flows on the firewall.
  • From Application Layer

    • Sanitize and validate input data received from the client.
    • Enforce URL schemes, ports, and destinations using a Positive Allow List. That is, explicitly specify only the URLs that are allowed, and block all others.
    • Do not directly provide raw responses to the client. (e.g., instead of returning the fetched content directly to the user, the application should parse the content and filter only necessary information before providing it).
    • Disable HTTP redirection. (Automatic redirections can be exploited in SSRF attacks).
    • Do not use Deny Lists or regular expressions for SSRF mitigation. Attackers already have tools, techniques, and payloads that can bypass them. (e.g., filtering localhost can be bypassed with 127.0.0.1 or 0.0.0.0).
  • Additional Measures to Consider:

    • Security-related services like OpenID should not be deployed on front systems. Control over these systems should be local.
    • For frontends with dedicated and manageable user groups, network encryption should be used in isolated systems that require high protection, such as VPNs.

Attack Scenarios

Attackers can exploit the following scenarios to target systems protected by firewalls or network ACLs:

  • Scenario #1: Internal Server Port Scanning If the network structure is not segmented, an attacker can use an SSRF vulnerability to attempt port scans on the internal network. By analyzing the server’s response times (connection success/failure, connection refused), the attacker can discover which internal ports are open. Example: http://example.com/api/get_data?url=http://192.168.1.1:22 (SSH port scan)

  • Scenario #2: Sensitive Data Exposure If an attacker can access internal resources like file:///etc/passwd or http://localhost:28017 (default MongoDB port), they can exfiltrate sensitive system files or internal service information. For example, file:///etc/passwd contains user information on Linux systems.

  • Scenario #3: Cloud Service Metadata Storage Access Most cloud service providers (AWS, Azure, GCP, etc.) offer metadata services like http://169.254.169.254. An attacker can access this metadata storage via SSRF to steal sensitive data such as cloud instance credentials or API keys.

  • Scenario #4: Internal Service Compromise and Remote Code Execution An attacker can exploit SSRF to misuse internal services (e.g., internal APIs, admin consoles) and execute attacks such as Remote Code Execution (RCE) or Denial of Service (DoS). For example, an attacker could chain SSRF with a vulnerability in an internal admin console.


2021 Top 10 Web Application Security Risks

A1:Broken Access Control (was A5)

Description

접근 통제(Access Control)는 사용자가 의도된 권한 범위 내에서만 행동할 수 있도록 정책을 강제하는 보안 메커니즘입니다. 접근 통제 실패는 주로 인가되지 않은 정보 노출, 데이터 수정 또는 파괴, 혹은 사용자의 권한을 벗어난 비즈니스 기능 수행으로 이어집니다. 이는 다음과 같은 예시에서 발생할 수 있습니다.

  • 사용자가 예상치 못한 방식으로 시스템의 기능을 조작할 수 있을 때 발생하는 문제입니다. 특히 특정 사용자나 역할(role)에만 접근이 허용되어야 하는 리소스에 기본적으로 ‘허용(allow)’ 설정이 되어 있거나, ‘거부(deny)’ 규칙이 제대로 설정되지 않았을 때 취약점이 발생합니다.
  • URL을 수정하여 다른 계정의 정보를 열람하거나, 공격 도구를 사용하여 API 요청을 변조하여 접근 통제를 우회할 수 있을 때입니다.
  • API에 대한 POST, PUT, DELETE 등의 HTTP 메소드에 대한 적절한 접근 통제가 없을 때 발생합니다.
  • 로그인하지 않은 상태에서도 일반 사용자(user)처럼 활동하거나, 일반 사용자 권한으로 로그인했음에도 관리자(admin) 기능에 접근 가능한 경우입니다.
  • Access control token으로 사용되는 JWT(JSON Web Token)를 재사용(replaying)하거나 변조(tampering)하는 경우, 또는 쿠키나 숨겨진(hidden) 필드를 조작하여 권한 상승(privilege escalation)을 시도하는 경우입니다.
  • CORS(Cross-Origin Resource Sharing) 설정 오류(misconfiguration)가 인가되지 않은 API 접근을 허용할 때 발생합니다.
  • 인증되지 않은 사용자가 강제 브라우징(force Browse)을 통해 접근이 허용되지 않은 리소스에 접근할 수 있을 때입니다.

Prevention

접근 통제는 공격자가 접근 통제 검사나 메타데이터를 수정할 수 없도록 신뢰할 수 있는 서버 측 코드 또는 서버리스(server-less) API에서만 효과적으로 적용되어야 합니다.

  • 공개 리소스를 제외한 모든 리소스는 기본적으로 ‘거부(deny)’해야 합니다. 즉, deny-by-default 원칙을 적용합니다.
  • CORS 사용을 최소화하는 방향으로 메커니즘을 구현해야 합니다. 필요한 경우에만 최소한의 출처(origin)를 허용하는 화이트리스트 방식을 사용합니다.
  • 접근 통제 모델은 사용자에게 특정 레코드를 생성/열람/수정/삭제할 수 있는 권한을 허용하기보다는 레코드 소유자만 권한을 갖도록 강제 설정해야 합니다.
  • 비즈니스 애플리케이션의 경우 도메인 모델(Domain Model)에 의해 특정 요구 사항을 제한해야 합니다. (예: 구매 수량 제한, 특정 기간 내 구매 횟수 제한 등)
  • 웹 서버상의 디렉토리 리스팅 기능을 비활성화하고, .git과 같은 메타데이터 파일이나 백업 파일들이 웹 루트(web root)에 존재하지 않도록 운영해야 합니다.
  • 접근 통제 실패, 경고 등에 관한 적절한 로깅(logging)을 구현해야 합니다. 이를 통해 의심스러운 활동을 감지하고 대응할 수 있습니다.
  • 공격 도구가 접근 통제에 관한 API 호출을 함부로 할 수 없을 정도로 적절한 요청 속도 제한(rate limit)을 적용해야 합니다.
  • JWT는 로그아웃 이후 즉시 무효화되어야 하며, 짧은 유효 기간을 설정하는 것이 좋습니다.

Attack Scenarios

  • Scenario #1: 인가되지 않은 계정 정보 접근 애플리케이션이 계정 정보를 조회하는 SQL 쿼리에서 사용자가 제공하는 acct 파라미터를 제대로 검증하지 않는 코드를 사용합니다. 공격자는 https://example.com/app/accountInfo?acct=notmyacct와 같이 acct 파라미터를 쉽게 수정하여 다른 사용자의 계정 정보를 요청할 수 있습니다. 서버의 코드가 다음과 같다면 취약합니다.

    1
    2
    
    pstmt.setString(1, request.getParameter("acct")); // 입력값을 검증 없이 사용
    ResultSet results = pstmt.executeQuery();
    

    이 경우, SQL 인젝션은 아니지만 acct 파라미터에 대한 인가(authorization) 검증이 누락되어 발생하는 접근 통제 문제입니다.

  • Scenario #2: 강제 브라우징을 통한 관리자 페이지 접근 공격자가 간단하게 대상 URL을 강제 브라우징합니다. 예를 들어, 일반 사용자 계정으로 로그인한 상태에서 관리자 전용 페이지인 https://example.com/app/admin_getappInfo에 접속을 시도했을 때, 관리자 권한이 없음에도 불구하고 페이지에 접근이 가능하다면 이는 접근 통제 취약점에 해당합니다.

    1
    2
    
    https://example.com/app/getappInfo
    https://example.com/app/admin_getappInfo // 관리자 권한이 없는데도 접근 가능
    

A2:Cryptographic Failures (was A3 - Sensitive Data Exposure)

Description

암호화 실패(Cryptographic Failures)는 민감한 데이터가 전송 중이거나 저장되어 있을 때 제대로 보호되지 않아 발생하는 문제입니다. 이 취약점은 이전의 ‘민감한 데이터 노출(Sensitive Data Exposure)’ 취약점과 밀접하게 관련되어 있으며, 특히 데이터의 보호 요구사항을 제대로 파악하지 못했을 때 발생합니다. 예를 들어 비밀번호, 신용카드 번호, 건강 기록, 개인 정보, 영업 비밀과 같은 데이터는 특히 EU의 GDPR(General Data Protection Regulation)이나 PCI DSS(Payment Card Industry Data Security Standard)와 같은 개인 정보 보호 법규나 규정의 적용을 받는 경우 추가적인 보호가 필수적입니다.

다음과 같은 상황에서 취약점이 존재할 수 있습니다.

  • 어떤 데이터라도 평문(clear text)으로 전송되고 있지는 않은지? 암호화가 되어 있지 않은 HTTP, SMTP, FTP와 같은 프로토콜을 사용하고 있지는 않은지 확인해야 합니다.
  • 기본값이나 이전 코드에서 오래되거나 약한 암호화 알고리즘 또는 프로토콜을 사용하고 있지는 않은지?
  • 기본 암호화 키가 약한 난수 생성기에서 만들어졌거나 재사용되지는 않는지? 키 관리는 제대로 이루어지고 있는지? 소스 코드 저장소에 암호화 키가 노출되어 있지는 않은지?
  • 서버 측 인증서 확인이나 신뢰 체인(trust chain)이 제대로 유효성을 검사하고 있는지?
  • 초기화 벡터(Initialization Vector, IV)가 사용되지 않거나 재사용되거나 안전하지 않은 방법으로 생성되어 적절한 암호화 작업에 사용되고 있지 않은지? ECB(Electronic Codebook)와 같이 안전하지 않은 운용 모드(mode of operation)를 사용하고 있지 않은지 확실한지?
  • MD5 또는 SHA1과 같이 더 이상 사용되지 않거나(deprecated) 안전하지 않은 해시 함수, 또는 암호학적으로 안전하지 않은 해시 함수를 사용하고 있지는 않는지?
  • PCKS number 1 v1.5와 같이 더 이상 사용되지 않는 암호화 패딩(padding) 방법을 사용하고 있지는 않는지?
  • 패딩 오라클 공격(Padding Oracle Attacks)과 같은 형태의 암호화 오류 메시지나 부채널 정보(side channel information)가 악용될 가능성이 있지는 않은지?

Prevention

데이터를 보호함에 있어 우선적으로 고려해야 할 것은 데이터가 처리되는지, 저장되는지, 전송되는지 분류하고, 어떤 데이터가 개인 정보 보호 법규, 규제 사항, 또는 비즈니스 니즈에 의해 중요한 데이터로 분류되는지 먼저 파악해야 합니다.

  • 민감한 데이터는 필요하지 않다면 저장하지 마십시오. 흔적이 없는 데이터는 훔쳐질 수 없습니다. 필요 없는 데이터는 빨리 폐기하십시오.
  • 민감한 데이터는 반드시 암호화되었는지 확인해야 합니다.
  • 최신의 표준 알고리즘, 프로토콜, 키를 사용하는지 확인하고, 키 관리를 제대로 해야 합니다. 키는 안전하게 보관하고 접근을 제한해야 합니다.
  • TLS(Transport Layer Security)와 같은 암호화 프로토콜로 데이터를 전송하고, HTTP Strict Transport Security(HSTS)와 같은 지시문을 사용하여 암호화를 강제해야 합니다.
  • 민감한 데이터를 포함한 응답을 캐시하는 것을 비활성화해야 합니다.
  • FTP, SMTP와 같은 레거시(legacy) 프로토콜을 사용하여 민감한 자료를 전송하지 마십시오.
  • 암호(password)에는 PBKDF2, bcrypt, scrypt, Argon2와 같은 강력한 솔티드(salted) 해시 함수를 사용해야 합니다.
  • CSPRNG(Cryptographically Secure Pseudo Random Number Generator)와 같은 것을 사용하여 적절한 IV를 선택해야 합니다. 그리고 IV는 두 번 이상 재사용하면 안 됩니다.
  • 단순한 암호화(encryption)가 아니라 인증된 암호화(authenticated encryption)를 사용해야 합니다. 이는 데이터의 기밀성뿐만 아니라 무결성도 보장합니다.

Attack Scenarios

  • Scenario #1: 저장된 데이터의 전송 중 노출 애플리케이션이 카드 정보를 자동으로 암호화해주는 데이터베이스를 사용합니다. 이 데이터는 검색 시 자동으로 해독되어 SQL 인젝션 취약점으로 인해 평문 상태로 해당 카드 정보를 탈취당할 수 있습니다. 이 경우는 저장 시에는 암호화가 안전하지만 전송 과정에서 암호화가 제대로 이루어지고 있지 않는 것입니다.

  • Scenario #2: TLS 다운그레이드를 통한 세션 탈취 TLS 사용을 강제하지 않는 웹사이트에서 공격자가 HTTPS를 HTTP로 다운그레이드 공격(예: SSL Stripping)을 수행한 다음, 사용자의 쿠키를 훔칩니다. 이후 공격자는 훔친 쿠키로 사용자의 세션을 탈취하여 사용자의 개인 정보를 변경할 수 있습니다. 특히 금융 관련 데이터와 같이 중요한 정보인 경우, 공격자는 수치를 변조하여 데이터를 전송할 수 있게 됩니다.

  • Scenario #3: 약한 암호 해시와 무차별 대입 공격 암호 데이터베이스가 솔트(salt)를 사용하지 않는다면, 파일 업로드 취약점 등을 통해 공격자가 암호 데이터베이스 정보를 탈취(retrieve)할 수 있습니다. 이후 공격자는 레인보우 테이블 공격(Rainbow Table Attack)이나 무차별 대입 공격(Brute-force Attack)을 통해 암호를 쉽게 복호화할 수 있을 것입니다.


A3:Injection (was A1 - Injection)

Description

인젝션(Injection) 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 명령어(command)나 쿼리(query)의 일부로 해석하여 실행할 때 발생합니다. 이는 공격자가 의도하지 않은 명령을 실행하거나 데이터에 접근, 수정, 삭제할 수 있도록 허용합니다.

다음과 같은 경우에 취약점이 존재합니다.

  • 사용자로부터 제공된 데이터가 유효성 검사(validate), 필터링(filter), 혹은 안전하게 처리되지(sanitized) 않을 때 발생합니다.
  • 컨텍스트 인식(context-aware) 이스케이프(escaping)가 없는 동적 쿼리(dynamic queries)매개변수화되지 않은(non-parameterized) 호출이 인터프리터(interpreter)에서 직접 실행될 때 취약합니다.
  • 악의적인(hostile) 데이터가 객체-관계 매핑(ORM, Object-Relational Mapping) 검색 매개변수에 추가되어 민감한 자료를 추출할 때입니다.
  • 악의적인 데이터가 직접적으로 사용되거나 문자열 연결(concatenated)될 때 발생합니다.
  • 가장 흔한 인젝션 공격으로는 SQL 인젝션, NoSQL 인젝션, OS 명령어 인젝션, ORM 인젝션, LDAP 인젝션, Expression Language(EL) 또는 Object Graph Navigation Library(OGNL) 인젝션 등이 있습니다.
  • 소스 코드 리뷰는 인젝션 취약점을 찾기에 가장 좋은 방법 중 하나이며, 자동화된 도구는 모든 매개변수, 헤더, URL, 쿠키, JSON, SOAP, XML 데이터 입력을 반드시 확인해야 합니다.
  • 기업들은 제품 출시 전 인젝션 취약점을 탐지하기 위해 SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing), IAST(Interactive Application Security Testing)와 같은 테스팅 도구들을 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인에 통합할 수 있습니다.

Prevention

인젝션 공격을 방어하는 데 있어 가장 중요한 것은 데이터와 명령어/쿼리를 분리하는 것입니다.

  • 안전한 API를 사용합니다. 예를 들어, SQL 쿼리에서는 매개변수화된 쿼리(Parameterized Query)를 사용하고, OS 명령어 실행 시에는 안전한 API를 통해 인자(argument)를 전달합니다.
  • 화이트리스트(whitelist) 기반의 서버 측 입력 유효성 검사(server-side input validation)를 사용합니다. 이는 완벽한 방어법은 아니지만, 추가적인 방어 계층을 제공합니다. 블랙리스트(blacklist) 방식은 우회될 가능성이 높으므로 피해야 합니다.
  • 특정 이스케이프 구문(escape syntax)을 사용하여 특수 문자를 이스케이프하는 동적 쿼리를 사용합니다. 이는 사용자 입력이 코드의 일부로 해석되지 않도록 합니다.
  • LIMIT 또는 다른 SQL 제어문을 사용하여 SQL 인젝션으로 인해 많은 자료가 노출되는 것을 방지합니다. (예: 반환되는 레코드 수를 제한)

Attack Scenarios

아래 두 가지 시나리오는 다음과 같은 형태의 공격에 모두 적용될 수 있습니다.

1
http://example.com/app/accountView?id=' or '1'='1
  • Scenario #1: 신뢰할 수 없는 데이터를 그대로 사용하는 경우 (SQL Injection) 애플리케이션이 사용자로부터 받은 id 파라미터를 SQL 쿼리 문자열에 직접 연결하는 경우 취약합니다.

    1
    
    String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
    

    공격자가 id=' or '1'='1을 입력하면 쿼리는 SELECT * FROM accounts WHERE custID='' or '1'='1'이 되어 모든 계정 정보를 반환할 수 있습니다.

  • Scenario #2: ORM (Object-Relational Mapping) 인젝션 유사하게, 애플리케이션이 ORM 프레임워크를 사용하면서 사용자 입력을 createQuery 메소드에 직접 전달하는 경우 블라인드 신뢰(blind trust) 문제가 발생합니다.

    1
    
    Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
    

    이 경우에도 공격자는 id 파라미터를 조작하여 의도하지 않은 쿼리를 실행하거나 데이터를 추출할 수 있습니다.


A4:Insecure Design (New)

Description

안전하지 않은 설계(Insecure Design)는 단순히 통제가 누락되었거나 비효율적인 통제 설계를 의미하는 것을 넘어, 근본적으로 특정 공격에 대해 방어할 수 없도록 설계된 것을 말합니다. 이는 안전하지 않은 구현(insecure implementation)과는 다릅니다.

안전하지 않은 디자인은 애초에 소프트웨어나 시스템을 만들 때 어느 정도 수준의 보안을 고려해야 할지 제대로 생각하지 않고, 해당 비즈니스의 특성을 제대로 파악하지 못했기 때문에 발생하는 문제점입니다.

  • 요구사항 및 자원 관리 (Requirements and Resource Management): 애플리케이션에 대한 비즈니스 요구사항을 수집하고 협상해야 합니다. 여기에는 모든 데이터에 대한 기밀성(confidentiality), 무결성(integrity), 가용성(availability), 그리고 인증(authenticity)이 모두 포함되어야 합니다. 기능적 및 비기능적 보안 요구사항(Functional and non-functional security requirements)을 포함하여, 보안 활동을 포함한 모든 디자인, 빌드, 테스팅, 작동에 관한 예산을 계획해야 합니다.
  • 보안 설계 (Secure Design): 보안 설계는 끊임없이 위협을 평가하고 테스트하며, 알려진 공격을 막는 코드를 보장할 수 있도록 하는 문화이자 방법론입니다. 위협 모델링(Threat Modeling)은 설계 개선 세션(refinement sessions)에 포함되어야 하며, 사용자 스토리(user story) 개발에서 취약할 수 있는 부분들에 대해 논의되어야 합니다. 적절한 행동에 대한 고려 조건들을 어떻게 유효성 검사할 것인지 정하고, 사용자 스토리에 대한 결과를 문서화해야 합니다. 보안 설계는 단순히 도구를 추가하거나 나중에 덧붙이는 것이 아니라 프로젝트 시작부터 진행되어야 하는 것입니다.
  • 보안 개발 수명 주기 (Secure Development Lifecycle): 안전한 소프트웨어는 보안 개발 수명 주기(SDLC), 보안 설계 패턴, 보안 컴포넌트 라이브러리, 도구, 그리고 위협 모델링 등을 요구합니다. 전체 프로젝트 및 소프트웨어 유지보수에 관한 시작을 할 때 보안 전문가와 함께 하는 것이 좋습니다.

Prevention

  • 안전한 개발 수명 주기(Secure Development Lifecycle)를 구축하는 것이 좋으며, 개인 정보 보호 관련 통제, 설계 보안 등을 평가하는 데 도움이 될 전문가와 함께 하는 것이 좋습니다.
  • 핵심 인증, 접근 통제, 비즈니스 로직, 주요 흐름에 관한 위협 모델링을 수행합니다.
  • 사용자 스토리 안에 보안 언어와 통제를 통합하여 구성합니다. 예를 들어, “사용자는 민감한 데이터를 입력할 때 반드시 암호화된 연결을 사용해야 한다”와 같이 보안 요구사항을 명확히 합니다.
  • 모든 핵심 흐름을 유효성 검사할 수 있는 단위(unit) 및 통합(integration) 테스트를 작성합니다.
  • 모든 계층(tier)에서 위험이 될 만한 네트워크 및 시스템 계층을 분리(segregate)합니다. (예: 데이터베이스 서버와 웹 서버를 다른 네트워크 세그먼트에 배치)
  • 사용자나 서비스에 의해 사용될 수 있는 소모(consumption)를 제한합니다. (예: API 호출 속도 제한, 리소스 사용량 제한)

Attack Scenarios

  • Scenario #1: 안전하지 않은 자격 증명 복구 워크플로우 자격 증명 복구(credential recovery) 워크플로우에 질문/답변 방식의 플로우가 포함될 수 있습니다. 만약 이 시스템이 한 명 이상의 사용자가 같은 답변으로 자격 증명을 할 수 있도록 허용한다면, 공격자가 답을 쉽게 알아내어 다른 사용자의 계정에 접근할 수 있을 것입니다. 이러한 코드는 애초에 안전한 디자인에서 제거되었어야 합니다.

  • Scenario #2: 비즈니스 로직 취약점을 이용한 대량 예약 영화관 웹사이트에서 최대 15명까지만 예약할 수 있으며, 그룹 예약 시 할인을 제공한다고 가정합니다. 공격자는 이 비즈니스 로직에 대한 위협 모델을 구현하여 600석을 예약하는 것을 시도할 것입니다. 만약 시스템이 이러한 비정상적인 예약 시도를 막지 못한다면, 이는 영화관에 거대한 손실을 가져다줄 것입니다. 이는 구현상의 버그가 아닌, 설계 단계에서 이러한 위협을 고려하지 않았기 때문에 발생하는 문제입니다.

  • Scenario #3: 봇에 의한 경매 조작 전자상거래 경매 웹사이트에서 봇(bot)에 대한 방어(예: CAPTCHA, 비정상적인 활동 감지)가 제대로 되어 있지 않다면, 악의적인 해커는 봇을 사용하여 경매 가격을 비정상적으로 높이거나, 허위 구매를 통해 다른 사용자에게 피해를 줄 수 있습니다. 이는 시스템의 디자인이 봇 공격에 취약하게 되어 있기 때문입니다.


A5:Security Misconfiguration (was A6 - Security Misconfiguration)

Description

보안 설정 오류(Security Misconfiguration)는 보안 기능이 의도치 않게 비활성화되거나, 안전하지 않은 기본 설정이 유지되거나, 불필요한 기능이 활성화되어 발생하는 취약점입니다. 이는 애플리케이션 스택의 모든 계층에서 발생할 수 있습니다.

다음과 같은 경우에 취약점이 발생합니다.

  • 애플리케이션 스택의 어떤 부분에서든 적절한 보안 강화(hardening)가 누락되었거나, 클라우드 서비스에 대한 권한 설정이 부적절하게 되었을 때 발생합니다.
  • 불필요한 기능(불필요한 포트, 서비스, 페이지, 계정 등)들을 가능하게 했거나 설치했을 때 취약해집니다.
  • 기본 계정(default account)과 그에 대한 비밀번호가 변경되지 않았거나 그대로일 때 발생합니다.
  • 사용자에게 에러 핸들링이나 에러 이상의 정보(예: 스택 트레이스, 컴포넌트 버전 정보)가 보여질 때 발생합니다.
  • 업그레이드된 시스템에 대해 최신 보안 기능이 비활성화되었거나 안전하게 설정되어 있지 않을 때 발생합니다.
  • 애플리케이션 서버, 프레임워크, 라이브러리, 데이터베이스 등 그 속의 보안 설정이 보안에 취약한 값으로 설정되어 있을 때 발생합니다.
  • 서버가 안전한 헤더(예: Content-Security-Policy, X-Content-Type-Options)나 지시문(directives)을 보내지 않거나, 그들이 안전한 값으로 설정되어 있지 않았을 때 발생합니다.
  • 소프트웨어가 구식이거나(outdated) 알려진 취약점을 포함하고 있을 때 발생합니다.
  • 일관되고 반복 가능한 보안 구성 프로세스가 없으면 시스템은 매우 위험에 노출됩니다.

Prevention

  • 반복 가능한 보안 강화 프로세스(hardening process)를 만들어 빠르고 쉽게 다른 환경에 배포할 수 있게 만듭니다. 개발, QA, 프로덕션 환경은 모두 동일한 설정 값으로 되어 있어야 하며, 각자에 맞는 서로 다른 인증서를 사용해야 합니다. 이러한 프로세스는 가능하면 자동화되어야 하며, 자동화를 통해 새로운 보안 환경을 설치하는 데 드는 비용이 최소화되어야 합니다.
  • 불필요한 것은 제거하거나 설치하지 않습니다. 최소한의 플랫폼으로 만드십시오.
  • 모든 보안 노트, 업데이트, 그리고 패치에 관한 적절한 구성(configurations)을 검토하고 업데이트하는 작업을 구현합니다. 또한 클라우드 저장소 권한에 대해서도 주기적으로 검토합니다.
  • 분할된 애플리케이션 아키텍처(segmented application architecture)는 구성 요소들이 효과적이고 안정적으로 작동할 수 있게 해줍니다. (예: 웹 서버, 애플리케이션 서버, 데이터베이스 서버를 논리적/물리적으로 분리)
  • 보안 헤더(Security Headers)와 같이, 보안 지시문(security directives)을 클라이언트에게 보내는 로직을 구성합니다.
  • 모든 환경에서 효과적으로 각 설정 값을 검증하는 자동화 프로세스를 구축합니다.

Attack Scenarios

  • Scenario #1: 제거되지 않은 샘플 애플리케이션 및 기본 계정 프로덕션 서버에 제거되지 않은 샘플 애플리케이션과 함께 애플리케이션 서버가 동작합니다. 이 샘플 애플리케이션은 보안 취약점이 있는 것으로 알려져 있고, 공격자는 그것을 이용해 서버를 침해합니다. 만약 이 애플리케이션이 관리자 콘솔이고 기본 계정(default account)과 비밀번호가 변경되지 않았다면, 공격자는 기본 비밀번호로 시스템을 완전히 장악(take over)할 것입니다.

  • Scenario #2: 디렉토리 리스팅 허용 및 코드 역분석 디렉토리 리스팅(Directory listing) 기능이 서버에서 비활성화되지 않았습니다. 공격자가 쉽게 서버의 디렉토리를 탐색할 수 있게 됩니다. 공격자는 컴파일된 자바 클래스 파일을 찾아 다운로드할 것이고, 이를 디컴파일하여 코드를 역분석(reverse engineer)할 것입니다. 공격자는 이를 통해 취약한 접근 통제 결함(access control flaw)을 발견하여 공격할 것입니다.

  • Scenario #3: 상세한 에러 메시지를 통한 정보 노출 애플리케이션 서버가 너무 상세한 에러 메시지(detailed error message)를 사용자에게 노출한다면, 이는 컴포넌트 버전이나 내부 구조에 대한 정보를 드러내어 공격자가 취약점을 식별하고 공격하기 쉽게 만들 것입니다.

  • Scenario #4: 클라우드 서비스 설정 오류로 인한 민감 데이터 탈취 클라우드 서비스 공급자가 Content Security Policy(CSP) 헤더를 사용자에게 권한을 오픈할 수 있도록 기본값으로 설정해 놓았다면, 클라우드 내의 저장소에 접근을 가능하게 만들어 민감한 데이터가 탈취당할 수 있습니다. (예: S3 버킷에 대한 Public Read/Write 권한 설정)


A6:Vulnerable and Outdated Components (was A9 - Using Components with Known Vulnerabilities)

Description

취약하고 오래된 컴포넌트(Vulnerable and Outdated Components) 취약점은 애플리케이션이 사용하는 라이브러리, 프레임워크, 그리고 다른 소프트웨어 컴포넌트에 알려진 취약점이 있음에도 불구하고 업데이트되지 않거나 적절하게 패치되지 않았을 때 발생합니다. 공격자들은 이러한 취약점을 악용하여 애플리케이션을 침해할 수 있습니다.

다음의 경우 이 취약점이 존재합니다.

  • 서버 측과 클라이언트 측 모두에서 사용되고 있는 모든 컴포넌트에 관한 버전을 모를 때 취약합니다.
  • 소프트웨어가 취약하거나, 더 이상 지원되지 않거나(End-of-Life), 구식(out of date)일 때 취약합니다. 특히 OS, 애플리케이션 서버, DBMS, API, 라이브러리, 런타임 환경 등 모든 컴포넌트가 이에 해당합니다.
  • 취약점을 정기적으로 스캔하지 않거나, 자신이 사용하고 있는 컴포넌트에 관한 새로운 보안 뉴스(예: CVE)를 접하지 않을 때 발생합니다.
  • 위험이 있는 프레임워크나 플랫폼과 같은 것들을 업그레이드하지 않거나 고치지 않을 때 발생합니다. 흔히 이런 일들은 한 달에 한 번 또는 분기마다 패치를 하고 매달 첫째 날에만 고치는 방식이라면 더 자주 발생할 수 있습니다. (즉, 보안 패치 주기가 너무 느리거나 불규칙할 때)
  • 소프트웨어 개발자가 새로 업그레이드된 라이브러리에 관한 테스트를 하지 않을 때 발생합니다. (업데이트 후 호환성 문제 등으로 인해 업데이트를 꺼리게 됨)
  • 각 컴포넌트의 구성(configuration)을 안전하게 하지 않았을 때 발생합니다.

Prevention

  • 사용하지 않는 기능(features), 종속성(dependencies), 컴포넌트, 파일 및 문서는 모두 제거합니다. 최소한의 필요한 것만 유지하십시오.
  • CVE(Common Vulnerabilities and Exposures), NVD(National Vulnerability Database)와 같은 데이터베이스를 지속적으로 모니터링하면서 관련된 컴포넌트의 취약점에 대한 뉴스를 계속 주시합니다. 만약 사용하고 있는 컴포넌트에 관한 취약점이 나왔을 때 이메일 알림을 구독하는 것을 고려합니다.
  • 공식적인(Official) 소스에서 안전한 링크를 통해 컴포넌트를 구합니다. 최대한 악성 코드가 포함될 가능성이 있는 경로로는 컴포넌트를 구하지 않도록 주의합니다.
  • 유지 보수가 되고 있지 않거나 보안 패치가 되지 않는 라이브러리 및 컴포넌트를 모니터링하고, 패치가 불가능할 때는 알려진 취약점에 대해 조치를 취할 수 있는 가상 패치(Virtual Patching)를 고려해야 합니다.
  • 모든 조직은 애플리케이션 수명 주기 동안 모니터링, 업데이트 확인 및 구성 변경을 끊임없이 수행해야 합니다.

Attack Scenarios

  • Scenario #1: 취약한 컴포넌트를 통한 시스템 침해 컴포넌트들은 주로 애플리케이션과 동일한 권한으로 실행됩니다. 따라서 어떤 컴포넌트라도 취약점이 생기면 심각한 문제를 초래할 수 있습니다. 예를 들어, 웹 서버에서 사용되는 특정 라이브러리에 원격 코드 실행(RCE) 취약점이 발견되면, 공격자는 이 취약점을 통해 서버를 완전히 장악할 수 있습니다. IoT 장치의 경우 주기적인 패치가 어렵거나 불가능할 수 있지만, 생체 의료 기기와 같은 경우 패치가 반드시 중요합니다. 패치 부재는 심각한 인명 피해나 개인 정보 유출로 이어질 수 있습니다.

A7:Identification and Authentication Failures (was A2 - Broken Authentication)

Description

식별 및 인증 실패(Identification and Authentication Failures)는 사용자, 시스템, 또는 서비스의 신원(identity), 인증(authentication), 그리고 세션 관리(session management) 기능이 제대로 구현되지 않아 발생하는 취약점입니다. 이는 인증 관련 공격으로부터 보호하는 데 매우 중요한 부분입니다.

다음과 같은 부분에 취약점들이 존재하게 됩니다.

  • Credential stuffing(크리덴셜 스터핑)과 같은 자동화 공격을 허용할 때 발생합니다. - 다른 사이트에서 얻은 계정 정보를 무차별적으로 입력하는 공격 기법
  • admin/admin과 같이 약하고 잘 알려진 기본 설정값(default credentials)을 허용할 때 발생합니다.
  • 지식 기반 답변(knowledge-based answer)과 같이 안전하지 않은 방식으로 복구(recovery) 및 비밀번호 찾기(forgot-password) 프로세스를 사용할 때 발생합니다. (예: “어머니 성함은?”, “졸업한 초등학교 이름은?” 등의 질문)
  • 평문으로 비밀번호를 저장하거나 전송하거나, 약한 암호화 알고리즘을 사용하여 비밀번호를 보호할 때 취약합니다.
  • MFA(Multi-Factor Authentication, 다단계 인증)가 불충분하거나 사용되지 않을 때 자동화된 공격에 취약해집니다.
  • URL에 세션 정보가 그대로 노출될 때 (예: jsessionid가 URL 파라미터로 노출) 세션 하이재킹에 취약해집니다.
  • 로그인 성공 이후 세션 식별자(session identifier)가 재사용 가능할 때 (Session Fixation 공격에 취약)
  • 세션 ID가 제대로 무효화되지 않거나(invalidate), 로그아웃이나 일정 시간(timeout) 이후에도 SSO(Single Sign-On) 토큰과 같은 인증 토큰이 제대로 무효화되지 않을 때 세션 하이재킹 공격에 취약해집니다.

Prevention

  • 가능하면 MFA를 사용하여 자동화된 공격이나 탈취된 자격 증명 재사용 공격을 막습니다.
  • 관리자 계정에 관한 것들은 기본값을 사용하지 않은 채로 배포(ship or deploy)해야 합니다. 즉, 배포 시에는 기본 비밀번호를 변경하도록 강제하거나, 사용자 생성 시 강력한 비밀번호를 요구해야 합니다.
  • 약한 비밀번호를 체크하고, 상위 10,000개의 가장 안 좋은 비밀번호 목록에 들어간 비밀번호는 허용하지 않도록 구현합니다. 비밀번호 강도 측정기를 제공하는 것도 좋은 방법입니다.
  • 비밀번호 길이, 복잡성, 순환(rotation) 정책을 적절히 설정합니다. (예: 최소 12자 이상, 대문자/소문자/숫자/특수문자 조합, 90일마다 변경)
  • 접속 실패에 대한 기록을 남기고, 자동화된 공격이 먹히지 않도록 로그인 시도 횟수와 시간에 제한을 걸어놓고, 서비스 거부(DoS) 공격을 방지합니다. (예: N회 로그인 실패 시 계정 잠금, 쿨다운(cooldown) 시간 적용)
  • 로그인 이후에 높은 엔트로피(entropy)를 지닌 무작위 세션 ID를 생성하는 안전한 세션 관리자를 사용합니다. 세션에 관한 정보는 URL에 노출시키지 않고, 로그인 이후 또는 특정 시간 이후 무효화(invalidate)하게 합니다.

Attack Scenarios

  • Scenario #1: 크리덴셜 스터핑 공격 크리덴셜 스터핑은 흔한 공격법입니다. 이에 대한 방어책이 없다면, 해당 애플리케이션은 공격자들이 탈취한 자격 증명이 유효한지 아닌지 확인할 수 있는 채널로 사용될 수 있습니다. 공격자는 수많은 계정을 시도하며 유효한 계정을 찾아낼 수 있습니다.

  • Scenario #2: 약한 비밀번호 사용 대다수의 인증 공격은 사용자들이 약하거나 재사용하는 비밀번호 때문에 발생합니다. 따라서 MFA를 사용하거나, 시스템이 쉬운 비밀번호를 사용하지 못하도록 강력한 비밀번호 정책을 강제해야 합니다. 예를 들어, 'password123'과 같은 비밀번호를 허용하는 시스템은 무차별 대입 공격에 매우 취약합니다.

  • Scenario #3: 부적절한 세션 타임아웃 세션 타임아웃이 제대로 설정되지 않았을 때, 사용자가 공용 컴퓨터에서 로그인한 후 로그아웃하지 않고 단순히 브라우저 탭을 닫거나 컴퓨터를 떠나는 경우를 가정합니다. 공격자가 한 시간 뒤에 같은 컴퓨터를 사용하여 브라우저를 열면, 이전 사용자의 인증된 세션이 여전히 활성 상태여서 서비스를 이용할 수 있게 될 것입니다. 로그아웃 버튼을 누르지 않고 탭으로 닫았을 때에도 적절하게 세션 설정(예: 짧은 비활동 타임아웃)을 해주어야 합니다.


A8:Software and Data Integrity Failures (New)

Description

소프트웨어 및 데이터 무결성 실패(Software and Data Integrity Failures)는 소프트웨어 업데이트, 중요한 데이터, CI/CD 파이프라인, 그리고 중요 코드에 대한 무결성 검증이 부족하여 발생하는 취약점입니다. 이는 신뢰할 수 없는 데이터가 애플리케이션의 중요한 부분으로 흘러 들어가 악용될 때 발생합니다.

  • 신뢰할 수 없는 소스에서 가져온 소프트웨어 업데이트, 중요 데이터, 라이브러리, 의존성 등이 코드나 설정의 변경 없이 자동으로 실행되는 경우 취약합니다. 이는 CI/CD 파이프라인의 보안 부족으로 인해 발생할 수 있습니다.
  • 플러그인, 라이브러리, 모듈 등 외부에서 가져온 컴포넌트나 모듈에 대한 무결성 검증이 부족할 때 취약합니다.
  • 애플리케이션이 사용자로부터 제공된 데이터를 클라이언트에 저장하고, 이 데이터에 대한 무결성 검증 없이 중요한 비즈니스 로직에 사용할 때 발생합니다. (예: 쇼핑 카트의 가격 정보가 클라이언트 측에서 조작될 수 있는 경우)
  • 오픈 소스 소프트웨어 및 외부 라이브러리에 의존하는 경우, 이러한 종속성에 대한 무결성 검증이 제대로 이루어지지 않을 때 백도어(backdoor)나 악성 코드에 노출될 수 있습니다.

Prevention

  • 소프트웨어 업데이트, 중요 데이터, 라이브러리 및 종속성에 대해 디지털 서명(digital signatures) 또는 다른 무결성 검증 메커니즘을 사용하여, 신뢰할 수 없는 소스로부터의 변경을 방지합니다.
  • 자동 업데이트 기능은 신중하게 관리하고, 업데이트의 유효성을 검증하는 프로세스를 포함해야 합니다.
  • CI/CD 파이프라인을 보호하고, 빌드 및 배포 프로세스 전반에 걸쳐 무결성 검사를 수행합니다. 모든 스크립트와 설정 파일에 대한 변경 사항을 추적하고 검토합니다.
  • 클라이언트 측에서 조작될 수 있는 데이터를 서버 측에서 반드시 다시 검증합니다. 특히 가격, 권한, 수량 등 비즈니스 로직에 중요한 데이터는 서버에서 최종적으로 확인해야 합니다.
  • 소프트웨어 컴포넌트 분석(SCA) 도구를 사용하여 오픈 소스 및 써드파티 라이브러리의 알려진 취약점을 식별하고 관리합니다.

Attack Scenarios

  • Scenario #1: 소프트웨어 업데이트 프로세스 변조 소프트웨어 공급업체가 보안 업데이트를 제공하지만, 이 업데이트에 대한 무결성 검증(예: 해시 값 확인, 디지털 서명 검증) 메커니즘이 부족합니다. 공격자는 공급업체의 웹사이트나 업데이트 미러를 침해하여 악성 코드가 포함된 업데이트 파일을 업로드하고, 사용자들은 이를 아무런 의심 없이 다운로드하여 설치하게 됩니다. 이로 인해 공격자는 사용자 시스템에 대한 완전한 제어권을 얻을 수 있습니다.

  • Scenario #2: CI/CD 파이프라인의 무결성 손상 기업의 CI/CD 파이프라인이 제대로 보호되지 않아, 공격자가 파이프라인 내의 스크립트나 설정 파일을 변조합니다. 이로 인해 악성 코드가 포함된 버전의 애플리케이션이 프로덕션 환경에 배포됩니다. 개발팀은 이러한 변조 사실을 알지 못하고, 사용자들은 손상된 애플리케이션을 사용하게 됩니다.

  • Scenario #3: 클라이언트 측 데이터 조작 온라인 상점에서 사용자가 쇼핑 카트에 담긴 상품의 가격을 클라이언트 측 스크립트로 조작하여 낮은 가격으로 결제를 시도합니다. 만약 서버 측에서 이 가격 정보에 대한 무결성 검증을 다시 수행하지 않는다면, 공격자는 실제 가격보다 훨씬 낮은 가격으로 상품을 구매할 수 있습니다.


A9:Security Logging and Monitoring Failures (was A10 - Insufficient Logging & Monitoring)

Description

보안 로깅 및 모니터링 실패(Security Logging and Monitoring Failures)불충분한 로깅과 모니터링이 사고 대응(incident response)과의 통합 부족과 결합될 때 발생합니다. 이는 공격자들이 시스템을 더욱 공격하고, 지속성을 유지하며, 더 많은 시스템으로 확장하고, 데이터를 변조, 추출 또는 파괴하도록 허용합니다. 대부분의 침해 연구에 따르면, 침해를 탐지하는 데 걸리는 시간은 평균 200일 이상이며, 주로 내부 프로세스나 모니터링이 아닌 외부 당사자에 의해 탐지됩니다.

  • 불충분한 로깅과 모니터링은 모든 중요한 보안 사고의 기반이 됩니다. 이러한 취약점으로 인해 공격자들은 시스템을 더 공격할 수 있게 됩니다.
  • 불필요한 로그를 많이 남기는 것도 좋지 않지만, 감시해야 할 이벤트들(예: 로그인 시도, 접근 통제 실패, 데이터 변경)은 반드시 기록해야 합니다.
  • 로그인, 로그인 실패와 같은 중요한 활동에 대한 로그가 모니터링 되지 않고, 경고 및 오류에 대한 로그 메시지도 없거나, 의심스러운 활동에 대한 API 호출 로그를 모니터링하지 않으면 이러한 취약점에 노출될 수 있습니다.
  • 로그를 단지 로컬에만 저장하고, 사용자나 공격자에게 로깅이나 경고 이벤트가 보여질 수 있다면 (예: 웹 페이지에 에러 로그가 그대로 노출) 이러한 취약점을 가지고 있는 것입니다.

Prevention

  • 모든 로그인, 접근 통제 실패, 서버 측 입력값 검증 실패 등 의심스럽거나 악의적인 계정 활동을 식별할 수 있는 내용들은 로깅해야 합니다.
  • 중앙 집중식 로그 관리 솔루션(예: SIEM)에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확인하여 보안 대책을 세웁니다.
  • 로그는 충분한 컨텍스트(context) 정보를 포함해야 합니다. (예: 타임스탬프, 사용자 ID, 소스 IP 주소, 요청된 URL 등)
  • 로그 무결성을 보호해야 합니다. 공격자가 로그를 변조하거나 삭제하지 못하도록 합니다. (예: WORM 저장소, 해시 체인)
  • 실시간에 가까운 모니터링 및 경고 시스템을 구축하여 의심스러운 활동이 발생했을 때 즉시 알림을 받을 수 있도록 합니다.
  • 로그 데이터를 정기적으로 분석하여 패턴을 파악하고, 비정상적인 활동을 식별합니다.
  • 사고 대응 계획(Incident Response Plan)을 수립하고, 로깅 및 모니터링 시스템을 이 계획에 통합합니다.

Attack Scenarios

  • Scenario #1: 로깅 부족으로 인한 지속적인 공격 감지 실패 애플리케이션에 SQL 인젝션 취약점이 존재하고, 공격자는 이를 통해 데이터베이스에 접근하여 민감한 정보를 추출합니다. 하지만 애플리케이션 서버의 로그에는 SQL 쿼리 실패나 비정상적인 데이터베이스 접근에 대한 기록이 없거나, 관련 경고가 설정되어 있지 않습니다. 결과적으로 공격자는 수개월 동안 탐지되지 않은 채 시스템에서 데이터를 계속해서 빼낼 수 있습니다.

  • Scenario #2: 에러 로그를 통한 정보 유출 및 시스템 탐색 웹 서버가 상세한 에러 로그를 공개적으로 접근 가능한 디렉토리에 저장하거나, 사용자에게 직접 표시합니다. 공격자는 이 로그를 통해 데이터베이스 연결 문자열, 내부 IP 주소, 취약한 라이브러리 버전 등 민감한 시스템 정보를 얻게 됩니다. 이 정보는 추가적인 공격을 위한 발판으로 사용될 수 있습니다.

  • Scenario #3: 모니터링 부족으로 인한 계정 침해 미인지 공격자가 크리덴셜 스터핑 공격을 통해 수많은 사용자 계정에 대한 로그인 시도를 수행합니다. 하지만 로그인 실패 횟수에 대한 모니터링이나 임계값 설정이 없어 비정상적인 로그인 시도를 감지하지 못합니다. 결국 공격자는 유효한 사용자 계정을 찾아내어 성공적으로 로그인하지만, 시스템 관리자는 이러한 침해 사실을 전혀 알지 못합니다.


A10:Server-Side Request Forgery (SSRF) (New)

Description

서버 측 요청 위조(Server-Side Request Forgery, SSRF)는 애플리케이션이 사용자가 제공한 URL을 제대로 검증하지 않고 외부 리소스(외부 서버 또는 내부 네트워크)를 가져올 때(fetching) 발생하는 취약점입니다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 접근 제어 목록(ACL)에 의해 보호되는 경우에도 특정 애플리케이션에 조작된 요청을 예기치 않은 대상(destination)으로 보내도록 허용해버립니다.

  • 현대 웹 애플리케이션은 엔드유저에게 편리한 기능을 제공하기 위해 URL 패칭(URL fetching)과 같은 시나리오(예: URL에서 이미지 가져오기, 원격 파일 임포트)가 일반화되었습니다. 그 결과 SSRF 취약점이 증가하게 된 것입니다. 클라우드 기반 아키텍처의 복잡성 때문에 더욱이 이 취약점이 증가하게 될 것입니다.

Prevention

SSRF 공격을 방어하기 위한 접근 방식은 네트워크 계층과 애플리케이션 계층으로 나눌 수 있습니다.

  • 네트워크 계층 (From Network layer)

    • SSRF의 영향을 줄이기 위해 분리된 네트워크(separate networks)에서 원격 리소스 접근 기능을 나눕니다. (예: 외부 리소스 접근을 위한 프록시 서버를 별도 네트워크에 배치)
    • 방화벽이나 네트워크 접근에 관한 기본 정책을 ‘거부(deny)’로 설정하고, 필수적인 인트라넷 트래픽만 허용합니다.
    • 방화벽의 모든 네트워크 플로우를 기록(log)합니다.
  • 애플리케이션 계층 (From Application layer)

    • 클라이언트로부터 받은 입력 데이터를 안전하게 처리(sanitize)하고 유효성 검사(validate)합니다.
    • 긍정적인 허용 목록(Positive Allow List)을 사용하여 URL 스키마, 포트, 그리고 대상을 강제합니다. 즉, 허용할 URL만 명시적으로 지정하고 나머지는 모두 차단합니다.
    • 클라이언트에게 원시(raw) 응답을 직접 주지 않습니다. (예: 원격 서버에서 가져온 내용을 사용자에게 직접 반환하지 않고, 애플리케이션이 내용을 파싱하여 필요한 정보만 필터링해서 제공)
    • HTTP 리다이렉션(redirection)을 비활성화합니다. (자동 리다이렉션이 SSRF 공격에 악용될 수 있으므로)
    • SSRF 완화를 위해 ‘거부 목록(Deny List)’을 사용하거나 정규 표현식(regular expression)을 사용해서는 안 됩니다. 공격자들은 그것들을 우회할 수 있는 도구와 기술, 페이로드들이 이미 있습니다. (예: localhost를 필터링해도 127.0.0.1이나 0.0.0.0 등으로 우회 가능)
  • 추가적인 고려 사항 (Additional Measures to consider):

    • 프론트 시스템에 OpenID와 같은 보안 관련 서비스를 배포해서는 안 됩니다. 이러한 시스템에 관해서는 로컬에서 통제해야 합니다.
    • 전용적이고 관리 가능한 사용자 그룹이 있는 프론트엔드에서는 VPN과 같이 고도로 보호해야 할 필요가 있는 독립적인 시스템에서 네트워크 암호화를 사용해야 합니다.

Attack Scenarios

공격자는 다음과 같은 시나리오들을 통해서 방화벽이나 네트워크 ACL 뒤에서 보호받는 시스템을 공격할 수 있습니다.

  • Scenario #1: 내부 서버 포트 스캔 만약 네트워크 구조가 분할되지 않았다면, 공격자는 SSRF 취약점을 이용하여 내부 네트워크에 대한 포트 스캔을 시도할 수 있습니다. 서버의 응답 시간(연결 성공/실패 여부, 연결 거부 여부)을 분석하여 어떤 내부 포트가 열려 있는지 알아낼 수 있습니다. 예: http://example.com/api/get_data?url=http://192.168.1.1:22 (SSH 포트 스캔)

  • Scenario #2: 민감 데이터 노출 공격자가 file:///etc/passwd, http://localhost:28017 (MongoDB 기본 포트)와 같은 내부 리소스에 접근할 수 있게 된다면, 민감한 시스템 파일이나 내부 서비스의 정보를 탈취할 수 있습니다. 예를 들어, file:///etc/passwd는 Linux 시스템의 사용자 정보를 포함하고 있습니다.

  • Scenario #3: 클라우드 서비스 메타데이터 저장소 접근 대다수의 클라우드 서비스 제공자(AWS, Azure, GCP 등)는 http://169.254.169.254와 같은 메타데이터 저장소(metadata service)를 제공합니다. 공격자는 SSRF를 통해 이 메타데이터 저장소에 접근하여 클라우드 인스턴스의 자격 증명(credential), API 키 등 민감한 자료를 탈취할 수 있습니다.

  • Scenario #4: 내부 서비스 침해 및 원격 코드 실행 공격자는 SSRF를 통해 내부 서비스(예: 내부 API, 관리 콘솔)를 악용하여 원격 코드 실행(Remote Code Execution, RCE) 또는 서비스 거부(DoS)와 같은 공격을 실행할 수 있게 될 것입니다. 예를 들어, 관리 콘솔의 취약점을 SSRF와 연계하여 악용할 수 있습니다.

This post is licensed under CC BY 4.0 by the author.