ನೈಜ ಇನ್ಬಾಕ್ಸ್ಗಳಿಲ್ಲದೆ OAuth ರಿಕವರಿ ಇಮೇಲ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
OAuth ರಿಕವರಿ ಇಮೇಲ್ಗಳನ್ನು ಸುಲಭವಾದ ರೀತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಭದ್ರತಾ ಅಪಾಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಅನೇಕ ತಂಡಗಳು ಪಾಸ್ವರ್ಡ್ ರಿಸೆಟ್ ಲಿಂಕ್ಗಳನ್ನು ಒಂದೇ ಹಂಚಿಕೆಯ ಇನ್ಬಾಕ್ಸ್ಗೆ ಕಳುಹಿಸುತ್ತವೆ. ಇಮೇಲ್ ಬಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ ಅವರು ಮುಂದುವರಿಯುತ್ತಾರೆ. ಈ ವಿಧಾನವು ದುರ್ಬಲವಾಗಿದೆ. ಇದು ಟೋಕನ್ ಮರುಬಳಕೆ (token reuse), ತಪ್ಪು ಬಳಕೆದಾರರಿಗೆ ವಿತರಣೆ ಮತ್ತು ಸೂಕ್ಷ್ಮ ಲಾಗ್ ಡೇಟಾವನ್ನು ಮರೆಮಾಚುತ್ತದೆ.
ಪ್ರತಿ ಪರೀಕ್ಷಾ ರನ್ಗಾಗಿ (test run) ಒಂದು ಡಿಸ್ಪೋಸಬಲ್ (disposable) ಇಮೇಲ್ ವಿಳಾಸವನ್ನು ಬಳಸಿ. ಘಟನೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ, ಅದನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಡೇಟಾವನ್ನು ಅಳಿಸಿಹಾಕಿ. ಇದು ಮಿಶ್ರಿತ ಪರೀಕ್ಷಾ ಡೇಟಾದಿಂದಾಗಿ ನಿಮ್ಮ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಬೀತುಪಡಿಸುವುದು ಕಷ್ಟವಾಗದಂತೆ ತಡೆಯುತ್ತದೆ.
ಉತ್ತಮ ಬೆದರಿಕೆ ಮಾದರಿಯು (threat model) ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲೇಬೇಕು:
- ಸಂದೇಶವು ಈ ನಿರ್ದಿಷ್ಟ ರನ್ಗಾಗಿ ಉದ್ದೇಶಿತ ಇನ್ಬಾಕ್ಸ್ಗೆ ತಲುಪಿದೆಯೇ?
- ಲಿಂಕ್ ಅಥವಾ ಕೋಡ್ ನಿಗದಿತ ಸಮಯದಲ್ಲಿ ಅವಧಿ ಮುಗಿಯುತ್ತದೆಯೇ?
- ವಿಷಯ ಸಾಲು (subject line) ಅತಿಯಾದ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆಯೇ?
- ಹೊಸ ವಿನಂತಿಯ ನಂತರ ಹಳೆಯ ಟೋಕನ್ ಕೆಲಸ ಮಾಡಬಹುದೇ?
- ಲಾಗ್ಗಳು ರಿಕವರಿ ರಹಸ್ಯಗಳನ್ನು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಇರಿಸಿಕೊಳ್ಳುತ್ತವೆಯೇ?
ಅತ್ಯುತ್ತಮ ಮಾದರಿಯೆಂದರೆ ಪ್ರತಿ ಪರೀಕ್ಷಾ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗೆ (test execution) ಒಂದು ಇನ್ಬಾಕ್ಸ್ ಇರುವುದು. ಇದು ಪ್ರತಿಯೊಂದು ಲಿಂಕ್ ಮತ್ತು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಒಂದೇ ರನ್ಗೆ ಜೋಡಿಸಿಡುತ್ತದೆ.
ಈ ಹರಿವನ್ನು (flow) ಅನುಸರಿಸಿ:
- ಹೊಸ ಬಳಕೆದಾರ ಫಿಕ್ಸ್ಚರ್ (user fixture) ಅಥವಾ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಐಡೆಂಟಿಟಿಯನ್ನು ರಚಿಸಿ.
- ರಿಕವರಿ ಇಮೇಲ್ ಅನ್ನು ರನ್-ಸ್ಕೋಪ್ಡ್ (run-scoped) ಇನ್ಬಾಕ್ಗೆ ಕಳುಹಿಸಿ.
- ಒಮ್ಮೆ OAuth ಅಥವಾ ಪಾಸ್ವರ್ಡ್ ರಿಕವರಿ ಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ.
- ನಿಖರವಾಗಿ ಒಂದು ಹೊಂದಿಕೆಯಾಗುವ ಇಮೇಲ್ ಬಂದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (Assert).
- ಅವಧಿ ಮುಕ್ತಾಯ ಮತ್ತು ಏಕಬಳಕೆಯ ನಡವಳಿಕೆಯನ್ನು驗ುವಿಕರಿಸಲು ಲಿಂಕ್ ಅಥವಾ ಕೋಡ್ ಅನ್ನು ತೆರೆಯಿರಿ.
- ಇನ್ಬಾಕ್ಸ್ ಮತ್ತು ಫಿಕ್ಸ್ಚರ್ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ನಾಶಪಡಿಸಿ.
ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯು ನಿನ್ನೆಯ ಹಳೆಯ ಇಮೇಲ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯು ದೋಷಪೂರಿತವಾಗಿದೆ ಎಂದರ್ಥ. ರಿಕವರಿ ಪುರಾವೆಯು ಎಂದಿಗೂ ಹಳೆಯ (stale) ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರಬಾರದು.
ಶಿಪ್ಪಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಈ ಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:
- ಸ್ವೀಕರಿಸುವವರ ಏಲಿಯಾಸ್ (recipient alias) ಪರೀಕ್ಷಾ ಐಡೆಂಟಿಟಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
- ಘಟನೆಗಾಗಿ ಕೇವಲ ಒಂದು ಮಾನ್ಯವಾದ ರಿಕವರಿ ಸಂದೇಶವಷ್ಟೇ ಇರುತ್ತದೆ.
- ವಿಷಯ (subject) ಮತ್ತು ಪ್ರಿವ್ಯೂ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ.
- ರಿಕವರಿ URL ಸರಿಯಾದ ಎನ್ವಿರಾನ್ಮೆಂಟ್ಗೆ (environment) ಸೂಚಿಸುತ್ತದೆ.
- ಬಳಕೆ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ನಂತರ ಟೋಕನ್ ಅಮಾನ್ಯವಾಗುತ್ತದೆ.
- ಮರುಪ್ರಯತ್ನದ ನಡವಳಿಕೆಯು (retry behavior) ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾನ್ಯವಾದ ಟೋಕನ್ಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಇರಿಸುವುದಿಲ್ಲ.
ಈ ಸಾಮಾನ್ಯ ವೈಫಲ್ಯಗಳನ್ನು ತಪ್ಪಿಸಿ:
- ಹಲವಾರು ಪರೀಕ್ಷಾ ಬಳಕೆದಾರರಿಗಾಗಿ ಒಂದೇ ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು.
- ರಿಕವರಿ URLಗಳನ್ನು ದೀರ್ಘಕಾಲದ ಲಾಗ್ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು.
- ರಿಕವರಿ ವಿಷಯಗಳಲ್ಲಿ ಪೂರ್ಣ ಇಮೇಲ್ ವಿಳಾಸಗಳನ್ನು ಸೇರಿಸುವುದು.
- ಎರಡನೇ ವಿನಂತಿಯ ನಂತರ ಹಳೆಯ ಲಿಂಕ್ಗಳನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಲು ಮರೆಯುವುದು.
ಸ್ಟೇಜಿಂಗ್ ಡೇಟಾ (Staging data) ಮುಖ್ಯವಾಗಿದೆ. ಇದು ಹೆಚ್ಚಾಗಿ ವಾಸ್ತವಿಕ ಹೆಸರುಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸುರಕ್ಷಿತ ಡಿಫಾಲ್ಟ್ಗಳನ್ನು ಬಳಸಿ: ಕಡಿಮೆ ಅವಧಿಯ ಉಳಿಕೆ (short retention), ಏಕಬಳಕೆಯ ರಹಸ್ಯಗಳು ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಕ್ಲೀನಪ್.
ಮೂಲ: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni