SECURITY REPORT

Cgpt - https://chaingpt.org

Report generated on Mar. 29, 2023 at 19:17 UTC

Summary
This section contains the scan summary

TARGET https://chaingpt.org Report generated on Mar. 29, 2023 at 19:17 UTC

STARTED ENDED DURATION SCAN PROFILE

Mar. 29, 2023, 19:09 UTC Mar. 29, 2023, 19:11 UTC 2 minutes Security Posture

NUMBER OF FINDINGS TOP 5

CURRENT
FROM LAST
PENDING
Browser content sniffing allowed 1
SCAN SCAN FIX

Missing clickjacking protection 1

HIGH 0 ‒ 0
Missing Content Security Policy header 1

MEDIUM 0 ‒ 0
HSTS header not enforced 1

LOW 4 ‒ 4
Settings
This section contains the summary of settings that were used during this scan

SCAN PROFILE

Security Posture

Security posture scan. Fast scan that checks

vulnerabilities related to SSL/TLS, HTTP
security headers, and cookies attributes.
Technical Summary
The following table summarizes the findings, ordered by their severity

# SEVERITY VULNERABILITY STATE

Missing Content Security Policy header

3 LOW NEW https://chaingpt.org
NOT FIXED

Missing clickjacking protection

2 LOW NEW NOT FIXED
https://chaingpt.org

HSTS header not enforced

4 LOW NEW https://chaingpt.org
NOT FIXED

Browser content sniffing allowed

1 LOW NEW https://chaingpt.org
NOT FIXED
Exhaustive Test List
The following pages contain the list of vulnerabilities we tested in this scan, taking into consideration the
chosen profile

Cookie without HttpOnly flag TLS Downgrade attack prevention not supported

Missing clickjacking protection Certificate without revocation information

SSL cookie without Secure flag HSTS header set in HTTP

Unencrypted communications HSTS header with low duration and no subdomain

protection

HSTS header not enforced HSTS header with low duration

Certificate with insufficient key size or usage, or HSTS header does not protect subdomains
insecure signature algorithm

Expired TLS certificate Insecure SSL protocol version 2 supported

Insecure SSL protocol version 3 supported Browser XSS protection disabled

Deprecated TLS protocol version 1.0 supported Browser content sniffing allowed

Deprecated TLS protocol version 1.1 supported Referrer policy not defined

Secure TLS protocol version 1.2 not supported Insecure referrer policy

Weak cipher suites enabled Potential DoS on TLS Client Renegotiation

Server Cipher Order not configured TLS certificate about to expire

Untrusted TLS certificate Invalid referrer policy

Heartbleed Missing Content Security Policy header

Secure Renegotiation is not supported Insecure Content Security Policy

Detailed Finding Descriptions
This section contains the findings in more detail, ordered by severity

# 3 Missing Content Security Policy header

CVSS SCORE
LOW
3.7
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

METHOD PATH

GET https://chaingpt.org

DESCRIPTION

The Content Security Policy (CSP) is an HTTP header through which site owners define a set of security rules that the browser must
follow when rendering their site. The most common usage is to define a list of approved sources of content that the browser can lo
ad. This can be used to effectively mitigate Cross-Site Scripting (XSS) and Clickjacking attacks.

CSP is flexible enough for you to define from where the browser can load JavaScript, Stylesheets, images, or fonts, among other op
tions. It can also be used in report mode only, a recommended approach before deploying strict rules in a live environment. Howev
er, please note that report mode does not protect you, it just logs policy violations.

EVIDENCE

Response headers, missing the Content-Security-Policy header:

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

REQUEST

GET / HTTP/1.1

Host: chaingpt.org

