నిజమైన ఇన్‌బాక్స్‌లు లేకుండా OAuth రికవరీ ఈమెయిల్స్‌ను పరీక్షించండి

OAuth రికవరీ ఈమెయిల్స్‌ను సులభమైన పద్ధతిలో పరీక్షించడం వల్ల భద్రతా పరమైన రిస్క్‌లు ఏర్పడతాయి. చాలా బృందాలు పాస్‌వర్డ్ రీసెట్ లింక్‌లను ఒకే షేర్డ్ మెయిల్‌బాక్స్‌కు పంపుతాయి. ఈమెయిల్ వచ్చిందో లేదో చూసి వారు ముందుకు వెళ్ళిపోతారు. ఈ పద్ధతి బలహీనమైనది. ఇది టోకెన్ పునర్వినియోగం (token reuse), తప్పు వినియోగదారునికి డెలివరీ కావడం మరియు సున్నితమైన లాగ్ డేటా వంటి అంశాలను దాచిపెడుతుంది.

ప్రతి టెస్ట్ రన్ కోసం ఒక డిస్పోజబుల్ (disposable) ఈమెయిల్ అడ్రస్‌ను ఉపయోగించండి. ఈవెంట్‌ను వేరు చేసి, దానిని పరిశీలించి, ఆ డేటాను తొలగించండి. దీనివల్ల మిశ్రమ టెస్ట్ డేటా వల్ల మీ ఫలితాలను నిరూపించడం కష్టతరం కాకుండా ఉంటుంది.

ఒక మంచి థ్రెట్ మోడల్ (threat model) ఈ క్రింది ప్రశ్నలను అడగాలి:

  • ఈ నిర్దిష్ట రన్ కోసం సందేశం ఉద్దేశించిన ఇన్‌బాక్స్‌కు చేరుకుందా?
  • లింక్ లేదా కోడ్ నిర్ణీత సమయంలో గడువు ముగుస్తుందా?
  • సబ్జెక్ట్ లైన్ వినియోగదారు డేటాను ఎక్కువగా బయటపెడుతుందా?
  • కొత్త రిక్వెస్ట్ తర్వాత పాత టోకెన్ పనిచేస్తుందా?
  • లాగ్‌లు రికవరీ సీక్రెట్‌లను అవసరానికి మించి ఎక్కువ కాలం ఉంచుతున్నాయా?

ప్రతి టెస్ట్ ఎగ్జిక్యూషన్‌కు ఒక ఇన్‌బాక్స్ ఉండటమే ఉత్తమమైన పద్ధతి. ఇది ప్రతి లింక్ మరియు టైమ్‌స్టాంప్‌ను ఒకే రన్‌కు అనుసంధానించబడి ఉండేలా చేస్తుంది.

ఈ ఫ్లో (flow) అనుసరించండి:

  • కొత్త యూజర్ ఫిక్చర్ (user fixture) లేదా సాండ్‌బాక్స్ ఐడెంటిటీని సృష్టించండి.
  • రికవరీ ఈమెయిల్‌ను రన్-స్కోప్డ్ (run-scoped) ఇన్‌బాక్స్‌కు పంపండి.
  • OAuth లేదా పాస్‌వర్డ్ రికవరీ చర్యను ఒకసారి ట్రిగ్గర్ చేయండి.
  • సరిగ్గా ఒకే ఒక సరిపోలే ఈమెయిల్ వచ్చిందని నిర్ధారించుకోండి (Assert).
  • గడువు ముగింపు మరియు సింగిల్-యూజ్ (single-use) ప్రవర్తనను ధృవీకరించడానికి లింక్ లేదా కోడ్‌ను తెరవండి.
  • ఇన్‌బాక్స్ మరియు ఫిక్చర్ డేటాను వెంటనే తొలగించండి.

మీ ప్రక్రియ నిన్నటి పాత ఈమెయిల్స్‌ను తనిఖీ చేయాల్సి వస్తే, మీ ప్రక్రియలో లోపం ఉన్నట్లే. రికవరీ నిరూపణ ఎప్పుడూ పాత (stale) డేటాపై ఆధారపడకూడదు.

షిప్పింగ్ (shipping) చేసే ముందు ఈ అంశాలను తనిఖీ చేయండి:

  • రిసిపియంట్ ఏలియాస్ (recipient alias) టెస్ట్ ఐడెంటిటీతో సరిపోలుతుంది.
  • ఈవెంట్ కోసం ఒకే ఒక చెల్లుబాటు అయ్యే రికవరీ సందేశం ఉంటుంది.
  • సబ్జెక్ట్ మరియు ప్రివ్యూ సున్నితమైన డేటాను బయటపెట్టవు.
  • రికవరీ URL సరైన ఎన్విరాన్మెంట్‌ను సూచిస్తుంది.
  • ఉపయోగించిన తర్వాత లేదా గడువు ముగిసిన తర్వాత టోకెన్ చెల్లదు.
  • రీట్రై (retry) ప్రవర్తన వల్ల బహుళ చెల్లుబాటు అయ్యే టోకెన్‌లు యాక్టివ్‌గా ఉండవు.

ఈ సాధారణ వైఫల్యాలను నివారించండి:

  • పలువురు టెస్ట్ వినియోగదారుల కోసం ఒకే ఇన్‌బాక్స్‌ను మళ్లీ ఉపయోగించడం.
  • రికవరీ URLలను ఎక్కువ కాలం ఉండే లాగ్‌లలో నిల్వ చేయడం.
  • రికవరీ సబ్జెక్ట్‌లలో పూర్తి ఈమెయిల్ అడ్రస్‌లను చేర్చడం.
  • రెండవ రిక్వెస్ట్ తర్వాత పాత లింక్‌లను చెల్లకుండా (invalidate) చేయడం మర్చిపోవడం.

స్టేజింగ్ డేటా (Staging data) ముఖ్యం. ఇందులో తరచుగా వాస్తవిక పేర్లు మరియు కాన్ఫిగరేషన్‌లు ఉంటాయి. సురక్షితమైన డిఫాల్ట్‌లను ఉపయోగించండి: తక్కువ రిటెన్షన్ (retention), వన్-టైమ్ సీక్రెట్‌లు మరియు స్పష్టమైన క్లీనప్ (cleanup).

Source: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni