[ Toimitettavuus ja lähettäjäsäännöt ]

Magic-link-sähköpostivirheet: seuraa toimitus- ja vanhenemisikkunaa

Erottele myöhässä taikalinkin sähköposti vanhentuneesta, kulutetusta tai virheellisesti uudelleenohjatusta linkistä muokatun päästä päähän -aikajanalla.

EmailAuth -tutkimusryhmä · 3 min lukuaika

[Avainkohdat]

  • Erottele myöhässä taikalinkin sähköposti vanhentuneesta, kulutetusta tai virheellisesti uudelleenohjatusta linkistä muokatun päästä päähän -aikajanalla.
  • Luokittele vanhentuneet, jo käytetyt ja väärin reititetyt linkit erikseen; säilyttää toiston eston tutkiessasi tiettyä vikaa.
Tällä sivulla

Magic-link-virhe voi tapahtua, kun postin toimitus on onnistunut. Viesti saattaa saapua vanhenemisen jälkeen, sovellus saattaa mitätöidä aikaisemman linkin tai uudelleenohjaus saattaa päätyä väärään ympäristöön. Tutki näitä erillisinä hypoteeseina sen sijaan, että käsittelisi jokaista epäonnistunutta sisäänkirjautumista todennustietueen ongelmana.

Jäljitä kaksi matkaa

Postin matka kulkee pyynnöstä luomiseen, jonotukseen ja vastaanotto-palvelimen hyväksymiseen. Sovellusmatka alkaa tunnuksen luomisesta linkkipyyntöön, validointiin ja istunnon perustamiseen. Liity heihin käyttämällä ei-salaista korrelaatiotunnistetta. Älä kirjaa täydellisiä siirtotielinkkejä tai liitä live-linkkiä ulkoiseen skanneriin.

SMTP hyväksyntätapahtuma on todiste siirtovastuusta, ei päättynyt käyttäjäistunto. Pidä tukitarrat täsmällisinä. RFC 5321. Tallenna puuttuva näkyvyys nimenomaisesti, kun palveluntarjoaja paljastaa vain lähetyksen ja lopullisen tilan.

OWASP-kirjausopastus tukee korrelaatiota paljastamatta pääsysalaisuuksia.

OWASP:n salasanan palautusohjeiden turvallisuusperiaatteet sisältävät kertakäyttöiset vanhenevat tunnukset, luotettavat HTTPS-kohteet ja suojauksen tunnuksen vuotamista vastaan. Nämä periaatteet koskevat arkaluontoisten sähköpostilinkkien tarkistamista, mutta lähde koskee salasanattoman kirjautumisen täydellistä määrittelyä. Magic-link-tuote tarvitsee oman uhkamallinsa ja istuntohallintansa. OWASP-nollaustunnuksen opastus.

Tarkista aiottu isäntä, ympäristö, polku ja uudelleenohjaus käyttämällä kertakäyttöisiä testitunnuksia hyväksytyssä testiympäristössä. Tarkista, mitätöikö uudempi pyyntö aiemmat linkit ja mitätöikö onnistunut käyttö tunnuksen. Kirjaa ylös todellinen käytäntö sen sijaan, että olettaisit kaikkien tuotteiden käyttäytyvän samalla tavalla.

Vertaa vanhenemishäiriötä ja kulutushäiriötä

Harkitse kahta hypoteettista merkkiä, jotka on luotu klo 09.00 UTC ja jotka päättyvät klo 09.10. Tapaus A saavuttaa vastaanottimen hyväksynnän klo 09:11, jo minuutti vanhenemisen jälkeen. Tapaus B saavuttaa tämän vaiheen klo 09.01, onnistunut hakemuksen lunastus kirjataan klo 09.02 ja saa toisen yrityksen klo 09.03. Kertakäyttökäytännössä B:n toisen yrityksen pitäisi epäonnistua kuten jo käytetty, vaikka seitsemän minuuttia on jäljellä.

Nämä ovat keksittyjä tapahtumaoletuksia, eivät tila-koneen suorituksia tai varmennettuja tapauksia. Tapaus A ehdottaa ajoitustutkimusta; tapaus B vaatii todisteita aikaisemmasta hakemuksen siirtymisestä. Lyhyempi postin viive ei tekisi B:stä uudelleen käytettävää. Älä määritä varhaista toimintoa turvaskanneriin tai henkilölle pelkästään käyttäjäagenttimerkkijonosta. Korreloi valtuutetut muokatut pyyntötietueet, tilan muutokset ja istuntotapahtumat ennen kuin määrität toimijan.

Jos haluat todellisen viiveen, ota huomioon hidas vaihe ja tarkista jäljellä oleva kelpoisuusbudjetti. Jos kyseessä on ennenaikainen kulutus, tarkista, pystyykö sovellus erottamaan vaarattoman laskeutumispyynnön nimenomaisesta, turvallisesti vahvistetusta toiminnosta, joka muodostaa istunnon. Se on suunnittelukatsaus, ei yleinen korjaustiedosto; Säilytä toiston esto, vanheneminen ja muut tarvittavat säätimet.

