TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

This QID will be marked as a Fail for PCI as of May 1st, 2017 in accordance with the new standards. For existing implementations, Merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation and Migration Plan, which will result in a pass for PCI up until June 30th, 2018.

Further details can be found at: NEW PCI DSS v3.2 and Migrating from SSL and Early TLS v1.1

]]> For example: An attacker could force a downgrade from the TLS protocol to the older SSLv3.0 protocol and exploit the POODLE vulnerability, read secure communications or maliciously modify messages.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

]]> 0 SSL/TLS protocols use ciphers such as AES,DES, 3DES and RC4 to encrypt the content of the higher layer protocols and thus provide the confidentiality service. Normally the output of an encryption process is a sequence of random looking bytes. It was known that RC4 output has some bias in the output. Recently a group of researchers has discovered that the there is a stronger bias in RC4, which make statistical analysis of ciphertext more practical.

The described attack is to inject a malicious javascript into the victim's browser that would ensure that there are multiple connections being established with a target website and the same HTTP cookie is sent multiple times to the website in encrypted form. This provides the attacker a large set of ciphertext samples, that can be used for statistical analysis.

NOTE: On 3/12/15 NVD changed the CVSS v2 access complicity from high to medium. As a result Qualys revised the CVSS score to 4.3 immediately. On 5/4/15 Qualys is also revising the severity to level 3.]]> This attack is not very practical as it requires the attacker to have access to millions of samples of ciphertext, but there are certain assumptions that an attacker can make to improve the chances of recovering the cleartext from cihpertext. For examples HTTP cookies are either base64 encoded or hex digits. This information can help the attacker in their efforts to recover the cookie.]]> 1 Since RDP transfers sensitive information about the user and the system, it can be configured to use encryption to provide privacy and integrity for its sessions. It is possible to configure RDP to use encryption algorithms that are considered insecure, such as RC4 40bit and RC4 56 bit.]]> To configure RDP encryption methods 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' snap-in can be launched in mmc.exe.
In 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' properties dialog box General tab for the Encryption Level 'High' should be selected.

On Windows XP the RDP configuration can be found under Computer Configuration\Administrative Templates\Windows Components\Terminal Services and User Configuration\Administrative Templates\Windows Components\Terminal Services. Under Encryption and Security item, double click on 'Set client connection encryption level' and enable the policy and select high for the 'Encryption level'.

For more details on configuration on 2008 R2 systems see Configure Server Authentication and Encryption Levels.
For more detail on disabling RC4 see Microsoft Update for Disabling RC4.
For details on supporting TLS 1.1 and TLS1.2 for Remote Desktop Services see Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2.
]]> 0 We have sent the following types of packets to trigger the host to send us ICMP replies:

Echo Request (to trigger Echo Reply)
Timestamp Request (to trigger Timestamp Reply)
Address Mask Request (to trigger Address Mask Reply)
UDP Packet (to trigger Port Unreachable Reply)
IP Packet with Protocol >= 250 (to trigger Protocol Unreachable Reply)

Listed in the "Result" section are the ICMP replies that we have received.]]> 0 0 Some operating systems (e.g., MacOS, OpenBSD) use a non-zero, probably random, initial value for the timestamp. For these operating systems, the uptime obtained does not reflect the actual uptime of the host; the former is always larger than the latter.]]> 0 0 Please note that for reliability reasons only the network traffic from open TCP ports is analyzed.]]> 0 0 0 KB2696547 for more details. Workaround:
Customer may consider blocking all versions of SMB at the network boundary by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139, for all boundary devices.]]> 0 0 The Host Scan Time does not have a direct correlation to the Duration time as displayed in the Report Summary section of a scan results report. The Duration is the period of time it takes the service to perform a scan task. The Duration includes the time it takes the service to scan all hosts, which may involve parallel scanning. It also includes the time it takes for a scanner appliance to pick up the scan task and transfer the results back to the service's Secure Operating Center. Further, when a scan task is distributed across multiple scanners, the Duration includes the time it takes to perform parallel host scanning on all scanners.

For host running the Qualys Windows agent this QID reports the time taken by the agent to collect the host metadata used for the most recent assessment scan.]]> 0 0 The service also attempts to authenticate using common credentials. You should verify that the credentials used for successful authentication were those that were provided in the Windows authentication record. User-provided credentials failed if the discovery method shows "Unable to log in using credentials provided by user, fallback to NULL session". If this is the case, verify that the credentials specified in the Windows authentication record are valid for this host.]]> 0 0 The registry key for the Network Level Authentication (NLA) is disabled.

Network Level Authentication is supported on Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2]]> 2671387 to use the automated Microsoft Fix it solution to enable this feature.

As a precaution, always test in a QA or rehearsal environment before rolling out to production.

Note: Client computers that do not support Credential Security Support Provider (CredSSP) protocol will not be able to access servers protected with Network Level Authentication. Windows XP does not support the CredSSP protocol by default.]]> 0 The Results section includes information on the remote access service that was found on the target.

Services like Telnet, Rlogin, SSH, windows remote desktop, pcAnywhere, Citrix Management Console, Remote Admin (RAdmin), VNC, OPENVPN and ISAKMP are checked.]]> 0 0 0 0 0 0 The following is a list of supported SSL ciphers.

Note: If a cipher is included in this list it means that it was possible to establish a SSL connection using that cipher. There are some web servers setups that allow connections to be established using a LOW grade cipher, only to provide a web page stating that the URL is accessible only through a non-LOW grade cipher. In this case even though LOW grade cipher will be listed here QID 38140 will not be reported.

]]> 0 This test determines if SSL session caching is enabled on the host.]]> 0 The Results section displays the port number (Port), the default service listening on the port (IANA Assigned Ports/Services), the description of the service (Description) and the service that the scanner detected using service discovery (Service Detected).]]> CERT Web site.]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 0 A certificate whose Subject commonName or subjectAltName does not match the server FQDN offers only encryption without authentication.

Please note that a false positive reporting of this vulnerability is possible in the following case:

If the common name of the certificate uses a wildcard such as *.somedomainname.com and the reverse DNS resolution of the target IP is not configured. In this case there is no way for Qualys to associate the wildcard common name to the IP. Adding a reverse DNS lookup entry to the target IP will solve this problem.

TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

This QID will be marked as a Fail for PCI as of May 1st, 2017 in accordance with the new standards. For existing implementations, Merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation and Migration Plan, which will result in a pass for PCI up until June 30th, 2018.

Further details can be found at: NEW PCI DSS v3.2 and Migrating from SSL and Early TLS v1.1

]]> For example: An attacker could force a downgrade from the TLS protocol to the older SSLv3.0 protocol and exploit the POODLE vulnerability, read secure communications or maliciously modify messages.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

]]> 0 SSL/TLS protocols use ciphers such as AES,DES, 3DES and RC4 to encrypt the content of the higher layer protocols and thus provide the confidentiality service. Normally the output of an encryption process is a sequence of random looking bytes. It was known that RC4 output has some bias in the output. Recently a group of researchers has discovered that the there is a stronger bias in RC4, which make statistical analysis of ciphertext more practical.

The described attack is to inject a malicious javascript into the victim's browser that would ensure that there are multiple connections being established with a target website and the same HTTP cookie is sent multiple times to the website in encrypted form. This provides the attacker a large set of ciphertext samples, that can be used for statistical analysis.

NOTE: On 3/12/15 NVD changed the CVSS v2 access complicity from high to medium. As a result Qualys revised the CVSS score to 4.3 immediately. On 5/4/15 Qualys is also revising the severity to level 3.]]> This attack is not very practical as it requires the attacker to have access to millions of samples of ciphertext, but there are certain assumptions that an attacker can make to improve the chances of recovering the cleartext from cihpertext. For examples HTTP cookies are either base64 encoded or hex digits. This information can help the attacker in their efforts to recover the cookie.]]> 1 Since RDP transfers sensitive information about the user and the system, it can be configured to use encryption to provide privacy and integrity for its sessions. It is possible to configure RDP to use encryption algorithms that are considered insecure, such as RC4 40bit and RC4 56 bit.]]> To configure RDP encryption methods 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' snap-in can be launched in mmc.exe.
In 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' properties dialog box General tab for the Encryption Level 'High' should be selected.

On Windows XP the RDP configuration can be found under Computer Configuration\Administrative Templates\Windows Components\Terminal Services and User Configuration\Administrative Templates\Windows Components\Terminal Services. Under Encryption and Security item, double click on 'Set client connection encryption level' and enable the policy and select high for the 'Encryption level'.

For more details on configuration on 2008 R2 systems see Configure Server Authentication and Encryption Levels.
For more detail on disabling RC4 see Microsoft Update for Disabling RC4.
For details on supporting TLS 1.1 and TLS1.2 for Remote Desktop Services see Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2.
]]> 0 We have sent the following types of packets to trigger the host to send us ICMP replies:

Echo Request (to trigger Echo Reply)
Timestamp Request (to trigger Timestamp Reply)
Address Mask Request (to trigger Address Mask Reply)
UDP Packet (to trigger Port Unreachable Reply)
IP Packet with Protocol >= 250 (to trigger Protocol Unreachable Reply)

Listed in the "Result" section are the ICMP replies that we have received.]]> 0 0 Some operating systems (e.g., MacOS, OpenBSD) use a non-zero, probably random, initial value for the timestamp. For these operating systems, the uptime obtained does not reflect the actual uptime of the host; the former is always larger than the latter.]]> 0 0 Please note that for reliability reasons only the network traffic from open TCP ports is analyzed.]]> 0 0 0 KB2696547 for more details. Workaround:
Customer may consider blocking all versions of SMB at the network boundary by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139, for all boundary devices.]]> 0 0 The Host Scan Time does not have a direct correlation to the Duration time as displayed in the Report Summary section of a scan results report. The Duration is the period of time it takes the service to perform a scan task. The Duration includes the time it takes the service to scan all hosts, which may involve parallel scanning. It also includes the time it takes for a scanner appliance to pick up the scan task and transfer the results back to the service's Secure Operating Center. Further, when a scan task is distributed across multiple scanners, the Duration includes the time it takes to perform parallel host scanning on all scanners.

For host running the Qualys Windows agent this QID reports the time taken by the agent to collect the host metadata used for the most recent assessment scan.]]> 0 0 The service also attempts to authenticate using common credentials. You should verify that the credentials used for successful authentication were those that were provided in the Windows authentication record. User-provided credentials failed if the discovery method shows "Unable to log in using credentials provided by user, fallback to NULL session". If this is the case, verify that the credentials specified in the Windows authentication record are valid for this host.]]> 0 0 The registry key for the Network Level Authentication (NLA) is disabled.

Network Level Authentication is supported on Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2]]> 2671387 to use the automated Microsoft Fix it solution to enable this feature.

As a precaution, always test in a QA or rehearsal environment before rolling out to production.

Note: Client computers that do not support Credential Security Support Provider (CredSSP) protocol will not be able to access servers protected with Network Level Authentication. Windows XP does not support the CredSSP protocol by default.]]> 0 The Results section includes information on the remote access service that was found on the target.

Services like Telnet, Rlogin, SSH, windows remote desktop, pcAnywhere, Citrix Management Console, Remote Admin (RAdmin), VNC, OPENVPN and ISAKMP are checked.]]> 0 0 0 0 0 0 The following is a list of supported SSL ciphers.

Note: If a cipher is included in this list it means that it was possible to establish a SSL connection using that cipher. There are some web servers setups that allow connections to be established using a LOW grade cipher, only to provide a web page stating that the URL is accessible only through a non-LOW grade cipher. In this case even though LOW grade cipher will be listed here QID 38140 will not be reported.

]]> 0 This test determines if SSL session caching is enabled on the host.]]> 0 The Results section displays the port number (Port), the default service listening on the port (IANA Assigned Ports/Services), the description of the service (Description) and the service that the scanner detected using service discovery (Service Detected).]]> CERT Web site.]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 0 A certificate whose Subject commonName or subjectAltName does not match the server FQDN offers only encryption without authentication.

Please note that a false positive reporting of this vulnerability is possible in the following case:

If the common name of the certificate uses a wildcard such as *.somedomainname.com and the reverse DNS resolution of the target IP is not configured. In this case there is no way for Qualys to associate the wildcard common name to the IP. Adding a reverse DNS lookup entry to the target IP will solve this problem.

TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

This QID will be marked as a Fail for PCI as of May 1st, 2017 in accordance with the new standards. For existing implementations, Merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation and Migration Plan, which will result in a pass for PCI up until June 30th, 2018.

Further details can be found at: NEW PCI DSS v3.2 and Migrating from SSL and Early TLS v1.1

]]> For example: An attacker could force a downgrade from the TLS protocol to the older SSLv3.0 protocol and exploit the POODLE vulnerability, read secure communications or maliciously modify messages.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

]]> 0 SSL/TLS protocols use ciphers such as AES,DES, 3DES and RC4 to encrypt the content of the higher layer protocols and thus provide the confidentiality service. Normally the output of an encryption process is a sequence of random looking bytes. It was known that RC4 output has some bias in the output. Recently a group of researchers has discovered that the there is a stronger bias in RC4, which make statistical analysis of ciphertext more practical.

The described attack is to inject a malicious javascript into the victim's browser that would ensure that there are multiple connections being established with a target website and the same HTTP cookie is sent multiple times to the website in encrypted form. This provides the attacker a large set of ciphertext samples, that can be used for statistical analysis.

NOTE: On 3/12/15 NVD changed the CVSS v2 access complicity from high to medium. As a result Qualys revised the CVSS score to 4.3 immediately. On 5/4/15 Qualys is also revising the severity to level 3.]]> This attack is not very practical as it requires the attacker to have access to millions of samples of ciphertext, but there are certain assumptions that an attacker can make to improve the chances of recovering the cleartext from cihpertext. For examples HTTP cookies are either base64 encoded or hex digits. This information can help the attacker in their efforts to recover the cookie.]]> 1 Since RDP transfers sensitive information about the user and the system, it can be configured to use encryption to provide privacy and integrity for its sessions. It is possible to configure RDP to use encryption algorithms that are considered insecure, such as RC4 40bit and RC4 56 bit.]]> To configure RDP encryption methods 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' snap-in can be launched in mmc.exe.
In 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' properties dialog box General tab for the Encryption Level 'High' should be selected.

On Windows XP the RDP configuration can be found under Computer Configuration\Administrative Templates\Windows Components\Terminal Services and User Configuration\Administrative Templates\Windows Components\Terminal Services. Under Encryption and Security item, double click on 'Set client connection encryption level' and enable the policy and select high for the 'Encryption level'.

For more details on configuration on 2008 R2 systems see Configure Server Authentication and Encryption Levels.
For more detail on disabling RC4 see Microsoft Update for Disabling RC4.
For details on supporting TLS 1.1 and TLS1.2 for Remote Desktop Services see Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2.
]]> 0 We have sent the following types of packets to trigger the host to send us ICMP replies:

Echo Request (to trigger Echo Reply)
Timestamp Request (to trigger Timestamp Reply)
Address Mask Request (to trigger Address Mask Reply)
UDP Packet (to trigger Port Unreachable Reply)
IP Packet with Protocol >= 250 (to trigger Protocol Unreachable Reply)

Listed in the "Result" section are the ICMP replies that we have received.]]> 0 0 Some operating systems (e.g., MacOS, OpenBSD) use a non-zero, probably random, initial value for the timestamp. For these operating systems, the uptime obtained does not reflect the actual uptime of the host; the former is always larger than the latter.]]> 0 0 Please note that for reliability reasons only the network traffic from open TCP ports is analyzed.]]> 0 0 0 KB2696547 for more details. Workaround:
Customer may consider blocking all versions of SMB at the network boundary by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139, for all boundary devices.]]> 0 0 The Host Scan Time does not have a direct correlation to the Duration time as displayed in the Report Summary section of a scan results report. The Duration is the period of time it takes the service to perform a scan task. The Duration includes the time it takes the service to scan all hosts, which may involve parallel scanning. It also includes the time it takes for a scanner appliance to pick up the scan task and transfer the results back to the service's Secure Operating Center. Further, when a scan task is distributed across multiple scanners, the Duration includes the time it takes to perform parallel host scanning on all scanners.

For host running the Qualys Windows agent this QID reports the time taken by the agent to collect the host metadata used for the most recent assessment scan.]]> 0 0 The service also attempts to authenticate using common credentials. You should verify that the credentials used for successful authentication were those that were provided in the Windows authentication record. User-provided credentials failed if the discovery method shows "Unable to log in using credentials provided by user, fallback to NULL session". If this is the case, verify that the credentials specified in the Windows authentication record are valid for this host.]]> 0 0 The registry key for the Network Level Authentication (NLA) is disabled.

Network Level Authentication is supported on Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2]]> 2671387 to use the automated Microsoft Fix it solution to enable this feature.

As a precaution, always test in a QA or rehearsal environment before rolling out to production.

Note: Client computers that do not support Credential Security Support Provider (CredSSP) protocol will not be able to access servers protected with Network Level Authentication. Windows XP does not support the CredSSP protocol by default.]]> 0 The Results section includes information on the remote access service that was found on the target.

Services like Telnet, Rlogin, SSH, windows remote desktop, pcAnywhere, Citrix Management Console, Remote Admin (RAdmin), VNC, OPENVPN and ISAKMP are checked.]]> 0 0 0 0 0 0 The following is a list of supported SSL ciphers.

Note: If a cipher is included in this list it means that it was possible to establish a SSL connection using that cipher. There are some web servers setups that allow connections to be established using a LOW grade cipher, only to provide a web page stating that the URL is accessible only through a non-LOW grade cipher. In this case even though LOW grade cipher will be listed here QID 38140 will not be reported.

]]> 0 This test determines if SSL session caching is enabled on the host.]]> 0 The Results section displays the port number (Port), the default service listening on the port (IANA Assigned Ports/Services), the description of the service (Description) and the service that the scanner detected using service discovery (Service Detected).]]> CERT Web site.]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 0 A certificate whose Subject commonName or subjectAltName does not match the server FQDN offers only encryption without authentication.

Please note that a false positive reporting of this vulnerability is possible in the following case:

If the common name of the certificate uses a wildcard such as *.somedomainname.com and the reverse DNS resolution of the target IP is not configured. In this case there is no way for Qualys to associate the wildcard common name to the IP. Adding a reverse DNS lookup entry to the target IP will solve this problem.

TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

This QID will be marked as a Fail for PCI as of May 1st, 2017 in accordance with the new standards. For existing implementations, Merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation and Migration Plan, which will result in a pass for PCI up until June 30th, 2018.

Further details can be found at: NEW PCI DSS v3.2 and Migrating from SSL and Early TLS v1.1

]]> For example: An attacker could force a downgrade from the TLS protocol to the older SSLv3.0 protocol and exploit the POODLE vulnerability, read secure communications or maliciously modify messages.

A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade.

]]> 0 SSL/TLS protocols use ciphers such as AES,DES, 3DES and RC4 to encrypt the content of the higher layer protocols and thus provide the confidentiality service. Normally the output of an encryption process is a sequence of random looking bytes. It was known that RC4 output has some bias in the output. Recently a group of researchers has discovered that the there is a stronger bias in RC4, which make statistical analysis of ciphertext more practical.

The described attack is to inject a malicious javascript into the victim's browser that would ensure that there are multiple connections being established with a target website and the same HTTP cookie is sent multiple times to the website in encrypted form. This provides the attacker a large set of ciphertext samples, that can be used for statistical analysis.

