Web Application Security Assessment: Sensitive Data Exposure

The Sensitive Data Exposure Web Application Security assessment evaluates the application design to ensure it includes controls that reduce the exposure of critical and sensitive information.

Table of Contents

• Secure Cookie Set on an Insecure Channel
• Session Token in URL
• Mixed Content
• HSTS Preload Directive Present
• Cookie SameSite Attribute
• Cookie SameSite Blocked
• Unsafe Referrer Policy

Secure Cookie Set on an Insecure Channel

The Secure flag instructs the browser to never pass a cookie over an insecure (e.g. non-HTTPS) channel; however, occasionally some websites set these cookies over insecure channels, defeating the purpose of the Secure flag. Some modern browsers will even ignore secure cookies set over an insecure medium.

Finding Message: Secure cookie on insecure channel

Framework References

Grading & Conditions

Cookies that do not contain sensitive information and are outside the control of the website owner are ignored. For more information, check the Cookie Assessment Exclusion.

Weight: Not Applicable

Possible Grades:

Condition = Secure cookie set on insecure channel findings are informational only.

Mitigation

Ensure the site is accessible through a secure connection. If that is not possible, ensure that the application does not depend on cookies with the Secure flag set.

Session Token in URL

Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked, or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.

Finding Message: A known session token pattern is present in a URL

Framework References

Grading & Conditions

Weight: Not Applicable

Possible Grades:

Condition = We issue an informational finding when we find tokens that may be used as session identifiers being passed in a URL field. Session Token in URL findings are informational only. They are always NEUTRAL and they do not impact your rating.

Mitigation

Even if this is an informational finding, users are advised to ensure that no session identifiers or otherwise sensitive information are passed via URL GET parameters.

Mixed Content

Some websites will load insecure resources using HTTP even though the sites are being served over HTTPS. This is a security risk.

Finding Message: Secure page included non-secure content

Framework References

Grading & Conditions

Whenever an HTTPS website is visited, we list every resource that is insecure content (HTTP). Depending on the type of content, a web browser may block it from loading (blocked) and try to load it via a secure channel (HTTPS) (upgraded).

Usually, the content that is blocked is more security sensitive, so we grade mixed content events using the following scale (there is a per event status limit to what counts against a hostname of 10 findings):

For each website, we add the weights of these events and calculate a mixed content score, issuing the following grades based on its value:

Minimum weight: 0

Maximum weight: Unbounded decreased to 10101

Possible Grades:

Weight = 0

Condition = Low number/low severity of mixed content events.

Weight = Between >0 and <10

Condition = Medium number/medium severity of mixed content events.

Content Score = Mixed_content_score < 10

Weight = Between ≥10 and <1000

Condition = Medium number/medium severity of mixed content events.

Content Score = 10 ≤ mixed_content_score < 1000

Weight = Between ≥1000 and ≤10101

Condition = High number/high severity of mixed content events.

Content Score = mixed_content_score ≥ 1000

Mitigation

The best strategy to avoid mixed content blocking is to serve all content as HTTPS instead of HTTP. Website owners should ensure that every resource loaded from an HTTPS website is loaded securely.

HSTS Preload Directive Present

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking.

It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.

Framework References

Grading & Conditions

Weight: -0.1 ❖

Possible Grades:

Weight = -0.1

Condition = The Strict-Transport-Security header is set with the preload directive.

Mitigation

Website owners should configure HSTS headers correctly.

Cookie SameSite Attribute

SameSite attributes prevent cookies from being passed to cross-origin browsing contexts and are one mitigating technique to prevent cross-site request forgery.

Finding Message: Cookie set without the SameSite attribute defined

Framework References

Grading & Conditions

Cookies that do not contain sensitive information and are outside the control of the website owner are ignored. For more information, check the Cookie Assessment Exclusion.

Weight: Not Applicable

Possible Grades:

Condition = Cookie SameSite Attribute findings are informational only. They are always NEUTRAL and they do not impact the rating.

Mitigation

In general, session and other tracking cookies should be explicit about how permissive the use of the cookie can be across origins. The current default behavior on most modern browsers is SameSite=Lax, which may be too permissive for session cookies on some web applications.

Cookie SameSite Blocked

The SameSite cookie attribute allows website owners to restrict where and when cookies may be sent. It allows for greater control over the use of third-party tracking cookies on a given website and helps to prevent attacks such as Cross-Site Request Forgery (CSRF).

Finding Message: A cookie was blocked due to SameSite policy violation

Framework References

Grading & Conditions

Cookies that do not contain sensitive information and are outside the control of the website owner are ignored. For more information, check the Cookie Assessment Exclusion.

Minimum weight: 0

Maximum weight: 0.1

Possible Grades:

Weight = 0

Condition = No Issues with blocked cookies exist.

Weight = 0.1

Condition = At least one of the following issues exists:

• The website is loading resources from a third-party site that has cookies that were blocked due to a SameSite policy.
• The website is attempting to set a cookie with SameSite=None, but is not setting the secure cookie flag.

Mitigation

As of July 14, 2020, Google Chrome and most browsers have adopted the default cookie policy of SameSite=Lax. This means that for third-party cookies to be sent when loading external resources, they need to be explicitly set with the SameSite=None policy as well as the secure flag to be loaded.

Unsafe Referrer Policy

The Referrer-Policy header tells the browser what referrer information should be passed on to navigation. In some policy configurations, sensitive user data may be leaked outside of secure channels.

Finding Message: Referrer-Policy defined with unsafe-url

Framework References

Grading & Conditions

Weight: 0.1

Possible Grades:

Weight = 0.1

Condition = The website contains the unsafe-url Referrer Policy. We scan each website looking for the Referrer-Policy: unsafe-url header. This header specifies that this website will pass its referrer information in full to other linked sites, including any query parameters, if present.

Mitigation

Website owners should avoid leaking internal URLs to third parties when possible.