Poista tarpeeton markkinointiseuranta arkaluonteisista tililinkeistä hyväksytyn mallin määritysten avulla ja vahvista lopullinen viesti. Kaikki uudelleenohjaukset tai mobiilin täsmälinkkien toiminta vaativat vielä testauksen. Älä koskaan ratkaise ajoittaista vikaa hyväksymällä vanhentuneita tokeneita määräämättömäksi ajaksi.

Testaa ohjatut matkat uudelleen saapumisen viivästymisen, toistuvien pyyntöjen, toiston ja väärän ympäristön reitityksen varalta. Sulje tarkka vikaluokka ja jäljellä olevat aukot. Selkeä luokittelu estää postioperaattoreita ja sovellussuunnittelijoita muuttamasta toistuvasti väärää järjestelmää.

Vaadi erillinen suljin jokaiselle vikaluokalle

Nopeampi saapuminen voi sulkea vanhenemisviivetapauksen vasta sen jälkeen, kun valvottu matka on vahvistanut voimassaolobudjetin. Se ei voi sulkea aikaisempaa kulutusta tai väärän ympäristön tapausta. Tallenna luokka, tuki hakemuksen siirtymiseen ja puuttuvat todisteet ennen syyn osoittamista.

[ Takeaway ]

Erottele myöhässä taikalinkin sähköposti vanhentuneesta, kulutetusta tai virheellisesti uudelleenohjatusta linkistä muokatun päästä päähän -aikajanalla.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Säilytä muokattu aikajana

Toimituksessa ja tokenin käytössä on erilliset kellot.

Seuraavat vaiheet

  1. Liitä korrelaatiotunnisteet.
  2. Tarkista lopulliset valvotut viestit.
  3. Tallenna näkyvyysraot.

CISO / SecOps

Pidä siirtotien linkit yksityisinä

Vianmäärityksen pikakuvake voi paljastaa tilin käytön.

Seuraavat vaiheet

  1. Estä salaisen URL-osoitteen kirjaaminen.
  2. Tarkista token-kulutussuunnittelu.
  3. Testaa vanhenemis- ja toistosäätimet uudelleen.

Perustaja / ei-tekninen

Mittaa onnistunut pääsy

Pelkästään postin hyväksyminen ei täydennä asiakaspolkua.

Seuraavat vaiheet

  1. Seuraa epäonnistumisluokkia.
  2. Määritä yhteinen postin ja sovelluksen omistajuus.
  3. Tarkista ratkaisemattomat käyttäjävaikutukset.

[ UKK ]

Usein kysytyt kysymykset

Voiko toimitettu maaginen linkki silti epäonnistua?

Kyllä. Vanheneminen, aiempi käyttö ja virheellinen reititys voivat epäonnistua postinsiirron onnistumisen jälkeen.

Pitäisikö reaaliaikaiset kirjautumislinkit lähettää julkisiin URL-skannereihin?

Ei. Palvelulinkki voi myöntää pääsyn, eikä sitä saa paljastaa tällä tavalla.

Osoittaako artikkeli, että skannerit kuluttavat maagisia linkkejä?

Ei. Aikaisempi onnistunut lunastus on hypoteettinen tapahtuma, ei todiste skannerista tai postilaatikon toimittajasta.

Miten tapaus A eroaa tapauksesta B?

A on vanhentunut vastaanottajan hyväksymisen yhteydessä; B kulutettiin ennen toista yritystä.

Voiko käyttäjäagentin teksti tunnistaa skannerin lopullisesti?

Ei. Korreloi pyynnön todisteet sovelluksen tilaan ja käsittele määritystä varoen.

Pitäisikö tunnuksen toistotarkistukset poistaa käytöstä luotettavuuden parantamiseksi?

Ei. Pidä toiston esto ja korjaa havaittu virtausvika.

Onko salasanan palautusopas täydellinen salasanaton kirjautuminen?

Ei. Kirjautumiskulku vaatii erillisen uhkamallin ja istunnon hallinnan.

Mitä tulee testata korjauksen jälkeen?

Viive, toistuvat pyynnöt, toisto, lopullinen kohde ja suunniteltu istunnon käyttäytyminen.

[ Lähteet ]

Lähteet

  1. OWASP Unohdin salasanan -huijauslehti

    Osat Johdanto · Salasana unohtunut · Yleiset turvallisuuskäytännöt · URL-tunnukset

  2. RFC 5321 SMTP

    Osat §3.3 · §4.5.4 · §6.1

  3. OWASP Logging Cheat Sheet

    Osat Tapahtuman attribuutit · Poissuljettavat tiedot

[ Sanasto ]

Sanasto

Kantajan linkki
URL-osoite, jonka upotettu salaisuus voi valtuuttaa toiminnan kenelle tahansa, jolla on se.
Kulutustapahtuma
Sovelluksen siirtymä, joka tekee kertakäyttöisen tunnuksen poissa käytöstä myöhempää käyttöä varten.
Uusinta
Myöhempi yritys käyttää uudelleen aiemmin esitettyä valtuustietoa tai tunnusta.

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta