DAST Report
Report overview
This OWASP Top 10 report lists all examples of vulnerabilities on the OWASP Top 10 list that were found during the scan. The OWASP Top 10 is a regularly-updated list of the most critical security risks. The scan also found 2 other issues that are not in OWASP Top 10 (2021)
| Site name: | test-mysite |
|---|---|
Start URLs: | 1 |
| Start: | 2023-08-25 6:43 AM |
|---|---|
End: | 2023-08-25 6:52 AM |
Duration: | 9m 37s |
Status: | Completed |
Issues found on https://handsonprojects.online
A01:2021 – Broken Access Control - 2 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Info | Certain | View |
/robots.txt | Info | Certain | View |
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Low | Certain | View |
/robots.txt | Low | Certain | View |
A02:2021 – Cryptographic Failures - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Low | Certain | View |
/robots.txt | Low | Certain | View |
A03:2021 – Injection - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Info | Firm | View |
A04:2021 – Insecure Design - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/robots.txt | Info | Certain | View |
/ | Info | Certain | View |
A05:2021 – Security Misconfiguration - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Info | Firm | View |
A07:2021 – Identification and Authentication Failures - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Medium | Certain | View |
A08:2021 – Software and Data Integrity Failures - 1 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Info | Certain | View |
Uncategorized - 2 issues found
| URL | Severity | Confidence | |
|---|---|---|---|
/ | Info | Certain | View |
| URL | Severity | Confidence | |
|---|---|---|---|
/robots.txt | Info | Certain | View |
Issue details for https://handsonprojects.online
Issue detail:
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.
Issue background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.
If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.
Issue remediation
Any inappropriate domains should be removed from the CORS policy.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://handsonprojects.online
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:50:28 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Access-Control-Allow-Origin: https://handsonprojects.online Vary: Origin, Accept-Encoding Access-Control-Allow-Credentials: true Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
Issue detail:
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.
Issue background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.
If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.
Issue remediation
Any inappropriate domains should be removed from the CORS policy.
References
Vulnerability classifications
Request:
GET /robots.txt HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://handsonprojects.online
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:51:39 GMT Content-Type: text/plain Content-Length: 115 Connection: close X-Powered-By: Express Access-Control-Allow-Origin: https://handsonprojects.online Vary: Origin, Accept-Encoding Access-Control-Allow-Credentials: true ETag: "28b1e4dc0de8ab706bc82d8dc4612a7e" Cache-Control: public, max-age=3600 User-agent: * Sitemap: http://handsonprojects.online/sitemap.xml Disallow: /ghost/ Disallow: /p/ Disallow: /email/
Issue detail:
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request which trusts websites accessed using unencrypted communications.
Issue background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.
If a site allows interaction from an origin that uses unencrypted HTTP communications, then it is vulnerable to an attacker who is in a position to view and modify a user's unencrypted network traffic. The attacker can control the responses from unencrypted origins, thereby injecting content that is able to interact with the application that publishes the policy. This means that the application is effectively extending trust to all such attackers, thereby undoing much of the benefit of using HTTPS communications.
Issue remediation
Only trust origins that use encrypted HTTPS communications.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: http://handsonprojects.online
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:50:35 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Access-Control-Allow-Origin: http://handsonprojects.online Vary: Origin, Accept-Encoding Access-Control-Allow-Credentials: true Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
Issue detail:
The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request which trusts websites accessed using unencrypted communications.
Issue background
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.
If a site allows interaction from an origin that uses unencrypted HTTP communications, then it is vulnerable to an attacker who is in a position to view and modify a user's unencrypted network traffic. The attacker can control the responses from unencrypted origins, thereby injecting content that is able to interact with the application that publishes the policy. This means that the application is effectively extending trust to all such attackers, thereby undoing much of the benefit of using HTTPS communications.
Issue remediation
Only trust origins that use encrypted HTTPS communications.
References
Vulnerability classifications
Request:
GET /robots.txt HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: http://handsonprojects.online
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:51:46 GMT Content-Type: text/plain Content-Length: 115 Connection: close X-Powered-By: Express Access-Control-Allow-Origin: http://handsonprojects.online Vary: Origin, Accept-Encoding Access-Control-Allow-Credentials: true ETag: "28b1e4dc0de8ab706bc82d8dc4612a7e" Cache-Control: public, max-age=3600 User-agent: * Sitemap: http://handsonprojects.online/sitemap.xml Disallow: /ghost/ Disallow: /p/ Disallow: /email/
Issue description
The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.
To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic.This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.
Issue remediation
The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.
Note that because HSTS is a "trust on first use" (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
Issue description
The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.
To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic.This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.
Issue remediation
The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.
Note that because HSTS is a "trust on first use" (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.
References
Vulnerability classifications
Request:
GET /robots.txt HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:46:19 GMT Content-Type: text/plain Content-Length: 115 Connection: close X-Powered-By: Express ETag: "28b1e4dc0de8ab706bc82d8dc4612a7e" Cache-Control: public, max-age=3600 Vary: Accept-Encoding User-agent: * Sitemap: http://handsonprojects.online/sitemap.xml Disallow: /ghost/ Disallow: /p/ Disallow: /email/
Issue detail:
The application may be vulnerable to DOM-based DOM data manipulation. Data is read from window.location.search and passed to window.history.pushState().
Issue background
DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.
DOM data manipulation arises when a script writes controllable data to a field within the DOM that is used within the visible UI or client-side application logic. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the appearance or behavior of the client-side UI. An attacker may be able to leverage this to perform virtual defacement of the application, or possibly to induce the user to perform unintended actions.
Burp Suite automatically identifies this issue using dynamic and static code analysis. Static analysis can lead to false positives that are not actually exploitable. If Burp Scanner has not provided any evidence resulting from dynamic analysis, you should review the relevant code and execution paths to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based DOM data manipulation vulnerabilities is not to dynamically write to DOM data fields any data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from being stored. In general, this is best achieved by using a whitelist of permitted values.
References
Vulnerability classifications
Request 1:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response 1:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
<link rel="alternate" type="application/rss+xml" title="Ghost" href="http://handsonprojects.online/rss/" /> <script defer src="https://unpkg.com/@tryghost/portal@~1.22.0/umd/portal.min.js" data-ghost="http://handsonprojects.online/" crossorigin="anonymous"></script>
Snip
Request 2:
GET /@tryghost/portal@1.22.6/umd/portal.min.js HTTP/2 Host: unpkg.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response 2:
HTTP/2 200 OK Date: Fri, 25 Aug 2023 02:50:23 GMT Content-Type: application/javascript; charset=utf-8 Access-Control-Allow-Origin: * Cache-Control: public, max-age=31536000 Last-Modified: Wed, 18 May 2022 03:15:35 GMT Etag: "79000-M0DLzHAKKwWGpUR+nfOsDIxvZTs" Via: 1.1 fly.io Fly-Request-Id: 01H4Z35YZVPDQBAGB4AC80Z6F4-fra Cf-Cache-Status: HIT Age: 3966147 Vary: Accept-Encoding Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Content-Type-Options: nosniff Server: cloudflare Cf-Ray: 7fc086f748ea4d46-FRA /*! For license information please see portal.min.js.LICENSE.txt */ !function(e){var t={};function n(r){if(t[r])return t[r].exports;var o=t[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.expo
Snip
.d(t,"getUpdatedOfferPrice",(function(){return le})),n.d(t,"isActiveOffer",(function(){return se}));var r=n(4),o=n(6);function i(){var e=window.location.hash.substr(1).split("?"),t=Object(o.a)(e,1)[0];t&&/^\/portal\/?(?:\/(\w+(?:\/\w+)*))?\/?$/.test(t)&&window.history.pushState("",document.title,window.location.pathname+window.location.search)}function a(e){var t=e.page,n={signin:"#/portal/signin",signup:"#/portal/signup"};return Object.keys(n).includes(t)?n[t]:n.default}function l(e){var t=e.page,n=e.siteUrl||"".concat(window.location.prot
Snip
Static analysis:
Data is read from window.location.search and passed to window.history.pushState() via the following statements:
t&&/^\/portal\/?(?:\/(\w+(?:\/\w+)*))?\/?$/.test(t)&&window.history.pushState("",document.title,window.location.pathname+window.location.search)
Issue description
Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.
Issue remediation
Applications should return caching directives instructing browsers not to store local copies of any sensitive data. Often, this can be achieved by configuring the web server to prevent caching for relevant paths within the web root. Alternatively, most web development platforms allow you to control the server's caching directives from within individual scripts. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content:
Cache-control: no-store
Pragma: no-cache
References
Vulnerability classifications
Request:
GET /robots.txt HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:46:19 GMT Content-Type: text/plain Content-Length: 115 Connection: close X-Powered-By: Express ETag: "28b1e4dc0de8ab706bc82d8dc4612a7e" Cache-Control: public, max-age=3600 Vary: Accept-Encoding User-agent: * Sitemap: http://handsonprojects.online/sitemap.xml Disallow: /ghost/ Disallow: /p/ Disallow: /email/
Issue description
Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.
Issue remediation
Applications should return caching directives instructing browsers not to store local copies of any sensitive data. Often, this can be achieved by configuring the web server to prevent caching for relevant paths within the web root. Alternatively, most web development platforms allow you to control the server's caching directives from within individual scripts. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content:
Cache-control: no-store
Pragma: no-cache
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
Issue description
If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.
Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.
You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.
Issue remediation
To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
Issue detail:
The following problems were identified with the server's TLS certificate:
The server's certificate is not valid for the server's hostname.
The server's certificate is not trusted.
Note: Burp relies on the Java trust store to determine whether certificates are trusted. The Java trust store does not include every root CA certificate that is included within browser trust stores. Burp might incorrectly report that a certificate is not trusted, if a valid root CA certificate is being used that is not included in the Java trust store.
The server presented the following certificate:
| Issued to: | Cloudflare |
|---|---|
Issued by: | Managed CA cb11f9f61cfc6626920a10ac200053c1 |
Valid from: | Thu Aug 24 15:07:00 UTC 2023 |
Valid to: | Sun Aug 23 15:07:00 UTC 2026 |
Issue background
TLS (or SSL) helps to protect the confidentiality and integrity of information in transit between the browser and server, and to provide authentication of the server's identity. To serve this purpose, the server must present an TLS certificate that is valid for the server's hostname, is issued by a trusted authority and is valid for the current date. If any one of these requirements is not met, TLS connections to the server will not provide the full protection for which TLS is designed.
It should be noted that various attacks exist against TLS in general, and in the context of HTTPS web connections in particular. It may be possible for a determined and suitably-positioned attacker to compromise TLS connections without user detection even when a valid TLS certificate is used.
References
Vulnerability classifications
Issue detail:
The response dynamically includes the following scripts from other domains:
https://code.jquery.com/jquery-3.5.1.min.js
https://unpkg.com/@tryghost/portal@~1.22.0/umd/portal.min.js
Issue background
When an application includes a script from an external domain, this script is executed by the browser within the security context of the invoking application. The script can therefore do anything that the application's own scripts can do, such as accessing application data and performing actions within the context of the current user.
If you include a script from an external domain, then you are trusting that domain with the data and functionality of your application, and you are trusting the domain's own security to prevent an attacker from modifying the script to perform malicious actions within your application.
Issue remediation
Scripts should ideally not be included from untrusted domains. Applications that rely on static third-party scripts should consider using Subresource Integrity to make browsers verify them, or copying the contents of these scripts onto their own domain and including them from there. If that is not possible (e.g. for licensing reasons) then consider reimplementing the script's functionality within application code.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
</div> <script src="https://code.jquery.com/jquery-3.5.1.min.js" integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=" crossorigin="anonymous"> </script>
Snip
Issue detail:
The response is loaded over HTTPS, but loads other resources over an unencrypted connection. The following "passive" resources are loaded over HTTP. An attacker able to modify traffic could influence the application's appearance and behavior:
http://handsonprojects.online/
http://handsonprojects.online/rss/
Issue background
The application loads pages over HTTPS that load other resources over unencrypted connections. An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with these resources, which may indirectly disclose information about the user's activity on the application itself. Furthermore, an attacker able to modify traffic could alter these resources and potentially influence the application's appearance and behavior. Due to these concerns, users' web browsers may automatically display warnings and disable affected components of the page. As a result, this vulnerability currently has more of an impact on usability than security.
To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.
Issue remediation
Ensure that all external resources the page references are loaded using HTTPS.
References
Vulnerability classifications
Request:
GET / HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:43:47 GMT Content-Type: text/html; charset=utf-8 Connection: close X-Powered-By: Express Cache-Control: public, max-age=0 ETag: W/"2bc3-26TKdCVEoevFNg9vRtvMVgxiwwI" Vary: Accept-Encoding Content-Length: 11203 <!DOCTYPE html> <html lang="en"> <head> <title>Ghost</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="HandheldFriendly" content="Tr
Snip
<meta name="description" content="Thoughts, stories and ideas" /> <link rel="canonical" href="http://handsonprojects.online/" /> <meta name="referrer" content="no-referrer-when-downgrade" />
Snip
<meta name="generator" content="Ghost 4.48" /> <link rel="alternate" type="application/rss+xml" title="Ghost" href="http://handsonprojects.online/rss/" /> <script defer src="https://unpkg.com/@tryghost/portal@~1.22.0/umd/portal.min.js" data-ghost="http://handsonprojects.online/" crossorigin="anonymous">
Snip
Issue detail:
The web server contains a robots.txt file.
Issue background
The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index.
The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.
Issue remediation
The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.
Vulnerability classifications
Request:
GET /robots.txt HTTP/1.1 Host: handsonprojects.online Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Connection: close Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Fri, 25 Aug 2023 02:50:21 GMT Content-Type: text/plain Content-Length: 115 Connection: close X-Powered-By: Express ETag: "28b1e4dc0de8ab706bc82d8dc4612a7e" Cache-Control: public, max-age=3600 Vary: Accept-Encoding User-agent: * Sitemap: http://handsonprojects.online/sitemap.xml Disallow: /ghost/ Disallow: /p/ Disallow: /email/
Scan details
| Site name: | test-mysite |
|---|---|
Start URLs: | https://handsonprojects.online/ |
Scan status: | Completed |
Start time: | 2023-08-25 6:43 AM |
End time: | 2023-08-25 6:52 AM |
Duration: | 9m 37s |
Reference: | #3 |
OS command injection
SQL injection
SQL injection (second order)
ASP.NET tracing enabled
File path traversal
XML external entity injection
LDAP injection
XPath injection
XML injection
ASP.NET debugging enabled
HTTP PUT method is enabled
Out-of-band resource load (HTTP)
File path manipulation
PHP code injection
Server-side JavaScript code injection
Perl code injection
Ruby code injection
Python code injection
Expression Language injection
Unidentified code injection
Server-side template injection
SSI injection
Extension generated issue
BCheck generated issue
TLS certificate
Unencrypted communications
Strict transport security not enforced
Mixed content
Hidden HTTP 2
Cross-site scripting (stored)
HTTP request smuggling
Client-side desync
Web cache poisoning
HTTP response header injection
Cross-site scripting (reflected)
Client-side template injection
Cross-site scripting (DOM-based)
Cross-site scripting (reflected DOM-based)
Cross-site scripting (stored DOM-based)
Client-side prototype pollution
JavaScript injection (DOM-based)
JavaScript injection (reflected DOM-based)
JavaScript injection (stored DOM-based)
Path-relative style sheet import
Client-side SQL injection (DOM-based)
Client-side SQL injection (reflected DOM-based)
Client-side SQL injection (stored DOM-based)
WebSocket URL poisoning (DOM-based)
WebSocket URL poisoning (reflected DOM-based)
WebSocket URL poisoning (stored DOM-based)
Local file path manipulation (DOM-based)
Local file path manipulation (reflected DOM-based)
Local file path manipulation (stored DOM-based)
Client-side XPath injection (DOM-based)
Client-side XPath injection (reflected DOM-based)
Client-side XPath injection (stored DOM-based)
Client-side JSON injection (DOM-based)
Client-side JSON injection (reflected DOM-based)
Client-side JSON injection (stored DOM-based)
Flash cross-domain policy
Silverlight cross-domain policy
GraphQL endpoint found
GraphQL endpoint discovered
GraphQL introspection enabled
GraphQL suggestions enabled
GraphQL content type not validated
Cross-origin resource sharing
Cross-origin resource sharing: arbitrary origin trusted
Cross-origin resource sharing: unencrypted origin trusted
Cross-origin resource sharing: all subdomains trusted
Cross-site request forgery
SMTP header injection
JWT signature not verified
JWT none algorithm supported
JWT self-signed JWK header supported
JWT weak HMAC secret
JWT arbitrary jku header supported
JWT arbitrary x5u header supported
Cleartext submission of password
External service interaction (DNS)
External service interaction (HTTP)
External service interaction (SMTP)
Referer-dependent response
Spoofable client IP address
User agent-dependent response
Password returned in later response
Password submitted using GET method
Password returned in URL query string
SQL statement in request parameter
Cross-domain POST
ASP.NET ViewState without MAC enabled
XML entity expansion
Long redirection response
Serialized object in HTTP message
Duplicate cookies set
Input returned in response (stored)
Input returned in response (reflected)
Suspicious input transformation (reflected)
Suspicious input transformation (stored)
Request URL override
Vulnerable JavaScript dependency
Open redirection (reflected)
Open redirection (stored)
Open redirection (DOM-based)
Open redirection (reflected DOM-based)
Open redirection (stored DOM-based)
TLS cookie without secure flag set
Cookie scoped to parent domain
Cross-domain Referer leakage
Cross-domain script include
Cookie without HttpOnly flag set
Session token in URL
Password field with autocomplete enabled
Password value set in cookie
File upload functionality
Frameable response (potential Clickjacking)
Browser cross-site scripting filter disabled
HTTP TRACE method is enabled
Cookie manipulation (DOM-based)
Cookie manipulation (reflected DOM-based)
Cookie manipulation (stored DOM-based)
Ajax request header manipulation (DOM-based)
Ajax request header manipulation (reflected DOM-based)
Ajax request header manipulation (stored DOM-based)
Denial of service (DOM-based)
Denial of service (reflected DOM-based)
Denial of service (stored DOM-based)
HTML5 web message manipulation (DOM-based)
HTML5 web message manipulation (reflected DOM-based)
HTML5 web message manipulation (stored DOM-based)
HTML5 storage manipulation (DOM-based)
HTML5 storage manipulation (reflected DOM-based)
HTML5 storage manipulation (stored DOM-based)
Link manipulation (DOM-based)
Link manipulation (reflected DOM-based)
Link manipulation (stored DOM-based)
Link manipulation (reflected)
Link manipulation (stored)
Document domain manipulation (DOM-based)
Document domain manipulation (reflected DOM-based)
Document domain manipulation (stored DOM-based)
DOM data manipulation (DOM-based)
DOM data manipulation (reflected DOM-based)
DOM data manipulation (stored DOM-based)
CSS injection (reflected)
CSS injection (stored)
Client-side HTTP parameter pollution (reflected)
Client-side HTTP parameter pollution (stored)
Form action hijacking (reflected)
Form action hijacking (stored)
Database connection string disclosed
Source code disclosure
Backup file
Directory listing
Email addresses disclosed
Private IP addresses disclosed
Social security numbers disclosed
Credit card numbers disclosed
Private key disclosed
Robots.txt file
Json Web Key Set disclosed
JWT private key disclosed
Cacheable HTTPS response
Base64-encoded data in parameter
Multiple content types specified
HTML does not specify charset
HTML uses unrecognized charset
Content type incorrectly stated
Content type is not specified
Last updated