NOTE: On 3/12/15 NVD changed the CVSS v2 access complicity from high to medium. As a result Qualys revised the CVSS score to 4.3 immediately. On 5/4/15 Qualys is also revising the severity to level 3.]]> This attack is not very practical as it requires the attacker to have access to millions of samples of ciphertext, but there are certain assumptions that an attacker can make to improve the chances of recovering the cleartext from cihpertext. For examples HTTP cookies are either base64 encoded or hex digits. This information can help the attacker in their efforts to recover the cookie.]]> 1 Since RDP transfers sensitive information about the user and the system, it can be configured to use encryption to provide privacy and integrity for its sessions. It is possible to configure RDP to use encryption algorithms that are considered insecure, such as RC4 40bit and RC4 56 bit.]]> To configure RDP encryption methods 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' snap-in can be launched in mmc.exe.
In 'Terminal Services Configuration' or 'Remote Desktop Session Host Configuration' properties dialog box General tab for the Encryption Level 'High' should be selected.

On Windows XP the RDP configuration can be found under Computer Configuration\Administrative Templates\Windows Components\Terminal Services and User Configuration\Administrative Templates\Windows Components\Terminal Services. Under Encryption and Security item, double click on 'Set client connection encryption level' and enable the policy and select high for the 'Encryption level'.

For more details on configuration on 2008 R2 systems see Configure Server Authentication and Encryption Levels.
For more detail on disabling RC4 see Microsoft Update for Disabling RC4.
For details on supporting TLS 1.1 and TLS1.2 for Remote Desktop Services see Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2.
]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 0 Note that if the host is behind a firewall, there is a small chance that the list includes a few ports that are filtered or blocked by the firewall but are not actually open on the target host. This (false positive on UDP open ports) may happen when the firewall is configured to reject UDP packets for most (but not all) ports with an ICMP Port Unreachable packet. This may also happen when the firewall is configured to allow UDP packets for most (but not all) ports through and filter/block/drop UDP packets for only a few ports. Both cases are uncommon.]]> CERT Web site.]]> 0 1) TCP/IP Fingerprint: The operating system of a host can be identified from a remote system using TCP/IP fingerprinting. All underlying operating system TCP/IP stacks have subtle differences that can be seen in their responses to specially-crafted TCP packets. According to the results of this "fingerprinting" technique, the OS version is among those listed below.

Note that if one or more of these subtle differences are modified by a firewall or a packet filtering device between the scanner and the host, the fingerprinting technique may fail. Consequently, the version of the OS may not be detected correctly. If the host is behind a proxy-type firewall, the version of the operating system detected may be that of the firewall instead of the host being scanned.

2) NetBIOS: Short for Network Basic Input Output System, an application programming interface (API) that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities. NetBIOS relies on a message format called Server Message Block (SMB).

3) PHP Info: PHP is a hypertext pre-processor, an open-source, server-side, HTML-embedded scripting language used to create dynamic Web pages. Under some configurations it is possible to call PHP functions like phpinfo() and obtain operating system information.

4) SNMP: The Simple Network Monitoring Protocol is used to monitor hosts, routers, and the networks to which they attach. The SNMP service maintains Management Information Base (MIB), a set of variables (database) that can be fetched by Managers. These include "MIB_II.system.sysDescr" for the operating system.]]> 0 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]> 1 HTTP headers according to CWE-693: Protection Mechanism Failure:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Content-Security-Policy: This HTTP header helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS), packet sniffing attacks and data injection attacks.

QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.

Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection HTTP: 0 disables this directive and hence is also treated as not detected.

A valid directive for X-Content-Type-Options: nosniff

A valid directive for Content-Security-Policy, except for Content-Security-Policy-Report-Only.

]]> Customers are advised to set proper X-Frame-Options, X-XSS-Protection, Content Security Policy and X-Content-Type-Options HTTP response headers.

Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:

X-Frame-Options:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>

X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");

X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff

Content-Security-Policy: (Please note that these values may differ from website to website. The values below are for informational purposes only. The scanner simply looks for the presence of the security header.)
Apache: Header set Content-Security-Policy "script-src 'self'; object-src 'self'"
IIS: <SYSTEM.WEBSERVER><HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="Content-Security-Policy" VALUE="default-src 'self';"></ADD></CUSTOMHEADERS></HTTPPROTOCOL></SYSTEM.WEBSERVER>
nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self';

]]>