[ Rapporter og etterforskning ]

Sikker inntak av komprimerte DMARC XML-filer

Separat vedleggsinntak, begrenset dekompresjon, sikker parsing og transaksjonsimport slik at én fiendtlig rapport ikke kan ødelegge analyser eller tømme samleren.

Av EmailAuth -forskningsteamet

[Nøkkelpunkter]

  • Behandle rapportvedlegg som uklarerte ved hvert inntakslag.
  • Bundet utvidede byte under dekompresjon, ikke etter full tildeling.
  • Bekreft kun validerte, duplikathåndterte data og bevar kontrollert diagnostikk.
På denne siden

En rapporteringspostboks er en inngangsgrense, ikke en klarert datakilde. Et vedlegg kan være misformet, overdimensjonert eller bevisst dyrt å behandle. Bygg innføringsbanen slik at transportgodkjenning ikke automatisk betyr parsersaksept, og parsersaksept betyr ikke automatisk at rapportens påstander er pålitelige.

RFC 9990 beskriver samlet XML-levering og advarer om ressursbruk og falsk informasjon. Rørledningen nedenfor er en implementeringsanbefaling, ikke en påstand om at et bestemt produkt allerede har disse kontrollene.

Isoler inntak fra analyse

Referanser: RFC 9990 §8.1, RFC 9990 §8.2.

Tildel en ankomstidentifikator og bevar en avgrenset, tilgangskontrollert referanse til det originale vedlegget. Registrer størrelse, fingeravtrykk, ankomsttid og transportmetadata. Bruk kø- og ressurskontroller per opprinnelse slik at én strøm ikke kan monopolisere arbeidere. Behandle en avsenderadresse eller et kjent filnavn som utilstrekkelig bevis på autentisitet.

Hold arbeideren minimalt privilegert og atskilt fra databaselegitimasjonen som brukes til å publisere endelige beregninger. Hindre vedleggsinnhold fra å bestemme kjørbare kommandoer eller destinasjonsstier. Mislykkede inndata hører hjemme i en kontrollert diagnostisk bane, ikke i offentlige feilsider eller ubegrensede logger.

Bundet dekompresjon mens den kjører

Referanser: RFC 9990 §3.5.2, RFC 9990 §8.1.

RFC 9990 spesifiserer XML og anbefaler GZIP-komprimering. Oppdag det støttede formatet og avvis ikke-støttede beholdere i henhold til en dokumentert kompatibilitetspolicy. Hvis eldre arkivformater med vilje støttes, må du gjennomgå ekstra utvinnings- og banerisiko i stedet for å behandle dem som likeverdige med en enkelt XML-strøm.

Sett grenser for komprimerte byte, utvidede byte, forløpt behandlingstid, minne, antall rekorder og samtidighet. Håndhev utvidede størrelsesgrenser mens du leser, ikke etter å ha allokert hele utdataene. Størrelsesdeklarasjoner inne i en beholder er ikke en erstatning for måling av faktisk produksjon. Stopp behandlingen når en konfigurert grense er nådd.

Parse uten unødvendige muligheter

Referanser: RFC 9990 §3.1.1, RFC 9990 §8.1.

Referanse: OWASP XML forebygging av eksterne enheter, generell veiledning.

Bruk en vedlikeholdt parser med den faktiske kjøretidskonfigurasjonen gjennomgått. Deaktiver unødvendige dokumenttyper, ekstern enhetsoppløsning, XInclude og ekstern ressursinnhenting. Behandle ikke-støttede herdingsinnstillinger som konfigurasjonsfeil, ikke advarsler om å ignorere. Bruk pålitelige lokale skjemaer der validering er nødvendig i stedet for å følge skjemaplasseringer levert av et vedlegg. Bruk grenser for nesting og tekststørrelse samt totale byte.

Valider den forventede rapportstrukturen og feltsemantikken separat fra XML-formen. Et dokument kan være godt utformet, men ubrukelig som en DMARC rapportere. Bevar årsaken til avvisningen uten å oversette en parserfeil til en dom for e-postautentisering.

Bruk en liten avgrenset armatur

Illustrerende oppsettingskonfigurasjon: tillat 64 KiB komprimert inngang og 256 KiB utvidet utgang for en bevisst liten testarbeider. En harmløs GZIP-armatur utvides til 300 KiB med repeterende testtekst. Det forventede resultatet er et stopp i utvidet størrelse før fullstendig materialisering, ingen rapportrader er forpliktet og en diagnostikk som inneholder grensen og inngangsreferansen.

Disse tallene er demonstrasjonsgrenser, ikke råd om produksjonsstørrelse. Test en gyldig liten rapport umiddelbart etterpå for å bekrefte at arbeideren forblir brukbar. Registrer faktiske målinger før du hevder at kontrollen fungerer. Denne artikkelen beskriver nødvendig iscenesettelsesatferd, ikke en utført leietakertest. Gjennomgangspakken registrerer også en ny avgrenset Python GZIP-demonstrasjon: den oppdager utvidelse utover 256 KiB-grensen med maksimalt én ekstra deteksjonsbyte, og håndterer deretter en liten gyldig XML-tekststrøm. Det demonstrerer bare denne lokale dekompresjonsvakten, ikke parserherding, minneisolasjon eller databaseatferd.

Forplikte kun validerte data

Referanser: RFC 9990 §3.5.4, RFC 9990 §9.2.

Trinn normaliserte poster og fullfør importen atomisk etter validering og duplikathåndtering. En avbrutt fil bør ikke etterlate en delvis telling i produksjonsanalyse. Gjør replay idempotent og behold avgjørelsen som knytter gjentatte ankomster til den tellede rapporten.

Overvåk avviste byte, behandlingstid, køalder og gjenopprettingsresultater. Legitime rapporter kan overskride lokale grenser, så gi en kontrollert gjennomgangsbane i stedet for å automatisk øke hver grense. Lukk driftsdesignet med navngitte eiere for inntak, parservedlikehold, lagringsoppbevaring og hendelsesrespons.

[ Takeaway ]

Bekreft kun validerte, duplikathåndterte data og bevar kontrollert diagnostikk.

[Etter rolle]

Hva dette betyr for deg

Velg din rolle for praktiske neste trinn.

IT / Mail Admin

Håndhev grenser for utvidelse av strømming.

Valider før du forplikter beregninger. Test replay og gjenoppretting etter feil.

Neste trinn

  1. Håndhev grenser for utvidelse av strømming.
  2. Valider før du forplikter beregninger.
  3. Test replay og gjenoppretting etter feil.

CISO / SecOps

Gjennomgå arbeiderprivilegier og utgang.

Krev målte ressurstester. Hold fiendtlige inndata unna ubegrensede logger.

Neste trinn

  1. Gjennomgå arbeiderprivilegier og utgang.
  2. Krev målte ressurstester.
  3. Hold fiendtlige inndata unna ubegrensede logger.

Grunnlegger / Ikke-teknisk

Tildel eierskap for samlerens pålitelighet.

Hold inntaksbrudd forskjellig fra e-postfeil. Finansier en kontrollert gjennomgangsbane for overdimensjonerte rapporter.

Neste trinn

  1. Tildel eierskap for samlerens pålitelighet.
  2. Hold inntaksbrudd forskjellig fra e-postfeil.
  3. Finansier en kontrollert gjennomgangsbane for overdimensjonerte rapporter.

[ Vanlige spørsmål ]

Ofte stilte spørsmål

Er et vedlegg klarert fordi det ankom rua?

Nei. Inntak må behandle rapportinnhold som uklarert.

RFC 9990 §8.2

Hvilken komprimering anbefaler den nåværende samlede RFC?

GZIP for XML-rapporten; ekstra eldre beholdere trenger en eksplisitt kompatibilitetspolicy.

RFC 9990 §3.5.2

Når bør sjekker for utvidet størrelse kjøre?

Under dekompresjon, før full utgang er allokert eller skrevet.

Er grensene for komprimert størrelse tilstrekkelige?

Nei. Utvidede byte, tid, minne og samtidighet trenger også kontroller.

RFC 9990 §8.1

Skal parserskjemaplasseringer utløse nettverkshentinger?

Bruk pålitelige lokale valideringsressurser og hindre vedleggsrettet henting.

Er misformet XML-bevis for falsk e-post?

Nei. Det er et behandlingsresultat, ikke et meldingsautentiseringsresultat.

Hva om en gyldig rapport overskrider en lokal grense?

Sett den i karantene for kontrollert gjennomgang uten å i det stille svekke hele rørledningen.

Hvordan skal en mislykket import gjenopprettes?

Utfør ingen delvise beregninger, behold en sikker diagnostikk og bekreft de neste gyldige rapportprosessene som normalt.

[ Kilder ]

Kilder

  1. RFC 9990

    Seksjoner §3.1 · §3.1.1 · §3.5.2 · §3.5.4 · §8.1 · §8.2 · §9.2

  2. OWASP XML External Entity Prevention

    Seksjoner Generell veiledning

[ Ordliste ]

Ordliste

Utvidet størrelse
Utdatabytene produsert ved dekompresjon, uavhengig av komprimert inngangslengde.
Atomforpliktelse
En lokal lagringsdesign som viser alle validerte importendringer sammen eller ingen av dem.
Samlet rapport
Grupperte mottakerobservasjoner om DMARC -evaluering under et rapporteringsintervall.

RFC 9990 §3.1

Enterprise herkomst

Hvorfor topp finansinstitusjoner og regjeringer pensjonert e-postsikkerhetsdashboardene deres.

Tradisjonelle e-postautentiseringsplattformer selger deg et dashbord og ber ingeniørene dine gjøre jobben. I miljøer med høy innsats betyr manuell overvåking forsinket håndheving, konfigurasjonsdrift og uovervåkede skyggedomener.

EmailAuth er den agentiske e-postopprinnelsesplattformen. Våre agenter håndhever p=reject, hold tredjepartssendere på linje og flytt domenene dine til fulle RFC 9989 compliance, den nye DMARC standarden, med menneskelig-in-the-loop reviderbarhet.

Regjeringer Store bedrifter Tier-1 finansinstitusjoner

SaaS · Dedikert leieforhold · Air-gaped on-prem · BYOK-kryptering

Kunnskapsbase