உண்மையான இன்பாக்ஸ்கள் இன்றி OAuth மீட்பு மின்னஞ்சல்களைச் சோதிக்கவும்

OAuth மீட்பு மின்னஞ்சல்களை எளிமையான முறையில் சோதிப்பது பாதுகாப்பு அபாயங்களை உருவாக்குகிறது. பல குழுக்கள் கடவுச்சொல் மாற்றும் இணைப்புகளை (password reset links) ஒரு பொதுவான மின்னஞ்சல் பெட்டிக்கு (shared mailbox) அனுப்புகின்றன. மின்னஞ்சல் வருகிறதா என்று மட்டும் சரிபார்த்துவிட்டு அவர்கள் அடுத்த கட்டத்திற்குச் செல்கிறார்கள். இந்த முறை பலவீனமானது. இது டோக்கன் மறுபயன்பாடு (token reuse), தவறான பயனர் விநியோகம் மற்றும் முக்கியமான லாக் தரவுகளை (sensitive log data) மறைத்துவிடுகிறது.

ஒவ்வொரு சோதனை ஓட்டத்திற்கும் (test run) ஒரு தற்காலிக மின்னஞ்சல் முகவரியைப் பயன்படுத்தவும். நிகழ்வைத் தனிமைப்படுத்தி, அதை ஆய்வு செய்து, தரவை நீக்கவும். இது கலவையான சோதனைத் தரவுகளால் உங்கள் முடிவுகளை நிரூபிப்பதில் ஏற்படும் சிரமங்களைத் தவிர்க்கிறது.

ஒரு சிறந்த அச்சுறுத்தல் மாதிரி (threat model) இந்த கேள்விகளைக் கேட்க வேண்டும்:

• இந்த குறிப்பிட்ட சோதனை ஓட்டத்திற்காக அந்த மின்னஞ்சல் இலக்கு வைக்கப்பட்ட இன்பாக்ஸைச் சென்றடைந்ததா?
• இணைப்பு அல்லது குறியீடு (code) உரிய நேரத்தில் காலாவலாகிறதா?
• தலைப்பு வரி (subject line) அதிகப்படியான பயனர் தரவை வெளிப்படுத்துகிறதா?
• புதிய கோரிக்கைக்குப் பிறகு பழைய டோக்கன் வேலை செய்யுமா?
• லாக்ஸ்கள் (logs) மீட்பு ரகசியங்களைத் தேவையான காலத்தை விட அதிக நேரம் வைத்திருக்கின்றனவா?

ஒவ்வொரு சோதனைச் செயல்பாட்டிற்கும் (test execution) ஒரு இன்பாக்ஸ் என்பதே சிறந்த முறையாகும். இது ஒவ்வொரு இணைப்பையும் நேர முத்திரையையும் (timestamp) ஒரு தனிச் சோதனை ஓட்டத்துடன் இணைத்து வைத்திருக்கும்.

இந்த வழிமுறையைப் பின்பற்றவும்:

• ஒரு புதிய பயனர் ஃபிக்சர் (user fixture) அல்லது சாண்ட்பாக்ஸ் அடையாளத்தை (sandbox identity) உருவாக்கவும்.
• மீட்பு மின்னஞ்சலை அந்தச் சோதனை ஓட்டத்திற்குரிய இன்பாக்ஸிற்கு அனுப்பவும்.
• OAuth அல்லது கடவுச்சொல் மீட்புச் செயல்பாட்டை ஒருமுறை தூண்டவும் (trigger).
• சரியாக ஒரு பொருத்தமான மின்னஞ்சல் வந்திருப்பதை உறுதி செய்யவும் (Assert).
• காலாவதி மற்றும் ஒருமுறை மட்டுமே பயன்படுத்தும் தன்மையைச் சரிபார்க்க இணைப்பை அல்லது குறியீட்டைத் திறக்கவும்.
• இன்பாக்ஸ் மற்றும் ஃபிக்சர் தரவை உடனடியாக அழிக்கவும்.

உங்கள் செயல்முறை நேற்றைய பழைய மின்னஞ்சல்களைச் சரிபார்க்க வேண்டியிருந்தால், உங்கள் செயல்முறை தவறானது. மீட்புச் சான்றுகள் (recovery proof) ஒருபோதும் பழைய தரவைச் (stale data) சார்ந்திருக்கக் கூடாது.

வெளியிடுவதற்கு (shipping) முன் இந்தத் புள்ளிகளைச் சரிபார்க்கவும்:

• பெறுநரின் விளிம்புப் பெயர் (recipient alias) சோதனை அடையாளத்துடன் ஒத்துப்போகிறதா?
• அந்த நிகழ்விற்காக ஒரு செல்லுபடியாகும் மீட்புச் செய்தி மட்டுமே உள்ளதா?
• தலைப்பு மற்றும் முன்னோட்டம் (preview) முக்கியமான தரவுகளை வெளிப்படுத்தாதவாறு உள்ளதா?
• மீட்பு URL சரியான சூழலை (environment) நோக்கியுள்ளதா?
• பயன்பாட்டிற்குப் பிறகும் அல்லது காலாவதியான பின்னரும் டோக்கன் செல்லாததாகிறதா?
• மீண்டும் முயற்சிக்கும் போது (retry behavior) ஒன்றுக்கும் மேற்பட்ட செல்லுபடியாகும் டோக்கன்கள் செயல்பாட்டில் இல்லையென்பதை உறுதி செய்யவும்.

இந்த பொதுவானத் தவறுகளைத் தவிர்க்கவும்:

• பல சோதனைப் பயனர்களுக்கு ஒரே இன்பாக்ஸைப் பயன்படுத்துதல்.
• மீட்பு URL-களை நீண்ட காலம் இருக்கும் லாக்ஸஸில் சேமித்தல்.
• மீட்புத் தலைப்புகளில் முழு மின்னஞ்சல் முகவரிகளையும் சேர்த்தல்.
• இரண்டாவது கோரிக்கைக்குப் பிறகு பழைய இணைப்புகளைச் செல்லாததாக்க மறப்பது.

ஸ்டேஜிங் தரவு (Staging data) முக்கியமானது. இதில் பெரும்பாலும் யதார்த்தமான பெயர்கள் மற்றும் கட்டமைப்புகள் (configurations) இருக்கும். பாதுகாப்பான இயல்புநிலைகளைப் (safe defaults) பயன்படுத்தவும்: குறுகிய காலத் தக்கவைப்பு (short retention), ஒருமுறை மட்டுமே பயன்படுத்தும் ரகசியங்கள் மற்றும் தெளிவான சுத்திகரிப்பு (explicit cleanup).

ஆதாரம்: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni