Separera meddelandekonstruktion från domänautentisering
En applikation kan skicka ett korrekt autentiserat meddelande som det aldrig borde ha konstruerat. SPF, DKIM och DMARC svara på frågor om att skicka auktorisation, underskrifter och domänjustering. De avgör inte om ett kontaktformulär fick välja mottagare, om ett ämnesfält tolkades som en annan rubrik eller om ett arbetsflöde godkände begäran. Denna distinktion har betydelse för lösenordsmeddelanden, supportformulär, fakturor och alla program som sammanställer e-post från extern input. Ett lyckat DMARC resultat är inte ett substitut för att validera den inmatningen innan meddelandeserialisering.
RFC 9989 exkluderar uttryckligen innehållsanalys och autentisering av andra enheter än domäner från DMARC :s mål. Den gränsen är utgångspunkten för denna hotmodell, inte en anledning att försvaga autentiseringen. Behåll anpassad autentisering och kontrollera separat hur applikationer skapar meddelanden. Detta manuskript föreslår defensiva granskningssteg. Den reproducerar inte en exploatering, skickar inte meddelanden, inspekterar en riktig applikation eller tillhandahåller en attacknyttolast.
Förstå serialiseringsgränsen
RFC 5322, avsnitt 2.2, beskriver ett rubrikfält som ett fältnamn följt av ett kolon och en fältkropp, avslutade av CRLF. Standarden beskriver även fällbara och utfällbara långa fält. Det är regler för meddelandeformat. De betyder inte att ett godtyckligt formulärfält ska tillåtas för att tillhandahålla rubrikavgränsare eller fortsättningslinjer. En applikation måste skilja data avsedda för ett fält från strukturen som separerar fält.
Rubrikinjektion är felläget där externt styrd data korsar den strukturella gränsen och påverkar rubriker bortom dess avsedda position. Dess praktiska inverkan beror på postbiblioteket, API, transport och auktoriseringsmodell. Anta inte att varje ny rad som accepteras av ett webbformulär når SMTP oförändrat. Anta inte heller att en nedströms undertecknare reparerar ett osäkert byggbeslut. En signatur kan täcka meddelandet som applikationen faktiskt producerade, inklusive ett oönskat men syntaktiskt giltigt resultat.
Lagerinmatning och auktoritet innan du väljer validering
Bygg en fältkarta för applikationen. Registrera var ett värde kommer från, vilken komponent som analyserar det, dess avsedda typ, vem som får leverera det och var det hamnar. Skilj en displayetikett från en adress, ett ämne från en kropp och synliga mottagarfält från transportkuvertet. En kontaktadress som lämnats av en besökare bör inte automatiskt bli auktoriserad kuvertsändare. Ett supportformulärs kundidentifierare ska inte behandlas som en obegränsad mottagarlista.
Definiera affärsbegränsningar först. Vissa applikationer behöver exakt en mottagare vald från en intern mappning; andra stöder legitimt flera godkända mottagare. Fritext kan vara acceptabel i brödtexten men inte i ett routingfält. Tillämpa gränser för storlek och kardinalitet och avvisa oväntade strukturella tecken där fältkontraktet förbjuder dem. Dessa är föreslagna applikationskrav, inte ett påstående om att RFC 5322 kräver en valideringsimplementering för varje språk eller produkt.
Föredrar strukturerad konstruktion, verifiera sedan dess beteende
Använd det strukturerade e-postgränssnittet som stöds för det valda ramverket istället för att manuellt sammanfoga hela rubrikrader från indata. De Python EmailMessage-dokumentation illustrerar denna separation: objektet representerar rubriker och nyttolast, erbjuder fältoperationer och serialiseras enligt en e-postpolicy. Den varnar också för att utjämning kan utlösa förändringar som att generera MIME gränser. Dessa dokumenterade funktioner fastställer inte att alla program som använder den klassen är säkra, eller att alla biblioteksversioner avvisar samma ogiltiga indata.
Granska den faktiska biblioteksversionen och policyn i programmet innan du förlitar dig på dess hantering. Validera innan du skapar meddelandet och behåll en separat auktoriseringskontroll för destinationer. Undvik en reparationsrutin som tyst tar bort misstänkta tecken och ändrar innebörden av ett värde. Ett förutsägbart avslag med ett säkert fel är ofta lättare att resonera kring än ett värde omvandlat till en annan mottagare. Logga aldrig lösenord, återställ tokens eller fyll aldrig i känsliga anmälningsorgan bara för att felsöka konstruktion.
Ett oförstörande arbetsblad för acceptans
Skapa en kalkylbladsrad för varje indata-till-utdata-sökväg. Inkludera applikationskomponenten, inmatningsfältet, förväntad typ, tillåten destinationskälla, parser- och serialiseringsversioner, valideringsbeslut och förväntat observerbart resultat. Lägg till en kolumn för granskaren som äger fältkontraktet. En företagsägare kan godkänna avsedd mottagarbeteende medan en ingenjör kontrollerar hur implementeringen genomför det; inget godkännande bör härledas från en e-postautentiseringsinstrumentpanel.
Föreslagna lokala fall kan inkludera ett normalt kort ämne, ett tomt obligatoriskt värde, ett överlängdsvärde, oväntade kontrolltecken representerade som testmetadata och en displayetikett som innehåller skiljetecken. Förvara fodralen i en isolerad sele som inte kan ansluta till en e-posttjänst. Inspektera den analyserade meddelandestrukturen istället för att skicka en exploit till en produktionsmottagare. Acceptans innebär att det avsedda fältet förblir inom sitt kontrakt, obehöriga mottagare är omöjliga genom den inmatningsvägen och fel hanteras utan att avslöja hemligheter. Ingen sådan sele utfördes för detta manuskript.
Fiktiv diagnos: en stödform med blandat ansvar
Tänk på ett fiktivt företag, Cedar Support, vars formulär tillåter en besökare att ange en svarsadress och en förfrågningsbeskrivning. En utvecklare låter också en frågeparameter välja destinationsstödkön. Meddelandet passerar DMARC eftersom Cedars godkända tjänst signerar det. Teamet behandlar initialt det resultatet som ett bevis på att formen är säker. Det är bevis på varken mottagarbehörighet eller reglerna för indatavalidering.
Den föreslagna utredningen skiljer två frågor åt. För det första, mappar köparametern endast godkända interna destinationer? För det andra, kan något fritextvärde ändra det serialiserade meddelandets struktur? Teamet skulle granska lokala byggresultat och auktoriseringsbeslut utan att skicka e-post. Även om serialiseraren avvisar felaktiga rubrikdata, kan en obegränsad destinationsparameter förbli en distinkt missbruksväg. Omvänt, en korrekt destinationsgodkännandelista bevisar inte att varje rubrikfält är säkert konstruerat. Detta är ett uppfunnit diagnostiskt scenario, inte en upptäckt sårbarhet eller ett avslutat test.
Frigivningskriterier och bevis behövs fortfarande
Dokumentera vad varje lager bevisar. Ingångsvalidering fastställer att inlämnade data uppfyller applikationens kontrakt. Auktorisationen fastställer om den aktören kan begära den destinationen eller åtgärden. Serialisering ger det avsedda meddelandeformatet. Autentisering hjälper mottagande system att utvärdera domänanvändning. Leveransövervakning avslöjar vad som hände efteråt. Att kombinera dessa lager är användbart just för att ingen ensam bevisar de andra.
Katalogen kräver en försvarbar hotmodell och en oförstörande labbreproduktion knuten till den ursprungliga forskningen. Det beviset är fortfarande öppet. Detta utkast innehåller en föreslagen modell och ett arbetsblad, inte originalforskning eller en labbreproduktion. OWASP-sidor som efterfrågades under forskning var inte tillgängliga och citeras inte som stöd; de testades inte igen via en annan väg. En kvalificerad applikationsgranskare måste verifiera implementeringen, ett kontrollerat labb måste behålla sina faktiska observationer och källans tillämplighet, produktionsvägar, tillgänglighet och ägarens release måste granskas innan publicering. Ingen produktionsinput, referens eller verkligt meddelande behövs för att förstå gränsen som beskrivs här.