Attacks on reporting URIs as mentioned in RFC 7489

[jorritfolmer]

RFC7489 mentions a number of threats against DMARC reporting URI's in chapter 12.2. Below is a short discussion of the current mitigation scope.

Threat	Mitigation
High-volume denial-of-service attacks	No: should we handle this? If so: how?
Deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities	Yes: use of defused XML library, and checks against GZ and ZIP bombs
Deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.	No: should we handle this? If so: how?

Any other threats we should address?

[malvidin]

I believe this processor should not be the primary location to combat most denial-of-service, false reports, or malformed reports. Addressing malformed reports is still appropriate, but denial-of-service and false reports are better handled elsewhere where additional context is available.

Deliberate malformed reports

• XSD validation mitigates additional threats, but not string fields
• XSD validation does not validate XML string values, which could target the Splunk server or a user

High-volume denial-of-service attacks

• RUA parser DNS lookups (IP & domain) might degrade arpa or other provider DNS services
• Best managed primarily by email security devices and hosting providers, not the RUA parser
• Reports with large numbers of records

Deliberate false reports

• Impossible to eliminate entirely, can be indistinguishable from a valid report
  • Entirely falsified reports
  • Addition of records / metadata
  • Removal of records / metadata
  • Modification of records / metadata
• Protections could include fingerprinting each DMARC processor and using that information to filter reports
• The report itself doesn't provide enough information to validate that it came from a legitimate source
• The full email provides information that can provide additional protections
• Some protections better applied through email security devices and hosting providers (Stricter DKIM & SPF policy)

[jorritfolmer]

Updated matrix with your feedback

Threat	Mitigation	Rationale
Denial-of-service attacks
GZ bombs	Yes. Decompressions limits
ZIP bombs	Yes. Decompressions limits
XML bombs	Yes. Defused XML library
Large numbers of files in a ZIP	TODO	1000 files that remain below the decompression limit are still a DOS.
Large numbers of reports	None	Best managed primarily by email security devices and hosting providers, not the RUA parser
Reports with large numbers of records	None
RUA parser DNS lookups	None	RUA parser DNS lookups (IP & domain) might degrade arpa or other provider DNS services. DNS amplification attacks aren't likely: an attacker doesn't control the source address, and can only perform A or PTR lookups.
Malformed reports
Invalid XML	Yes. XML parser check
Valid XML but invalid DMARC report	Yes. XSD validation
Valid XML, valid DMARC report but invalid field values	TODO	XSD validation does not validate XML string values, which could target the Splunk server or a user
False reports
Mail Receiver spoofing	TODO	The add-on should add email metadata to the JSON object. This enables creation of rules in a Splunk app or dashboard.
Fake Mail Receiver	TODO	The add-on should add email metadata to the JSON object. This enables creation of rules in a Splunk app or dashboard.
False reports from a legitimate Mail Receiver	None	Based on the mail and report metadata we cannot determine if records or metadata have been added, removed or modified.