ਅਸਲੀ ਇਨਬਾਕਸਾਂ ਤੋਂ ਬਿਨਾਂ OAuth ਰਿਕਵਰੀ ਈਮੇਲਾਂ ਦੀ ਜਾਂਚ ਕਰੋ

OAuth ਰਿਕਵਰੀ ਈਮੇਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਸੁਰੱਖਿਆ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਲਿੰਕ ਇੱਕ ਸਾਂਝੇ ਮੇਲਬਾਕਸ 'ਤੇ ਭੇਜਦੀਆਂ ਹਨ। ਉਹ ਸਿਰਫ਼ ਇਹ ਦੇਖਦੇ ਹਨ ਕਿ ਈਮੇਲ ਆਈ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਫਿਰ ਅੱਗੇ ਵਧ ਜਾਂਦੇ ਹਨ। ਇਹ ਤਰੀਕਾ ਕਮਜ਼ੋਰ ਹੈ। ਇਹ ਟੋਕਨ ਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ (token reuse), ਗਲਤ-ਯੂਜ਼ਰ ਡਿਲੀਵਰੀ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਲੌਗ ਡੇਟਾ ਨੂੰ ਲੁਕਾ ਲੈਂਦਾ ਹੈ।

ਹਰੇਕ ਟੈਸਟ ਰਨ ਲਈ ਇੱਕ ਡਿਸਪੋਜ਼ੇਬਲ (disposable) ਈਮੇਲ ਪਤਾ ਵਰਤੋ। ਘਟਨਾ ਨੂੰ ਅਲੱਗ ਕਰੋ, ਇਸਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਡੇਟਾ ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿਓ। ਇਹ ਮਿਸ਼ਰਤ ਟੈਸਟ ਡੇਟਾ ਨੂੰ ਤੁਹਾਡੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਾਬਤ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਇੱਕ ਚੰਗੇ ਥ੍ਰੇਟ ਮਾਡਲ (threat model) ਵਿੱਚ ਇਹ ਸਵਾਲ ਪੁੱਛੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ:

  • ਕੀ ਸੁਨੇਹਾ ਇਸ ਖਾਸ ਰਨ ਲਈ ਨਿਰਧਾਰਤ ਇਨਬਾਕਸ ਤੱਕ ਪਹੁੰਚਿਆ?
  • ਕੀ ਲਿੰਕ ਜਾਂ ਕੋਡ ਸਹੀ ਸਮੇਂ 'ਤੇ ਐਕਸਪਾਇਰ (expire) ਹੁੰਦਾ ਹੈ?
  • ਕੀ ਵਿਸ਼ਾ (subject line) ਬਹੁਤ ਜ਼ਿਆਦਾ ਯੂਜ਼ਰ ਡੇਟਾ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ?
  • ਕੀ ਨਵੀਂ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਟੋਕਨ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ?
  • ਕੀ ਲੌਗਜ਼ ਰਿਕਵਰੀ ਗੁਪਤ ਜਾਣਕਾਰੀ ਨੂੰ ਲੋੜ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੱਕ ਰੱਖਦੇ ਹਨ?

ਸਭ ਤੋਂ ਵਧੀਆ ਪੈਟਰਨ ਹਰੇਕ ਟੈਸਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (test execution) ਲਈ ਇੱਕ ਇਨਬਾਕਸ ਹੈ। ਇਹ ਹਰ ਲਿੰਕ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਰਨ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖਦਾ ਹੈ।

