2023-01-10 Hostedscan Report
2023-01-10 Hostedscan Report
2023-01-10 Hostedscan Report
BY
HostedScan Security
GENERATED ON 1/10/2023
Report Summary
Passive Web Application Vulnerabilities
Active Web Application Vulnerabilities
SSL/TLS Security
Network Vulnerabilities
Open TCP Ports
Open UDP Ports
This report contains information on all of the risks found from your vulnerability scans. Each risk is assigned a threat level (high,
medium, or low).
Total Risks
Total number of risks found by severity.
3
13
2
0
The OWASP ZAP passive web application scan crawls the pages of a web application. It inspects the web pages as well as the
requests and responses sent between the server. The passive scan checks for vulnerabilities such as cross-domain
misconfigurations, insecure cookies, vulnerable js dependencies, and more.
Total Risks
Total number of risks found by the passive web application vulnerability scan.
0
2
1
0
Risks Summary
Summary of detected risks.
Open Accepted
Threat Level Title
Count Count
A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target
destination without their knowledge or intent in order to perform an action as the victim. The underlying
cause is application functionality using predictable URL/form actions in a repeatable way. The nature of
the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting
(XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-
site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session
riding, confused deputy, and sea surf.
CSRF has primarily been used to perform an action against a target site using the victim's privileges, but
recent techniques have been discovered to disclose information by gaining access to the response. The
risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because
XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-
origin policy.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that
make this weakness easier to avoid.
Phase: Implementation
Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be
bypassed using attacker-controlled script.
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of
the form. Be sure that the nonce is not predictable (CWE-330).
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate
confirmation request to ensure that the user intended to perform that operation.
Do not use the GET method for any request that triggers a state change.
Phase: Implementation
Check the HTTP Referer header to see if the request originated from an expected page. This could break
legitimate functionality, because users or proxies may have disabled sending the Referer for privacy
reasons.
CWE Id 352
WASC Id 9
https://riobalitours.com/
The response does not include either Content-Security-Policy with 'frame-ancestors' directive or X-Frame-
Description
Options to protect against 'ClickJacking' attacks.
Modern Web browsers support the Content-Security-Policy and X-Frame-Options HTTP headers. Ensure
one of them is set on all web pages returned by your site/app.
Solution If you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll
want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY.
Alternatively consider implementing Content Security Policy's "frame-ancestors" directive.
Reference https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
CWE Id 1021
WASC Id 15
Other
Information
https://riobalitours.com/
Review the source code of this page. Implement custom error pages. Consider implementing a mechanism
Solution to provide a unique error reference/identifier to the client (browser) while logging the details on the server
side and not exposing them to the user.
Reference
CWE Id 200
WASC Id 13
Other
Information
https://riobalitours.com/
The OWASP ZAP active web application scan crawls the pages of a web application. It scans for all of the passive scan checks and
additionally makes requests and submits forms to actively test for more vulnerabilities. The active scan checks for vulnerabilities
such as SQL injection, remote command execution, XSS, and more.
Total Risks
Total number of risks found by the active web application vulnerability scan.
1
4
1
0
Risks Summary
Summary of detected risks.
Open Accepted
Threat Level Title
Count Count
Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's
browser instance. A browser instance can be a standard web browser client, or a browser object
embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client.
The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java,
Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security
context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify
and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her
account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent
content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the
trust relationship between a user and the web site. Applications utilizing browser object instances which
load content from the file system may execute code under the local machine zone allowing for system
compromise.
Description There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced
with malicious code, or visit a malicious web page containing a web form, which when posted to the
vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the
vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted
automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link
or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the
user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by
using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period
of time. Examples of an attacker's favorite targets often include message board posts, web mail
messages, and web chat software. The unsuspecting user is not required to interact with any additional
site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing
the code.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that
make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include
Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
Understand the context in which your data will be used and the encoding that will be expected. This is
especially important when transmitting data between different components, or when generating outputs
that can contain multiple encodings at the same time, such as web pages or multi-part mail messages.
Study all expected communication protocols and data representations to determine the required encoding
strategies.
For any data that will be output to another web page, especially any data that was received from external
inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are
needed.
For any security checks that are performed on the client side, ensure that these checks are duplicated on
the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying
values after the checks have been performed, or by changing the client to remove the client-side checks
entirely. Then, these modified values would be submitted to the server.
If available, use structured mechanisms that automatically enforce the separation between data and
code. These mechanisms may be able to provide the relevant quoting, encoding, and validation
Solution automatically, instead of relying on the developer to provide this capability at every point where output is
generated.
Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8.
When an encoding is not specified, the web browser may choose a different encoding by guessing which
encoding is actually being used by the web page. This can cause the web browser to treat certain
sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations
related to encoding/escaping.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In
browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and
Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side
scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all
browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read
access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use an allow list of
acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to
specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or
malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential
attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of
input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields,
and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid
because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as
"red" or "blue."
Ensure that you perform input validation at well-defined interfaces within the application. This will help
protect the application even if a component is reused or moved elsewhere.
http://projects.webappsec.org/Cross-Site-Scripting
Reference
http://cwe.mitre.org/data/definitions/79.html
CWE Id 79
Other
Information
https://riobalitours.com/
A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target
destination without their knowledge or intent in order to perform an action as the victim. The underlying
cause is application functionality using predictable URL/form actions in a repeatable way. The nature of
the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting
(XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-
site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session
riding, confused deputy, and sea surf.
CSRF has primarily been used to perform an action against a target site using the victim's privileges, but
recent techniques have been discovered to disclose information by gaining access to the response. The
risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because
XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-
origin policy.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that
make this weakness easier to avoid.
Phase: Implementation
Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be
bypassed using attacker-controlled script.
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of
the form. Be sure that the nonce is not predictable (CWE-330).
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate
confirmation request to ensure that the user intended to perform that operation.
Do not use the GET method for any request that triggers a state change.
Phase: Implementation
Check the HTTP Referer header to see if the request originated from an expected page. This could break
legitimate functionality, because users or proxies may have disabled sending the Referer for privacy
reasons.
http://projects.webappsec.org/Cross-Site-Request-Forgery
Reference
http://cwe.mitre.org/data/definitions/352.html
CWE Id 352
WASC Id 9
https://riobalitours.com/
It is possible to view the directory listing. Directory listing may reveal hidden scripts, include files, backup
Description
source files, etc. which can be accessed to read sensitive information.
http://httpd.apache.org/docs/mod/core.html#options
Reference
http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html
CWE Id 548
WASC Id 48
Other
Information
https://riobalitours.com/
Parameter manipulation caused an error page or Java stack trace to be displayed. This indicated lack of
Description
exception handling and potential areas for further exploit.
Identify the cause of the error and fix it. Do not trust client side input and enforce a tight check in the server
Solution
side. Besides, catch the exception properly. Use a generic 500 error page for internal server error.
Reference
CWE Id 472
WASC Id 20
Other
Information
https://riobalitours.com/
The response does not include either Content-Security-Policy with 'frame-ancestors' directive or X-Frame-
Description
Options to protect against 'ClickJacking' attacks.
Reference https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
CWE Id 1021
WASC Id 15
Other
Information
https://riobalitours.com/
This page contains an error/warning message that may disclose sensitive information like the location of
the file that produced the unhandled exception. This information can be used to launch further attacks
Description
against the web application. The alert could be a false positive if the error message is found inside a
documentation page.
Review the source code of this page. Implement custom error pages. Consider implementing a mechanism
Solution to provide a unique error reference/identifier to the client (browser) while logging the details on the server
side and not exposing them to the user.
Reference
CWE Id 200
WASC Id 13
Other
Information
https://riobalitours.com/
The SSLyze security scan checks for misconfigured SSL/TLS certificates, expired certificates, weak ciphers, and SSL/TLS
vulnerabilities such as Heartbleed.
Total Risks
Total number of risks found by the SSL/TLS security scan.
0
0
0
0
The OpenVAS network vulnerability scan tests servers and network connected devices for over 50,000 vulnerabilities.
Total Risks
Total number of risks found by the network vulnerability scan.
2
2
0
0
Risks Summary
Summary of detected risks.
HIGH Diffie-Hellman Ephemeral Key Exchange DoS Vulnerability (SSL/TLS, D(HE)ater) 7.5 1 0
HIGH Diffie-Hellman Ephemeral Key Exchange DoS Vulnerability (SSL/TLS, D(HE)ater) 7.5 1 0
type nvt
cvss_base 7.5
score 7.5
type cvss_base_v3
origin NVD
severities
severity date 2021-11-16T15:36:00Z
score 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/
value
A:H
cvss_base_
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vector
affected
tags
impact
solution_ty
Mitigation
pe
type Mitigation
type cve
id CVE-2002-20001
type url
https://www.researchgate.net/profile/Ant
on-Stiglic-
id 2/publication/2401745_Security_Issues_i
n_the_Diffie-
Hellman_Key_Agreement_Protocol
type url
id https://github.com/Balasys/dheater
type cert-bund
id WID-SEC-2022-2251
type cert-bund
refs ref
id WID-SEC-2022-2000
type cert-bund
id CB-K22/0224
type cert-bund
id CB-K21/1276
type dfn-cert
id DFN-CERT-2022-2147
type dfn-cert
id DFN-CERT-2022-0437
type dfn-cert
id DFN-CERT-2021-2622
threat High
severity 7.5
https://riobalitours.com/
nvt
oid 1.3.6.1.4.1.25623.1.0.117840
type nvt
cvss_base 7.5
score 7.5
type cvss_base_v3
origin NVD
severities
date 2021-11-16T15:36:00Z
severity
score 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/
value
A:H
affected
tags
impact
solution_ty
Mitigation
pe
type Mitigation
refs
id CVE-2002-20001
type url
https://www.researchgate.net/profile/Ant
on-Stiglic-
id 2/publication/2401745_Security_Issues_i
n_the_Diffie-
Hellman_Key_Agreement_Protocol
type url
id https://github.com/Balasys/dheater
type cert-bund
id WID-SEC-2022-2251
type cert-bund
ref
id WID-SEC-2022-2000
type cert-bund
id CB-K22/0224
type cert-bund
id CB-K21/1276
type dfn-cert
id DFN-CERT-2022-2147
type dfn-cert
id DFN-CERT-2022-0437
type dfn-cert
id DFN-CERT-2021-2622
threat High
severity 7.5
value 30
qod
type
https://riobalitours.com/
type nvt
cvss_base 5.0
score 5.0
type cvss_base_v2
origin
severities
severity date 2005-11-03T13:08:04Z
score 5.0
value AV:N/AC:L/Au:N/C:P/I:N/A:N
cvss_base_
AV:N/AC:L/Au:N/C:P/I:N/A:N
vector
insight
affected
impact
tags
1) Disable this feature by changing 'UserDir public_html' (or
whatever) to
'UserDir disabled'.
Or
2) Use a RedirectMatch rewrite
rule under Apache -- this works even if there
is no such entry in the
password file, e.g.:
RedirectMatch ^/~(.*)$ http://example.com/$1
solution
Or
3) Add into httpd.conf:
ErrorDocument 404
http://example.com/sample.html
ErrorDocument 403
http://example.com/sample.html
(NOTE: You need to use a FQDN
inside the URL for it to work properly).
vuldetect
solution_ty
Mitigation
pe
type Mitigation
id CVE-2001-1013
type url
http://www.securiteam.com/unixfocus/5
id
WP0C1F5FI.html
type url
refs ref
id http://www.securityfocus.com/bid/3335
type cert-bund
id CB-K14/0304
type dfn-cert
id DFN-CERT-2014-0315
threat Medium
severity 5.0
id b7582562-2069-455e-aacf-166d34118b38
name product
cpe:/a:apache:http_se
value
rver
name location
value 80/tcp
detection result
details detail
name source_oid
1.3.6.1.4.1.25623.1.0.1
value
17232
name source_name
value 70
qod
type
https://riobalitours.com/
oid 1.3.6.1.4.1.25623.1.0.111074
type nvt
cvss_base 5.0
score 5.0
type cvss_base_v2
origin
severities
severity date 2015-12-26T14:00:00Z
score 5.0
value AV:N/AC:L/Au:N/C:P/I:N/A:N
cvss_base_
AV:N/AC:L/Au:N/C:P/I:N/A:N
vector
insight
solution_ty
Mitigation
pe
type url
threat Medium
severity 5.0
https://riobalitours.com/
The NMAP TCP port scan discovers open ports on with a complete scan of ports 0 to 65535.
Total Risks
Total number of risks found by the TCP port scan.
0
5
0
0
Open Accepted
Threat Level Title
Count Count
An open port may be an expected configuration. For example, web servers use port 80 to serve websites
over http and port 443 to serve websites over https. For a list of commonly used ports see
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
Details
An unexpected open port could give unintended access to applications, data, and private networks. Open
ports can also be dangerous when expected services are out of date and exploited through security
vulnerabilities.
https://riobalitours.com/
An open port may be an expected configuration. For example, web servers use port 80 to serve websites
over http and port 443 to serve websites over https. For a list of commonly used ports see
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
Details
An unexpected open port could give unintended access to applications, data, and private networks. Open
ports can also be dangerous when expected services are out of date and exploited through security
vulnerabilities.
https://riobalitours.com/
An open port may be an expected configuration. For example, web servers use port 80 to serve websites
over http and port 443 to serve websites over https. For a list of commonly used ports see
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
Details
An unexpected open port could give unintended access to applications, data, and private networks. Open
ports can also be dangerous when expected services are out of date and exploited through security
vulnerabilities.
https://riobalitours.com/
An open port may be an expected configuration. For example, web servers use port 80 to serve websites
over http and port 443 to serve websites over https. For a list of commonly used ports see
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
Details
An unexpected open port could give unintended access to applications, data, and private networks. Open
ports can also be dangerous when expected services are out of date and exploited through security
vulnerabilities.
https://riobalitours.com/
An open port may be an expected configuration. For example, web servers use port 80 to serve websites
over http and port 443 to serve websites over https. For a list of commonly used ports see
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
Details
An unexpected open port could give unintended access to applications, data, and private networks. Open
ports can also be dangerous when expected services are out of date and exploited through security
vulnerabilities.
https://riobalitours.com/
The NMAP UDP port scan discovers open ports of common UDP services.
Total Risks
Total number of risks found by the UDP port scan.
0
0
0
0