Skip to content

Latest commit

 

History

History
607 lines (480 loc) · 80.5 KB

summary.md

File metadata and controls

607 lines (480 loc) · 80.5 KB
Raw

Fortify on Demand Release Report

IWA-Java [KAL] - main

Report generated on: 2024-12-03 11:12

Security Policy

Rating: ★☆☆☆☆ Status: Fail

Issue Counts

Type Last Scan Date Critical High Medium Low
Static 2024-12-03 08:52 36 15 0 0
Dynamic 2024-11-07 09:39 2 2 2 15
Mobile N/A 0 0 0 0
Open Source 2024-12-03 08:52 7 44 25 1
Total 45 61 27 16

Existing Issues

Summary: The class in User.java is both a database persistent entity and a dynamically bound request object. Allowing database persistent entities to be auto-populated by request parameters will let an attacker create unintended database records in association entities or update unintended fields in the entity object. Allowing database persistent entities to be auto-populated by request parameters will let an attacker create unintended records in association entities or update unintended fields in the entity object.

Summary: The call to getInstance() at EncryptedPasswordUtils.java line 76 uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.The identified call uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.

Summary: Attackers can control the file system path argument to resolve() at FileSystemStorageService.java line 143, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The method createUser() in ApiUserController.java mishandles confidential information, which can compromise user privacy and is often illegal.Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

Summary: The application does not restrict browsers from letting third-party sites render its content.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 54, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The method createUser() in ApiUserController.java mishandles confidential information, which can compromise user privacy and is often illegal.Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

Summary: The method setEmailPassword() in EmailUtils.java mishandles confidential information, which can compromise user privacy and is often illegal.Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

Summary: Content Security Policy (CSP) is not configured.

Summary: On line 119 of UserUtils.java, the method registerUser() writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.

Summary: XML parser configured in UserController.java:890 does not prevent nor limit external entities resolution. This can expose the parser to an XML External Entities attackUsing XML parsers that are not configured to prevent or limit external entities resolution can expose the parser to an XML External Entities attack.

Summary: The method createUser() in ApiUserController.java mishandles confidential information, which can compromise user privacy and is often illegal.Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

Summary: Content Security Policy (CSP) is not configured.

Summary: The call to getInstance() at EncryptedPasswordUtils.java line 47 uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.The identified call uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 78, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The function matches() in EncryptedPasswordUtils.java uses a cryptographic encryption algorithm with an insecure mode of operation on line 76.Do not use cryptographic encryption algorithms with an insecure mode of operation.

Summary: Attackers can control the file system path argument to resolve() at FileSystemStorageService.java line 143, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: XML parser configured in UserController.java:905 does not prevent nor limit external entities resolution. This can expose the parser to an XML External Entities attackUsing XML parsers that are not configured to prevent or limit external entities resolution can expose the parser to an XML External Entities attack.

Summary: The method sendEmail() in EmailUtils.java establishes an unencrypted connection to a mail server allowing an attacker to carry out a man-in-the-middle attack and read all the mail transmissions.Establishing an unencrypted connection to a mail server allows an attacker to carry out a man-in-the-middle attack and read all the mail transmissions.

Summary: Attackers can control the file system path argument to resolve() at FileSystemStorageService.java line 143, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The function decryptPassword() in EncryptedPasswordUtils.java uses a cryptographic encryption algorithm with an insecure mode of operation on line 61.Do not use cryptographic encryption algorithms with an insecure mode of operation.

Summary: The class in Authority.java is both a database persistent entity and a dynamically bound request object. Allowing database persistent entities to be auto-populated by request parameters will let an attacker create unintended database records in association entities or update unintended fields in the entity object. Allowing database persistent entities to be auto-populated by request parameters will let an attacker create unintended records in association entities or update unintended fields in the entity object.

Summary: The method setEmailPassword() in EmailUtils.java mishandles confidential information, which can compromise user privacy and is often illegal.Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 54, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The file DefaultController.java passes unvalidated data to an HTTP redirect function on line 218. Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.

Summary: Attackers can control the file system path argument to resolve() at FileSystemStorageService.java line 143, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 159, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: Attackers can control the file system path argument to get() at ProductController.java line 146, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The connection established via send() in EmailUtils.java does not verify the server certificate when making an SSL connection. This leaves the application vulnerable to a man-in-the-middle attack.Server identity verification is disabled when making SSL connections.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 159, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The function encryptPassword() in EncryptedPasswordUtils.java uses a cryptographic encryption algorithm with an insecure mode of operation on line 47.Do not use cryptographic encryption algorithms with an insecure mode of operation.