ਇਸ ਪ੍ਰਕਿਰਿਆ (flow) ਦੀ ਪਾਲਣਾ ਕਰੋ:

  • ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਫਿਕਸਚਰ (user fixture) ਜਾਂ ਸੈਂਡਬਾਕਸ ਪਛਾਣ ਬਣਾਓ।
  • ਰਿਕਵਰੀ ਈਮੇਲ ਨੂੰ ਰਨ-ਸਕੋਪਡ (run-scoped) ਇਨਬਾਕਸ ਵੱਲ ਭੇਜੋ।
  • OAuth ਜਾਂ ਪਾਸਵਰਡ ਰਿਕਵਰੀ ਐਕਸ਼ਨ ਨੂੰ ਇੱਕ ਵਾਰ ਟ੍ਰਿਗਰ ਕਰੋ।
  • ਇਹ ਯਕੀਨੀ ਬਣਾਓ (assert) ਕਿ ਸਿਰਫ਼ ਇੱਕ ਮੈਚਿੰਗ ਈਮੇਲ ਆਉਂਦੀ ਹੈ।
  • ਐਕਸਪਾਇਰੀ ਅਤੇ ਸਿੰਗਲ-ਯੂਜ਼ ਵਿਵਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਲਿੰਕ ਜਾਂ ਕੋਡ ਖੋਲ੍ਹੋ।
  • ਇਨਬਾਕਸ ਅਤੇ ਫਿਕਸਚਰ ਡੇਟਾ ਨੂੰ ਤੁਰੰਤ ਖਤਮ ਕਰ ਦਿਓ।

ਜੇਕਰ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕੱਲ੍ਹ ਦੀਆਂ ਪੁਰਾਣੀਆਂ ਈਮੇਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਖਰਾਬ ਹੈ। ਰਿਕਵਰੀ ਸਬੂਤ ਕਦੇ ਵੀ ਪੁਰਾਣੇ (stale) ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਸ਼ਿਪਿੰਗ (shipping) ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੁਕਤਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ:

  • ਪ੍ਰਾਪਤਕਰਤਾ ਐਲੀਅਸ (recipient alias) ਟੈਸਟ ਪਛਾਣ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
  • ਘਟਨਾ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਵੈਧ ਰਿਕਵਰੀ ਸੁਨੇਹਾ ਮੌਜੂਦ ਹੈ।
  • ਵਿਸ਼ਾ (subject) ਅਤੇ ਪ੍ਰੀਵਿਊ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦੇ।
  • ਰਿਕਵਰੀ URL ਸਹੀ ਮਾਹੌਲ (environment) ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
  • ਵਰਤੋਂ ਜਾਂ ਐਕਸਪਾਇਰੀ ਤੋਂ ਬਾਅਦ ਟੋਕਨ ਅਵੈਧ ਹੋ ਜਾਂਦਾ ਹੈ।
  • ਰੀਟ੍ਰਾਈ (retry) ਵਿਵਹਾਰ ਕਾਰਨ ਕਈ ਵੈਧ ਟੋਕਨ ਸਰਗਰਮ ਨਹੀਂ ਰਹਿਣੇ ਚਾਹੀਦੇ।

ਇਹਨਾਂ ਆਮ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਚੋ:

  • ਕਈ ਟੈਸਟ ਯੂਜ਼ਰਾਂ ਲਈ ਇੱਕੋ ਇਨਬਾਕਸ ਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ ਕਰਨਾ।
  • ਰਿਕਵਰੀ URL ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੱਖੇ ਜਾਣ ਵਾਲੇ ਲੌਗਜ਼ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ।
  • ਰਿਕਵਰੀ ਵਿਸ਼ਿਆਂ (subjects) ਵਿੱਚ ਪੂਰੇ ਈਮੇਲ ਪਤੇ ਸ਼ਾਮਲ ਕਰਨਾ।
  • ਦੂਜੀ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣੇ ਲਿੰਕਾਂ ਨੂੰ ਅਵੈਧ ਕਰਨ ਵਿੱਚ ਭੁੱਲ ਜਾਣਾ।

ਸਟੇਜਿੰਗ ਡੇਟਾ (Staging data) ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਵਿੱਚ ਅਕਸਰ ਅਸਲੀ ਨਾਮ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੁੰਦੇ ਹਨ। ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟਸ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਘੱਟ ਰਿਟੈਂਸ਼ਨ (retention), ਵਨ-ਟਾਈਮ ਸੀਕਰੇਟਸ, ਅਤੇ ਸਪੱਸ਼ਟ ਸਫਾਈ (cleanup)।

ਸਰੋਤ: https://dev.to/sophiax99/how-to-test-oauth-recovery-emails-without-exposing-real-inboxes-hni