Web Application Header Finding Considerations

Web Application Header findings are generated with host and port data. Each Host:Port pair is considered as a single finding.

If the issues(s) identified in the finding are remediated and the site remains accessible, a new finding will be created and will replace the initial finding in the risk vector grade calculation. If the destination cannot be located when a finding is remediated, a new finding is not generated and the previous BAD finding impacts the grade until it completes its lifetime. This can happen when a web application firewall (WAF) is in place or the destination domain belongs to the WAF. Refer to Asset Not Found for details.

Asset Not Reached finding rescan status, Asset Not Found finding rescan status

Valid Risk Indicators

To reduce the population of “noisy” observations that are not valid risk indicators, the following criteria are applied:

• Hostname
• Port
• Hardware Appliances
• Content-Type
• Content-Length
• Response
• Redirects
• Protocol Changes

Hostname

Criteria

The host is part of the company’s infrastructure.

Why?

Countless hosts, including subdomains (mail.google.com), are tallied. This is to detect Web Application Headers across the Bitsight inventory.

The company’s domains are used as the criteria for identifying hosts. Related records are matched and assigned to a company. This handling of wildcards in DNS records prevents the creation and evaluation of repeated findings.

Example: If the company has a subset domain (e.g., saperix.com) of the host specified in the record (www.saperix.com), the observation is recorded.

Port

Criteria

The port must be 80 or 443.

Why?

These ports are the most likely to host content that is of interest. Non-standard ports (8000, 8080, 8443, etc.) are often web management interfaces for software and hardware platforms.

Hardware Appliances

Criteria

The appliance must not be a common hardware appliance, i.e., Cisco ASA, Sonicwall firewalls, etc.

Why?

These are the devices that general users cannot address and fix.

Content-Type

Criteria

The content type must be text/html.

Why?

If the Content-Type is “application/json,” this typically means the host is a HTTP-based API.

Example: An image is not a useful web application. The record will be dropped.

Content-Length

Criteria

The content must be absent or the content length must be greater than 0.

Why?

• If present and is specified as “0” (no HTML returned), the record is not generated.
• If the header is missing from the response, this check is skipped.

Response

Criteria

The response must end in “200.”

Why?

The data provider normally follows all 3xx-based redirects, but if the 3xx redirect causes the protocol to change (such as from HTTP to HTTPS or vice versa), the record ends and a new record is created for the new protocol.

If the response ends in anything else, such as:

• 3xx redirect - The headers received from the web application are not necessarily the headers that a normal user would observe.
• 4xx or 5xx HTTP status code - Something went wrong during the request. The ultimate resource was not returned.

Redirects

Criteria

Redirects to a different hostname result in a record being created only for the destination host, assuming it is part of the company’s infrastructure.

Example: Traffic to saperix.com is redirected to saperix.io. A record is created for saperix.io.

Why?

• Records are based on the original hostname. When subdomains with different URLs are shortcuts to the same web application, the number of records may be excessive. If a record is based on the terminal hostname, it will have rapid fluctuations in record grades. This is because a different page is evaluated each day.
• When a subdomain of a company redirects to a domain (and infrastructure) that belongs to a different company, the company that the record should be assigned to is ambiguous.

Protocol Changes

Criteria

Protocols can only change from HTTP to HTTPS.

Why?

Redirects from HTTPS to HTTP is a misconfiguration and should be addressed.