OWASP-02-05-2024/01-05-2024-hostedscan.md

232 lines
12 KiB
Markdown
Raw Normal View History

2024-05-02 17:18:34 +02:00
### Medium Risk
## OVH14-win1
# 1. CSP: Wildcard Directive Vulnerability on Internal Apache Server
Issue Identified: The Content-Security-Policy (CSP) for our internal Apache server (https://178.32.125.176) is configured with wildcard directives for font-src, img-src, script-src, and style-src. This configuration significantly reduces the security level by allowing resources from any origin, increasing the risk of Cross-Site Scripting (XSS) and other types of injection attacks.
Recommended Action:
Modify CSP: To enhance our security posture and mitigate potential XSS and data injection risks, I recommend revising the CSP directives to specify trusted sources instead of using wildcards. This change will restrict the browser's ability to load resources to those hosted on approved domains, significantly reducing the likelihood of malicious content execution.
# 2. CSP: style-src 'unsafe-inline' Vulnerability
Issue Identified:
The Content-Security-Policy (CSP) directive style-src 'unsafe-inline' is currently used in our web application's security configuration. This setting allows inline styles, which poses a security risk as it can be exploited by attackers to inject malicious CSS. Inline styles are a common vector for various types of attacks, including Cross-Site Scripting (XSS).
Recommended Action:
If possible, Eliminate Unsafe Inline Styles: To increase security against XSS and other injection attacks, it is advisable to remove the 'unsafe-inline' directive from the style-src CSP rule. Instead, use external CSS files or adopt Content Security Policy Level 3 features to safely include dynamic styles.
## OVH14-win2
same vulneabilities with the apache server as OVH14-win1, same procedures...
(https://178.32.125.178)
## OVH6-Ubuntu7-Zabbix
# 1. CSP Header Not Set on Apache Ubuntu Server
Issue Identified:
The Apache/Ubuntu server at http://54.38.9.70/ displays the default Apache2 Ubuntu page and is missing a comprehensive Content-Security-Policy (CSP) header. The only CSP directive set is frame-ancestors 'self', which limits the domains that can frame the content of the page to the same origin. However, this does not sufficiently mitigate the risk of other types of content injection attacks, such as Cross-Site Scripting (XSS), as it does not restrict sources for scripts, styles, images, etc.
Recommended Action:
Implement a Comprehensive CSP: To better protect against XSS and other injection attacks, it is crucial to define a full CSP that includes directives for scripts, styles, images, and other resources. This policy will ensure that only resources from the same origin are allowed, except for frames, which are limited to the same origin by the existing frame-ancestors directive.
# 2. CSP: Wildcard Directive Vulnerability
already explained in OVH14-win1
# 3. CSP: script-src 'unsafe-inline' Vulnerability
Issue Identified:
The script-src 'unsafe-inline' directive is used in the Content-Security-Policy (CSP) of one of our applications. This setting permits the execution of inline scripts and event-handling attributes within HTML, which poses a significant security risk. It makes the application vulnerable to Cross-Site Scripting (XSS) attacks, as attackers can inject malicious scripts directly into web pages.
Recommended Action:
Remove Unsafe Inline Scripts: To enhance security and prevent XSS attacks, it is advisable to remove the 'unsafe-inline' directive from the script-src CSP rule.
## OVH9-win3
# 1. Absence of Anti-CSRF Tokens Vulnerability
(https://51.77.72.117 Beckman Coulter)
Issue Identified
This issue exposes the application to CSRF attacks, where an attacker can manipulate a user into performing actions they did not intend, utilizing the user's own credentials. CSRF attacks exploit the trust that a website has in a user's browser, making it a critical security concern, especially when combined with XSS vulnerabilities that could amplify the attack potential.
Recommended Action:
Implement Anti-CSRF Measures: To mitigate the risk of CSRF attacks, it is crucial to integrate anti-CSRF tokens into all forms and state-changing requests within the application
## OVH12 - Win1
(/dxone-pentest.imep.net Beckman Coulter)
# 1. Source Code Disclosure - SQL
Issue Identified: The application source code was disclosed by the web server, potentially exposing SQL code.
Recommended Action: Ensure that application source code is not stored with alternative file extensions and is not included within other files or data deployed to or served by the web server.
# 2. Sub Resource Integrity Attribute Missing
Issue Identified: The integrity attribute is missing on script or link tags served by an external server, which could allow attackers to inject malicious content.
Recommended Action: Add a valid integrity attribute to all external script and link tags to ensure content has not been altered.
# 3. CSP: Wildcard Directive
Already explained
# 4. CSP: style-src 'unsafe-inline'
Issue Identified: The style-src 'unsafe-inline' directive in CSP allows inline styles, making the application vulnerable to XSS attacks.
Recommended Action: Remove the 'unsafe-inline' directive from the style-src CSP rule and use external or nonce-based CSS to enhance security.
# 5. Vulnerable JavaScript Library
Issue Identified: A JavaScript library used in the application is outdated or has known security vulnerabilities.
Recommended Action: Update the JavaScript library to the latest version. Ensure that all third-party libraries are kept up-to-date and regularly checked for vulnerabilities.
### Low Risk
## OVH14-WIN1
# 1. Strict-Transport-Security Header Not Set
Issue Identified: The Strict-Transport-Security (HSTS) header is not set in the Apache server configuration. This header is crucial for enforcing secure (HTTPS) connections to the server, preventing downgrade attacks and other potential security threats like cookie hijacking.
Recommended Action:
Implement HSTS: Add the Strict-Transport-Security header to the Apache server configuration to enforce HTTPS connections.
## OVH14-WIN2
# 1. Strict-Transport-Security Header Not Set
It's the same as ovh14-win1
## OVH12-WIN1
# 1. Dangerous JavaScript Functions
Issue Identified: Certain JavaScript functions, identified as dangerous, are currently in use within our application's codebase. These functions can potentially leave the site vulnerable to a variety of threats, including but not limited to, cross-site scripting (XSS) and data exfiltration.
Recommended Action:
Review and Replace Dangerous Functions: Conduct a comprehensive review of the JavaScript code to identify and replace any dangerous functions. Use more secure alternatives that adhere to modern security practices.
# 2. Strict-Transport-Security Header Not Set
Already explained
## OVH6-Ubuntu7-Zabbix
# 1. Server Leaks Version Information via "Server" HTTP Response Header Field
Server Leaks Version Information
Issue Identified: The web/application server (apache) is disclosing version information through the "Server" HTTP response header. This exposure can help attackers in identifying other vulnerabilities specific to the server versions being used.
Recommended Action:
Suppress Server Information: Configure your web server, application server, or load balancer to suppress the Server header or modify it to return only generic information
## OVH9-win3 (Beckman Coulter)
# 1. Strict-Transport-Security Header Not Set
Issue Identified: The Strict-Transport-Security (HSTS) header is not set in our application's server. This omission makes the site more susceptible to man-in-the-middle attacks by allowing unsecured HTTP connections.
Recommended Action:
Enable HSTS: Add the Strict-Transport-Security header to server's configuration to enforce secure connections:
# 2. X-Content-Type-Options Header Missing
Issue Identified: The X-Content-Type-Options header is missing from HTTP responses, which prevents the browser from MIME-sniffing the response away from the declared content-type. This vulnerability can lead to security risks like style/script injection attacks.
Recommended Action:
Implement MIME Sniffing Protection: Configure the server to include the X-Content-Type-Options header with the value nosniff in all responses
## OVH9-win2 (Jumbodiset)
# 1. Strict-Transport-Security Header Not Set
# 2. X-Content-Type-Options Header Missing
same vulnerabilities as ovh9win3. Same procedures
## OVH10win1 (Stryker)
# 1. Cross-Domain JavaScript Source File Inclusion
Issue Identified: JavaScript source files are being included from different domains, which can expose the site to malicious script injections.
Recommended Action: Restrict JavaScript source files to be loaded only from trusted, same-origin domains or ensure proper CORS settings to mitigate potential risks.
# 2. Strict-Transport-Security Header Not Set
Issue Identified: HSTS header is missing, allowing potential for insecure connections.
Recommended Action: Add the HSTS header to enforce secure (HTTPS) connections
# 3. Server Leaks Version Information via "Server" HTTP Response Header Field
Issue Identified: Server version information is exposed in HTTP headers.
Recommended Action: Configure the server to suppress or provide generic details in the Server header.
## OVH6-Ubuntu1 (mrc connect. Apache-coyote/1.1)
# 1. Cookie Without Secure Flag
Issue Identified: Cookies are sent over unsecured connections, which could be intercepted.
Recommended Action: Ensure all cookies are flagged as Secure, only transmitting them over HTTPS.
# 2. Strict-Transport-Security Header Not Set
Issue Identified: HSTS header is not set, risking unsecured HTTP connections.
Recommended Action: Implement the HSTS header to ensure all connections use HTTPS
# 3. Cookie with SameSite Attribute None
Issue Identified: Cookies are sent with SameSite=None without Secure flag, making them vulnerable to CSRF attacks.
Recommended Action: Set cookies with SameSite=Lax or Strict, and use the Secure flag when SameSite=None is necessary.
# 4. Server Leaks Version Information via "Server" HTTP Response Header Field
Issue Identified: Server version information is exposed in HTTP headers.
Recommended Action: Configure the server to suppress or provide generic details in the Server header.
## OVH6-Win1 (Server: Microsoft-IIS/8.5)
# 1. X-Content-Type-Options Header Missing
Already explained
# 2. Server Leaks Version Information via "Server" HTTP Response Header Field
Issue Identified: Detailed server version info is exposed which could aid attackers.
Recommended Action: Configure IIS to customize or suppress the Server header to remove version details.
# 3. Strict-Transport-Security Header Not Set
Issue Identified: Missing HSTS header, allowing for possible insecure connections.
Recommended Action: Configure the server to use HSTS:
# 4. X-Content-Type-Options Header Missing
Issue Identified: MIME-sniffing vulnerability present due to missing header.
Recommended Action: Implement the X-Content-Type-Options header with the value nosniff.
### Not our scope
## OVH6-Win4-deprecated, migrated to OVH10Win2
# Absence of Anti-CSRF Tokens
# Content Security Policy (CSP) Header Not Set
# Missing Anti-clickjacking Header
# Strict-Transport-Security Header Not Set
# X-Content-Type-Options Header Missing
## OVH7
# CSP: Wildcard Directive
# CSP: Directory Browsing
# CSP: CSP: script-src unsafe-inline
# CSP: Vulnerable JS Library
# CSP: style-src unsafe-inline
# CSP: style-src unsafe-inline
# Private IP Disclosure
## OVH10-Oracle2
# Strict-Transport-Security Header Not Set
# X-Content-Type-Options Header Missing
# Server Leaks Version Information via "Server" HTTP Response Header Field
## OVH10-Oracle1
# Strict-Transport-Security Header Not Set
# X-Content-Type-Options Header Missing
# Server Leaks Version Information via "Server" HTTP Response Header Field