Summary: The call to SecretKeySpec() at EncryptedPasswordUtils.java line 42 uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.The identified call uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.

Summary: Attackers can control the file system path argument to get() at FileSystemStorageService.java line 159, which allows them to access or modify otherwise protected files.Allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Summary: The call to getInstance() at EncryptedPasswordUtils.java line 61 uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.The identified call uses a weak encryption algorithm that cannot guarantee the confidentiality of sensitive data.

Summary: On line 95 of ProductRepository.java, the method findByCode() invokes a SQL query built with input that comes from an untrusted source. This call could allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.

Summary: The method getKeywordsContent() in ProductController.java sends unvalidated data to a web browser on line 97, which can result in the browser executing malicious code.Sending unvalidated data to a web browser can result in the browser executing malicious code.

Summary: The method serveFile() in UserController.java includes unvalidated data in an HTTP response header on line 793. This enables attacks such as cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.

Summary: The function commence() in BasicAuthenticationEntryPointCustom.java reveals system data or debug information by calling println() on line 68. The information revealed by println() could help an adversary form a plan of attack.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.

Summary: Hardcoded passwords can compromise system security in a way that is difficult to remedy.

Summary: The class AdminDefaultController is a singleton, so the member field thRCECMD is shared between users. The result is that one user could see another user's data.Servlet member fields might allow one user to see another user's data.

Summary: The function deserializeUser() in UserUtils.java sometimes fails to release a system resource allocated by FileInputStream() on line 160.The program can potentially fail to release a system resource.

Summary: The function serializeUser() in UserUtils.java sometimes fails to release a system resource allocated by FileOutputStream() on line 152.The program can potentially fail to release a system resource.

Summary: A sensitive field defined in User.java on line 192 is exposed to the model binder.A sensitive field is exposed to the model binder.

Summary: Hardcoded passwords can compromise system security in a way that is difficult to remedy.

Summary: The method serveUnverifiedFile() in UserController.java includes unvalidated data in an HTTP response header on line 947. This enables attacks such as cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.

Summary: The function registerUser() in UserUtils.java sometimes fails to release a system resource allocated by FileReader() on line 82.The program can potentially fail to release a system resource.

Summary: The method downloadFile() in ProductController.java includes unvalidated data in an HTTP response header on line 179. This enables attacks such as cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.

Summary: The function commence() in AuthenticationEntryPointJwt.java reveals system data or debug information by calling println() on line 69. The information revealed by println() could help an adversary form a plan of attack.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.

  • High (Static) - Dockerfile Misconfiguration: Default User Privilege:
    Dockerfile:1

Summary: The Dockerfile does not specify a USER, so it defaults to running with a root user.

Summary: The method serveXMLFile() in UserController.java includes unvalidated data in an HTTP response header on line 865. This enables attacks such as cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.

Summary: The function handle() in ApiAccessDeniedHandler.java reveals system data or debug information by calling println() on line 66. The information revealed by println() could help an adversary form a plan of attack.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.

New Issues

Summary:
WebInspect has detected the application to be vulnerable to an HTTP Request Smuggling attack.

HTTP Request Smuggling vulnerabilities arise due to the discrepancy in parsing of non-compliant HTTP headers by the front-end and back-end servers. By supplying a request that is interpreted as being of different lengths by different servers, an attacker can poison the back-end TCP/TLS socket and prepend arbitrary data to the next request or smuggle additional requests to the back-end server without the front-end server being aware of it.

There are numerous ways in which a malicious user can accomplish an HTTP Request Smuggling attack. In this instance, an incoming HTTP request that contains both Content-Length and Transfer-Encoding headers is interpreted differently by the front-end server and the back-end server. One honors the Content-Length header and the other the Transfer-Encoding header to determine the length of the request. This can render the application vulnerable to smuggling attacks.

The attack vector used indicates that the front-end server honors the Content-Length header and the back-end server honors the Transfer-Encoding header.

WebInspect was able to confirm this vulnerability. WebInspect performed the attack by sending two requests on the same TCP/IP connection with the server. The first request with HTTP headers 


Content-Length: 36
Transfer-Encoding: chunked
and request body 
0


