CODEWITHSUNDEEP
authenticationuricontent-security-policy
Serban Cezar
Serban Cezar

Reputation: 535

Securing CSP report-uri payloads

I am looking to implement a Lambda@Edge function that will add CSP headers to my website and thus will improve my site's security.

I do have an issue with the URL report settings (report-to/report-uri). As far as I can tell, there's no way for me to authenticate CSP violation requests. Does that mean that if a malicious person gains a hold of my reporting API, they can just spam POST requests and send false data? Is there any way to add any sort of security for the reports that get posted via the reporting directive?

Upvotes: 2

Views: 1229

Answers (3)

SAMUEL
SAMUEL

Reputation: 8552

To protect the CSP reporting endpoint, one approach is to dynamically generate a temporary URL for the reporting endpoint that expires within a specified time frame (such as the session's duration) and append it to the report's header. This ensures that only valid reports within an active session can be sent to the endpoint, limiting the possibility of malicious activity.

How This Works:

  1. Server-Side Dynamic URL Generation: When a session starts or a report is being created, the server generates a temporary URL tied to the session, with an expiration time based on the session's duration.

  2. Append to Report Header: This dynamic URL is appended to the CSP report as part of the Report-To or Content-Security-Policy-Report-Only header.

  3. Expiration Check: Upon receiving the report, the server validates whether the report was sent within the valid session time and whether the URL is still valid (not expired).

Sequence Diagram

Benefits:

  • Security: The temporary nature of the URL ensures that the endpoint is not exposed indefinitely, minimizing the risk of attacks.
  • Session-based Validity: The dynamic URL is tied to a specific session, and only reports from the active session are accepted.
  • Tamper-proof: By appending the URL as part of the CSP report header, you ensure that the URL cannot be easily intercepted or manipulated by attackers.

Use Cases:

  • Large Applications: In a large ecosystem with multiple CSP report endpoints, this method ensures that each report is associated with a secure, temporary endpoint specific to the current session.
  • Dynamic Security: This allows real-time security adjustments, such as session timeouts, which prevent outdated or invalid reports from being accepted.

Upvotes: 0

user16568787
user16568787

Reputation:

I don't agree with @granty If I was the attacker: yes I can't be sure that the reporting API is running but nevermind. I know there is a risk that the API is up until report-uri directive is set in the Content-Security-Policy header. If I was trying to exploit a vulnerability I would perform a blind attack on the CSP report uri so that potential admins are misinformed on all my exploit tests on the website. This attack make sense if you know that there is a risk that CSP can be triggered by your exploit.

Upvotes: 2

granty
granty

Reputation: 8546

Yes, a malicious person can sent a fake SPAM violation reports. But he will not gain any profit from that, just DOS-attack which will not affect the website.

You can make some protection from this if you do use your own service for obtaining reports of violations. You can check cookies, generate a special URL for the reporting API for each visitor (for example, add md5 (IP-address) to it), etc.

But there is usually no reason to protect reports. An attacker cannot determine if this API is currently running or disabled. Therefore, a blind attack of reporting API does not make sense.

Upvotes: 2

Related Questions