first commit
This commit is contained in:
Longinos
commit
b62122eb0f
|
|
@ -0,0 +1,231 @@
|
|||
### 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
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
### Medium Risk
|
||||
|
||||
- CSP: Wildcard Directive, OHV14. VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
||||
- Directory Browsing, OHV14. VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
||||
- CSP: style-src unsafe-inline. OHV14. VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
||||
### Low Risk
|
||||
|
||||
- Private IP Disclosure. OHV14. VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
||||
- Private IP Disclosure OHV14. VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
||||
- Strict-Transport-Security Header Not Set, OVH6 VMWare OWASP vulnerability, we can do nothing. risk accepted.
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
### MEDIUM RISK
|
||||
|
||||
## 1. CSP: Wildcard Directive
|
||||
# Eric response: Can't we updated the apache config to add trusted source?
|
||||
|
||||
## 2. CSP: style-src 'unsafe-inline'
|
||||
# Eric response: Accept the risk
|
||||
|
||||
## 3. CSP Header Not Set
|
||||
# Eric response: This is zabbix it's for internal use. Accept the risk
|
||||
|
||||
## 4. CSP: script-src 'unsafe-inline'
|
||||
# Eric response: This is zabbix it's for internal use. Accept the risk
|
||||
|
||||
## 5. Absence of Anti-CSRF Tokens
|
||||
# Eric response: accept the risk
|
||||
|
||||
## 6. Source Code Disclosure - SQL
|
||||
# Eric response: what source code is exposed?
|
||||
|
||||
## 7. Sub Resource Integrity Attribute Missing
|
||||
# Eric response: nothink currently. Can you provide the integrity tag for the concerned external script
|
||||
|
||||
## 8. Vulnerable JavaScript Library
|
||||
# Eric response: What's the concerne library?
|
||||
|
||||
## 9. Missing Anti-clickjacking Header
|
||||
# Eric response:
|
||||
|
||||
## 10. Cross-Domain Misconfiguration
|
||||
# Eric response:
|
||||
|
||||
### LOW RISK
|
||||
|
||||
## 1. Strict-Transport-Security Header Not Set
|
||||
# Eric response: accept risk
|
||||
|
||||
## 2. Dangerous JavaScript Functions
|
||||
# Eric response: Accept the risk
|
||||
|
||||
## 3. Server Leaks Version Information via 'Server' HTTP Response Header
|
||||
# Eric response: Accept the risk
|
||||
|
||||
## 4. CSP: X-Content-Type-Options Header Missing
|
||||
# Eric response: Accept risk
|
||||
|
||||
## 5. Cross-Domain JavaScript Source File Inclusion
|
||||
# Eric response: accept the risk
|
||||
|
||||
## 6. Cookie Without Secure Flag
|
||||
# Eric response: accept the risk
|
||||
|
||||
## 7. Cookie with SameSite Attribute None
|
||||
# Eric response: accept the risk
|
||||
Loading…
Reference in New Issue