POST /mal formed ZZZZ/9.7
Q: W
was crafted so that the server put part of the request body in a queue. This was prepended to the subsequent HTTP request and caused an error on the server.

Summary:
Cross-Site Scripting vulnerability found in Get parameter keywords. The following attack uses plain encoding:

<sCrIpT></sCrIpT>


A Cross-Site Scripting (XSS) vulnerability was detected in the web application. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. In this instance, the web application was vulnerable to an automatic payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross-Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Recommendations include implementing secure programming techniques that ensure proper filtration of user-supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a format that can be executed.

Summary:
A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. The attacker could use this weakness to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks.

Clickjacking
The goal of a Clickjacking attack is to deceive the victim (user) into interacting with UI elements of the attacker’s choice on the target web site without their knowledge and then executing privileged functionality on the victim’s behalf. To achieve this goal, the attacker must exploit the XFS vulnerability to load the attack target inside an iframe tag, hide it using Cascading Style Sheets (CSS) and overlay the phishing content on the malicious page. By placing the UI elements on the phishing page so they overlap with those on the page targeted in the attack, the attacker can ensure that the victim must interact with the UI elements on the target page not visible to the victim.

WebInspect has detected a page which potentially handles sensitive information using an HTML form with a password input field and is missing XFS protection.

An effective frame-busting technique was not observed while loading this page inside a frame.
This response while protected by a valid X-Frame-Options does not contain a valid Content-Security-Policy(CSP) frame-ancestors directive. Consider adding CSP as it now replaces X-Frame-Options and is supported in most modern browswers.

Summary: Webinspect has detected an archive file with the .gz extension on the target server. The severity of the threats posed by the web-accessible backup files depends on the sensitivity of the information stored in original document. Based on that information, an attacker can gain sensitive information about the site architecture, database and network access credential details, encryption keys, and so forth from these files. The attacker can use information obtained to craft precise targeted attacks, which may not otherwise be feasible, against the application.

Summary: This policy states that any area of the website or web application that contains sensitive information or access to privileged functionality such as remote site administration requires that all cookies are sent via SSL during an SSL session. The URL: https://iwa.onfortify.com:443/ has failed this policy. If a cookie is marked with the "secure" attribute, it will only be transmitted if the communications channel with the host is a secure one. Currently this means that secure cookies will only be sent to HTTPS (HTTP over SSL) servers. If secure is not specified, a cookie is considered safe to be sent in the clear over unsecured channels.