User-Agent: Mozilla/5.0 (compatible; +https://probely.com/sos) ProbelyMRKT/0.1.0

Accept: */*

Accept-Encoding: gzip, deflate

RESPONSE

HTTP/1.1 301 Moved Permanently

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

<html>

<head><title>301 Moved Permanently</title></head>

<body>

<center><h1>301 Moved Permanently</h1></center>

<hr><center>openresty</center>

</body>

</html>

 # 2 Missing clickjacking protection

CVSS SCORE
LOW 6.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

METHOD PATH

GET https://chaingpt.org

DESCRIPTION

A frameable response occurs when one or multiple pages can be used on an iframe on any website. This allows the clickjackin
g attack to be used.

Clickjacking is when an attacker a hidden iframe with multiple transparent or opaque layers above it, to trick a user into clicking
on a button or link on the iframe when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clic
ks meant for the top level page and routing them to the iframe.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text bo
xes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an inv
isible frame controlled by the attacker.

EVIDENCE

Response headers, missing the X-Frame-Options header:

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

REQUEST

GET / HTTP/1.1

Host: chaingpt.org

User-Agent: Mozilla/5.0 (compatible; +https://probely.com/sos) ProbelyMRKT/0.1.0

Accept: */*

Accept-Encoding: gzip, deflate

RESPONSE

HTTP/1.1 301 Moved Permanently

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

<html>

<head><title>301 Moved Permanently</title></head>

<body>

<center><h1>301 Moved Permanently</h1></center>

<hr><center>openresty</center>

</body>

</html>

 # 4 HSTS header not enforced

CVSS SCORE
LOW
7.4
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

METHOD PATH

GET https://chaingpt.org

DESCRIPTION

The application does not force users to connect over an encrypted channel, i.e. over HTTPS. If the user types the site address in th
e browser without starting with https, it will connect to it over an insecure channel, even if there is a redirect to HTTPS later. Even
if the user types https, there may be links to the site in HTTP, forcing the user to navigate insecurely. An attacker that is able to in
tercept traffic between the victim and the site or spoof the site's address can prevent the user from ever connecting to it over an
encrypted channel. This way, the attacker is able to eavesdrop all communications between the victim and the server, including th
e victim's credentials, session cookie and other sensitive information.

EVIDENCE

Response headers, missing the Strict-Transport-Security header:

HTTP/1.1 301 Moved Permanently

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

REQUEST

GET / HTTP/1.1

Host: chaingpt.org

User-Agent: Mozilla/5.0 (compatible; +https://probely.com/sos) ProbelyMRKT/0.1.0

Accept: */*

Accept-Encoding: gzip, deflate

RESPONSE

HTTP/1.1 301 Moved Permanently

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

<html>

<head><title>301 Moved Permanently</title></head>

<body>

<center><h1>301 Moved Permanently</h1></center>

<hr><center>openresty</center>

</body>

</html>

 # 1 Browser content sniffing allowed

CVSS SCORE
LOW
4.7
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N

METHOD PATH

GET https://chaingpt.org

DESCRIPTION

The application allows browsers to try to mime-sniff the content-type of the responses. This means the browser may try to guess t
he content-type by looking at the response content, and render it in way it was not intended to. This behavior may lead to the exe
cution of malicious code, for instance, to explore an XSS vulnerability.

Applications should disable this behavior, forcing browsers to honor the content-type specified in the response. Without a specific c
ontent-type set browsers will default to render the content as text, turning XSS payloads innocuous.

Disabling mime-sniffing should be seen as an extra layer of defense against XSS, and not as replacement of the recommended XSS
prevention techniques.

EVIDENCE

Response headers, missing the X-Content-Type-Options header:

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

REQUEST

GET / HTTP/1.1

Host: chaingpt.org

User-Agent: Mozilla/5.0 (compatible; +https://probely.com/sos) ProbelyMRKT/0.1.0

Accept: */*

Accept-Encoding: gzip, deflate

RESPONSE

HTTP/1.1 301 Moved Permanently

Date: Wed, 29 Mar 2023 19:09:20 GMT

Content-Type: text/html

Content-Length: 166

Connection: keep-alive

Location: https://www.chaingpt.org/

<html>

<head><title>301 Moved Permanently</title></head>

<body>

<center><h1>301 Moved Permanently</h1></center>

<hr><center>openresty</center>

</body>

</html>

Glossary
Term Definition

A type of security weakness that might occur in applications (e.g. Broken Authentication,
Information Disclosure).

Vulnerability
Some vulnerabilities take their name not from the weakness itself, but from the attack that exploits
it (e.g. SQL Injection, XSS, etc.).

Findings An instance of a Vulnerability that was found in an application.

Severity Legend
To each finding is attributed a severity which sums up its overall risk

The severity is a compound metric that encompasses the likelihood of the finding being found and exploited
by an attacker, the skill required to exploit it, and the impact of such exploitation. A finding that is easy to
find, easy to exploit and the exploitation has high impact, will have a greater severity.

Different findings of the same type could have a different severity: we consider multiple factors to increase
or decrease it, such as if the application has an authenticated area or not.

The following table describes the different severities:

Severity Description Examples

These findings may have a direct impact in the application security,

SQL Injection

HIGH either clients or service owners, for instance by granting the

OS Command Injection
attacker access to sensitive information.

Medium findings usually don't have immediate impact alone, but

Cross-site Request Forgery

MEDIUM combined with other findings may lead to a successful compromise

Unencrypted Communications
of the application.

Findings where either the exploit is not trivial, the impact is low, or Directory Listing

LOW
the finding cannot be exploited by itself. Clickjacking
Category Descriptions
The following pages contain descriptions of each vulnerability. For each vulnerability you will find a section
explaining its impact, causes and prevention methods.

These descriptions are very generic, and whenever they are not enough to understand or fix a given finding,
more information is provided for that finding in the Detailed Finding Descriptions section.

Missing Content Security Policy header

Description

The Content Security Policy (CSP) is an HTTP header through which site owners define a set of security rules that the browser must follow
when rendering their site. The most common usage is to define a list of approved sources of content that the browser can load. This can be
used to effectively mitigate Cross-Site Scripting (XSS) and Clickjacking attacks.

CSP is flexible enough for you to define from where the browser can load JavaScript, Stylesheets, images, or fonts, among other options. It can
also be used in report mode only, a recommended approach before deploying strict rules in a live environment. However, please note that
report mode does not protect you, it just logs policy violations.

Fix

You can define a Content Security Policy by setting a header in your application. The header can look like this:

Content-Security-Policy: frame-ancestors 'none'; default-src 'self', script-src '*://*.example.com:*'

In this example, the frame-ancestors directive set to 'none' indicates that the page cannot be placed inside a frame, not even by itself.
The
default-src defines the loading policy for all resources, in this case, they can be loaded from the current origin (protocol + domain + port).
The example sets a more specific policy for scripts, through the script-src, restricting script loading to any subdomain of example.com.

The policy can be with different directives, and there are other less strict options for the directives above.

Missing clickjacking protection

Description

A frameable response occurs when one or multiple pages can be used on an iframe on any website. This allows the clickjacking attack to
be used.

Clickjacking is when an attacker a hidden iframe with multiple transparent or opaque layers above it, to trick a user into clicking on a button
or link on the iframe when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for the top
level page and routing them to the iframe.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user
can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled
by the attacker.

Fix

The recommended way to prevent clickjacking is to send a header that instructs the browser to not allow arbitrary framing, typically from other
domains.

The current recommendation is to use the Content-Security-Policy HTTP header (CSP) with a frame-ancestors directive. This header obsoletes
the X-Frame-Options HTTP header.

To use CSP you need the following header:

Content-Security-Policy: frame-ancestors 'none'

The header might contain more directives, and there are other less strict options for the frame-ancestors directive.

If you want to use X-Frame-Options, send the proper HTTP header, with one of the following directives:

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

A third directive, ALLOW-FROM is no longer supported by modern browsers.

If you specify DENY, all attempts to load the page in a frame will fail. SAMEORIGIN will allow the page to be loaded in the site including it in
a frame is the same as the one serving the page.

The most common option is DENY when there is no need to load your pages on some other site.

HSTS header not enforced

Description

The application does not force users to connect over an encrypted channel, i.e. over HTTPS. If the user types the site address in the browser
without starting with https, it will connect to it over an insecure channel, even if there is a redirect to HTTPS later. Even if the user types https,
there may be links to the site in HTTP, forcing the user to navigate insecurely. An attacker that is able to intercept traffic between the victim
and the site or spoof the site's address can prevent the user from ever connecting to it over an encrypted channel. This way, the attacker is
able to eavesdrop all communications between the victim and the server, including the victim's credentials, session cookie and other sensitive
information.

Fix

The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security
(HSTS).

You can do so by sending the Strict-Transport-Security header so that browsers will always enforce a secure connection to your site,
regardless of the user typing https in the address.

An HSTS enabled server includes the following header in an HTTPS response: Strict-Transport-Security: max-
age=15768000;includeSubdomains
Please bear in mind that only HTTPS responses should have the HSTS header, because browsers ignore this
header when sent over HTTP.

When the browser sees this, it will remember, for the given number of seconds, that the current domain should only be contacted over HTTPS.
In the future, if the user types http:// or omits the scheme, HTTPS is the default. In this example, which includes the option
includeSubdomains, all requests to URLs in the current domain and subdomains will go over HTTPS. When you set includeSubdomains make
sure you can serve all requests over HTTPS! It is, however, important that you add the option includeSubdomains whenever is possible.

Instead of changing your application, you should have the web server setting the header for you. If you are using Apache, just enable
mod_headers and add the following line to your virtual host configuration: Header always set Strict-Transport-Security "max-
age=15768000;includeSubdomains"

If you are using NGINX, just add this line to your host configuration: add_header Strict-Transport-Security max-
age=15768000;includeSubdomains

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 may therefore be vulnerable to aforementioned SSL stripping attacks. To mitigate this risk, you can optionally ask the browser
vendors to include your domain in a preloaded list, included in the browser, and afterwards add the 'preload' flag to the HSTS header.

Browser content sniffing allowed

Description

The application allows browsers to try to mime-sniff the content-type of the responses. This means the browser may try to guess the content-
type by looking at the response content, and render it in way it was not intended to. This behavior may lead to the execution of malicious
code, for instance, to explore an XSS vulnerability.

Applications should disable this behavior, forcing browsers to honor the content-type specified in the response. Without a specific content-type
set browsers will default to render the content as text, turning XSS payloads innocuous.

Disabling mime-sniffing should be seen as an extra layer of defense against XSS, and not as replacement of the recommended XSS prevention
techniques.

Fix

This problem can be fixed by sending the header X-Content-Type-Options with value nosniff, to force browsers to disable the content-type
guessing (the sniffing).

The header should look this:

X-Content-Type-Options: nosniff

It is normally easy to enable the header in the web server configuration file, but it can also be done at application level.