* Medium (Dynamic) - Cross-Frame Scripting: [https://iwa.onfortify.com:443/](https://ams.fortify.com/redirect/Issues/76902059-1ace-4d09-9d94-2c5b5e8ea7b1)

Summary:
A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. The attacker could use this weakness to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks.

Clickjacking
The goal of a Clickjacking attack is to deceive the victim (user) into interacting with UI elements of the attacker’s choice on the target web site without their knowledge and then executing privileged functionality on the victim’s behalf. To achieve this goal, the attacker must exploit the XFS vulnerability to load the attack target inside an iframe tag, hide it using Cascading Style Sheets (CSS) and overlay the phishing content on the malicious page. By placing the UI elements on the phishing page so they overlap with those on the page targeted in the attack, the attacker can ensure that the victim must interact with the UI elements on the target page not visible to the victim.

WebInspect has detected a response containing one or more forms that accept user input but is missing XFS protection.

An effective frame-busting technique was not observed while loading this page inside a frame.
This response while protected by a valid X-Frame-Options does not contain a valid Content-Security-Policy(CSP) frame-ancestors directive. Consider adding CSP as it now replaces X-Frame-Options and is supported in most modern browswers.

Summary: FrontPage-related directories were found during a Directory Enumeration scan. FrontPage allows remote users to upload and modify web site content. Historically, attackers seek out FrontPage sites since FrontPage is often misconfigured to not require authentication. FrontPage components have also contained multiple vulnerabilities in the past. Recommendations include reviewing the FrontPage configuration, and removing FrontPage if it is not being used.

Summary: FrontPage-related directories were found during a Directory Enumeration scan. FrontPage allows remote users to upload and modify web site content. Historically, attackers seek out FrontPage sites since FrontPage is often misconfigured to not require authentication. FrontPage components have also contained multiple vulnerabilities in the past. Recommendations include reviewing the FrontPage configuration, and removing FrontPage if it is not being used.

Summary: Directory Enumeration vulnerabilities were discovered within your web application. Risks associated with an attacker discovering a directory on your application server depend upon what type of directory is discovered, and what types of files are contained within it. The primary threat, other than accessing files containing sensitive information, is that an attacker can utilize the information discovered in that directory to perform other types of attacks. Recommendations include restricting access to important directories or files by adopting a "need to know" requirement for both the document and server root, and turning off features such as Automatic Directory Listings that provide information that could be utilized by an attacker when formulating or conducting an attack.

Summary: Directory Enumeration vulnerabilities were discovered within your web application. Risks associated with an attacker discovering a directory on your application server depend upon what type of directory is discovered, and what types of files are contained within it. The primary threat, other than accessing files containing sensitive information, is that an attacker can utilize the information discovered in that directory to perform other types of attacks. Recommendations include restricting access to important directories or files by adopting a "need to know" requirement for both the document and server root, and turning off features such as Automatic Directory Listings that provide information that could be utilized by an attacker when formulating or conducting an attack.

Summary:
Http Strict Transport Security (HSTS) policy enables web applications to enforce web browsers to restrict communication with the server over an encrypted SSL/TLS connection for a set period. Policy is declared via special Strict Transport Security response header. Encrypted connection protects sensitive user and session data from attackers eavesdropping on network connection.
Consider following attack scenarios:

  • Users often omit the URI scheme i.e. https:// when typing a URL in location bar to access a website. Also third party websites can link to the site using the “http” scheme instead of "”https”. This could result in an initial connection to a HTTPS-enabled site over an unencrypted channel. An eavesdropping attacker can hijack this unencrypted connection and replace the intended use of HTTPS protocol with HTTP in an attack known as SSLStrip, granting unauthorized access to all subsequent traffic.
  • Websites often transfer non-sensitive resources such as help documents over an unencrypted HTTP connection. Any cookies without a secure flag are sent along with such requests potentially disclosing sensitive user and session data to eavesdropper.
  • Man-in-the-Middle attacks that exploit user tendencies to override invalid certification warnings, e.g. SSLSniff.

For web sites configured with an accurate HSTS policy, browsers automatically upgrade any HTTP connections to HTTPS. Furthermore, browsers prevent users from overriding any host certificate warnings. HSTS offers an effective defense against above attack scenarios.

Summary: The SameSite attribute protects cookies from Cross-Site Request Forgery (CSRF) attacks. The browser automatically appends cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data like session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute on a cookie allows sites to control that behaviour and prevents browsers from appending the cookie to request if the request is generated from a third-party site page load. The SameSite attribute can have the following three values:

  • Strict: When set to Strict, cookies are only sent along with requests upon top level navigation .
  • Lax: When set to Lax, cookies are sent with top level navigation from the same host as well as GET requests originated to the host from third-party sites (for example, in iframe, link, href, and so on and the form tag with GET method only).
  • None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Please note that cookies that have the SameSite attribute with the value of None must be set with the Secure attribute otherwise the browser rejects the cookies. Additionally, a few specific browser versions reject the SameSite cookie with the None value for example, Chrome versions 51 to 66, versions of the UC Browser on Android prior to version 12.13.2, versions of Safari and embedded browsers on macOS 10.14, and all browsers on iOS 12 reject cookies set with SameSite=None. A suggested workaround for this issue is to set an alternate cookie with a prefix or suffix such as Legacy appended to cookiename . Sites can look for this legacy cookie if it does not find a cookie that was set with SameSite=None.

Summary: A resource on the target website has been found to be shared across websites using CORS with an open access control policy.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
A domain includes a list of domains that are allowed to make cross domain requests to shared resources in Access-Control-Allow-Origin header. This header can have either list of domains or a wildcard character (“*”) to allow all access. Having a wildcard is considered overly permissive policy. * Low (Dynamic) - HTML5: CORS Unsafe Methods Allowed: [https://iwa.onfortify.com:443/api/v3/site/subscribe-user](https://ams.fortify.com/redirect/Issues/82cf7e70-8584-4f63-aa7d-58df183f7f0e)

Summary: A resource on the target domain has been found to be shared using CORS. The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods

Summary: A server error response was detected. The server could be experiencing errors due to a misbehaving application, a misconfiguration, or a malicious value sent during the auditing process. While error responses in and of themselves are not dangerous, per se, the error responses give attackers insight into how the application handles error conditions. Errors that can be remotely triggered by an attacker can also potentially lead to a denial of service attack or other more severe vulnerability. Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.

Summary:
WebInspect has detected a web cache poisoning instance by fat GET requests. Fat GET requests are requests that contain parameters as request body. Web cache poisoning exploits the behaviour of the web server causing a malicious response to be served to legitimate requests. In this type of web cache poisoning, the cache key is derived from the original query parameters passed in the request line. However, the value of the query parameter used by the server is the duplicate value sent as part of the request body. This altered response is cached and served to the users with legitimate requests.



WebInspect has detected that the cache can be poisoned. The limit was passed in the request body and it is observed that the initial response differed from the later response for the same query. This indicates that the cache might be poisoned.

Summary: A resource on the target website has been found to be shared across websites using CORS with an open access control policy.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
A domain includes a list of domains that are allowed to make cross domain requests to shared resources in Access-Control-Allow-Origin header. This header can have either list of domains or a wildcard character (“*”) to allow all access. Having a wildcard is considered overly permissive policy. * Low (Dynamic) - HTML5: CORS Unsafe Methods Allowed: [https://iwa.onfortify.com:443/api/v3/products?limit=](https://ams.fortify.com/redirect/Issues/e1a99d9b-a23d-4951-b875-139dad5f7835)

Summary: A resource on the target domain has been found to be shared using CORS. The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods

Summary: A resource on the target website has been found to be shared across websites using CORS with an open access control policy.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
A domain includes a list of domains that are allowed to make cross domain requests to shared resources in Access-Control-Allow-Origin header. This header can have either list of domains or a wildcard character (“*”) to allow all access. Having a wildcard is considered overly permissive policy. * Low (Dynamic) - HTML5: CORS Unsafe Methods Allowed: [https://iwa.onfortify.com:443/api/](https://ams.fortify.com/redirect/Issues/a9a0c660-0c86-49a0-8b35-c7bb2248e1c4)

Summary: A resource on the target domain has been found to be shared using CORS. The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods

Summary: A server error response was detected. The server could be experiencing errors due to a misbehaving application, a misconfiguration, or a malicious value sent during the auditing process. While error responses in and of themselves are not dangerous, per se, the error responses give attackers insight into how the application handles error conditions. Errors that can be remotely triggered by an attacker can also potentially lead to a denial of service attack or other more severe vulnerability. Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary:
The Content-Type HTTP response header or the HTML meta tag provides a mechanism for the server to specify an appropriate character encoding for the response content to be rendered in the web browser. Proper specification of the character encoding through the charset parameter in the Content-Type field reduces the likelihood of misinterpretation of the characters in the response content and ensure reliable rendering of the web page. Failure to ensure enforcement of the desired character encoding could result in client-side attacks like Cross-Site Scripting.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment. Recommendations include setting autocomplete to "off" on all your forms.

Summary: A Privacy Policy was not supplied by the web application within the scope of this audit. Many legislative initiatives require that organizations place a publicly accessible document within their web application that defines their information privacy policy. As a general rule, these information privacy policies must detail what information an organization collects, the purpose for collecting it, potential avenues of disclosure, and any methods of addressing potential grievances. Various laws governing privacy policies include the Gramm-Leach-Bliley Act, Health Insurance Portability and Accountability Act (HIPAA), the California Online Privacy Protection Act of 2003, European Union's Data Protection Directive and others.

Summary: The web server sent a 401 "Authorization Required" status code with a response that did not contain a WWW-Authenticate HTTP header. This means the server is asking for authentication, but the browser is not prompting for authentication because of the missing WWW-Authenticate header. Recommendations include reviewing the web pages to determine if they should be protected via authentication, and correct the web server or application configuration to correct the problem by setting the 401 "Authorization Required" status code or by removing the WWW-Authenticate header.

Summary: The server supports the OPTIONS HTTP method. The OPTIONS method is used to determine what other methods the server supports for a given URI/resource.

Summary: Content Security Policy (CSP) is an HTTP response security header that developers and security architects can leverage to create an allow list of domains from which the site is allowed to load resources. This header provides an in-depth security protection from critical vulnerabilities such as cross-site scripting and clickjacking. Additionally, CSP restricts execution of inline JavaScript, dynamic JavaScript code evaluation from strings, and framing of the site from external domains. While CSP is not a replacement for input validation, it can help to significantly reduce the risk of XSS from unknown weaknesses. The CSP frame-ancestors directive is equivalent to X-Frame-Options and restricts the domain that are allowed to frame the site’s content.

Summary: While preventing display of information on the web page itself, the information submitted via hidden form fields is easily accessible, and could give an attacker valuable information that would prove helpful in escalating his attack methodology. Recommendations include not relying on hidden form fields as a security solution for any area of the web application that contains sensitive information or access to privileged functionality such as remote site administration functionality.

Summary: While preventing display of information on the web page itself, the information submitted via hidden form fields is easily accessible, and could give an attacker valuable information that would prove helpful in escalating his attack methodology. Recommendations include not relying on hidden form fields as a security solution for any area of the web application that contains sensitive information or access to privileged functionality such as remote site administration functionality.

Summary:
Hacker Level Insights provides developers and security professionals with more context relating to the overall security posture of their application. The Bootstrap version 4.5.3 was detected to be in use by during this scan. While these findings do not necessarily represent a security vulnerability, it is important to note that attackers commonly perform reconnaissance of their target in an attempt to identify known weaknesses or patterns. Knowing what the hacker can see provides context which can help teams better secure their applications.

Summary:
Hacker Level Insights provides developers and security professionals with more context relating to the overall security posture of their application. The jQuery version 3.5.1 was detected to be in use by during this scan. While these findings do not necessarily represent a security vulnerability, it is important to note that attackers commonly perform reconnaissance of their target in an attempt to identify known weaknesses or patterns. Knowing what the hacker can see provides context which can help teams better secure their applications.

Summary:
Hacker Level Insights provides developers and security professionals with more context relating to the overall security posture of their application. The Moment.js version 2.29.1 was detected to be in use by during this scan. While these findings do not necessarily represent a security vulnerability, it is important to note that attackers commonly perform reconnaissance of their target in an attempt to identify known weaknesses or patterns. Knowing what the hacker can see provides context which can help teams better secure their applications.
<style> .cvc-grid {width:100%;} .cvc-box {border-radius: 15px; border: 2px solid #1a75ff; width: 100%; padding: 10px;} .cvc-cat {position: relative; display: inline-block; border-bottom: 1px dotted black;} .cvc-cat .nvd-tooltip {visibility: hidden; width: 400px; background-color: #3b96ff; color: #fff; text-align: left; border-radius: 6px; padding: 5px; position: absolute; z-index: 1;} .cvc-cat:hover .nvd-tooltip {visibility: visible;} .score-box{color:#000!important;background-color:#f1f1f1!important;width:75%;border-radius:8px} .score-box div {border-radius:8px} .score-box div div{padding-left: 10px; font-weight: bold;} .score-box > div:after,.score-box > div:before {content:""; display:table;clear:both} .sb-good{color:#fff!important;background-color:#87e547!important} .sb-warn{color:#fff!important;background-color:#fbc02d!important} .sb-bad{color:#fff!important;background-color:#ff8686!important} .nvd-tooltip:before{content:"The National Vulnerability Database (NVD) helps Fortify WebInspect HLI analysis to find information for CVEs including a brief summary by using Common Platform Enumeration(CPE) queries. The database is maintained by the National Institute of Standards and Technology (NIST)."} </style>

Known NVD records for:
cpe:2.3:a:momentjs:moment:2.29.1


VULNERABILITY:FOUND VERSION:FIXED VERSION:SEVERITY:
CVE-2022-247852.29.12.29.2
High
 Moment.js is a JavaScript date library for parsing, validating, manipulating, and formatting dates. A path traversal vulnerability impacts npm (server) users of Moment.js between versions 1.0.1 and 2.29.1, especially if a user-provided locale string is directly used to switch moment locale. This problem is patched in 2.29.2, and the patch can be applied to all affected versions. As a workaround, sanitize the user-provided locale name before passing it to Moment.js.

VULNERABILITY:FOUND VERSION:FIXED VERSION:SEVERITY:
CVE-2022-311292.29.12.29.4
High
 moment is a JavaScript date library for parsing, validating, manipulating, and formatting dates. Affected versions of moment were found to use an inefficient parsing algorithm. Specifically using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs. Users may notice a noticeable slowdown is observed with inputs above 10k characters. Users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks. The problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking. Users are advised to upgrade. Users unable to upgrade should consider limiting date lengths accepted from user input.

Removed Issues

  • No removed issues were detected