FixVibe
Covered by FixVibehigh

CSRF ਸੁਰੱਖਿਆ: ਅਣਅਧਿਕਾਰਤ ਰਾਜ ਤਬਦੀਲੀਆਂ ਦੇ ਵਿਰੁੱਧ ਬਚਾਅ ਕਰਨਾ

ਕਰਾਸ-ਸਾਈਟ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (CSRF) ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਖਤਰਾ ਬਣਿਆ ਹੋਇਆ ਹੈ। ਇਹ ਖੋਜ ਖੋਜ ਕਰਦੀ ਹੈ ਕਿ ਕਿਵੇਂ Django ਵਰਗੇ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਸੁਰੱਖਿਆ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ ਅਤੇ ਕਿਵੇਂ SameSite ਵਰਗੀਆਂ ਬ੍ਰਾਊਜ਼ਰ-ਪੱਧਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਣਅਧਿਕਾਰਤ ਬੇਨਤੀਆਂ ਦੇ ਵਿਰੁੱਧ ਰੱਖਿਆ-ਵਿੱਚ-ਡੂੰਘਾਈ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।

CWE-352

ਪ੍ਰਭਾਵ

ਕ੍ਰਾਸ-ਸਾਈਟ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (CSRF) ਇੱਕ ਹਮਲਾਵਰ ਨੂੰ ਇੱਕ ਪੀੜਤ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਵੈੱਬਸਾਈਟ 'ਤੇ ਅਣਚਾਹੇ ਕਾਰਵਾਈਆਂ ਕਰਨ ਲਈ ਧੋਖਾ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਪੀੜਤ ਵਰਤਮਾਨ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਹੈ। ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀਆਂ ਵਿੱਚ ਕੂਕੀਜ਼ ਵਰਗੇ ਅੰਬੀਨਟ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਸ ਨੂੰ ਆਪਣੇ ਆਪ ਹੀ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ, ਇੱਕ ਹਮਲਾਵਰ ਸਟੇਟ-ਬਦਲਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ-ਜਿਵੇਂ ਕਿ ਪਾਸਵਰਡ ਬਦਲਣਾ, ਡੇਟਾ ਮਿਟਾਉਣਾ, ਜਾਂ ਲੈਣ-ਦੇਣ ਸ਼ੁਰੂ ਕਰਨਾ-ਉਪਭੋਗਤਾ ਦੀ ਜਾਣਕਾਰੀ ਤੋਂ ਬਿਨਾਂ ਜਾਅਲੀ ਕਰ ਸਕਦਾ ਹੈ।

ਮੂਲ ਕਾਰਨ

CSRF ਦਾ ਮੂਲ ਕਾਰਨ ਕਿਸੇ ਡੋਮੇਨ ਨਾਲ ਸੰਬੰਧਿਤ ਕੂਕੀਜ਼ ਭੇਜਣ ਦਾ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਹੈ ਜਦੋਂ ਵੀ ਉਸ ਡੋਮੇਨ ਨੂੰ ਬੇਨਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਬੇਨਤੀ ਦੀ ਮੂਲ [S1] ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ। ਖਾਸ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਬਿਨਾਂ ਕਿ ਇੱਕ ਬੇਨਤੀ ਜਾਣਬੁੱਝ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਪਣੇ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ, ਸਰਵਰ ਇੱਕ ਜਾਇਜ਼ ਉਪਭੋਗਤਾ ਕਾਰਵਾਈ ਅਤੇ ਇੱਕ ਜਾਅਲੀ ਇੱਕ ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

Django CSRF ਸੁਰੱਖਿਆ ਵਿਧੀ

Django ਮਿਡਲਵੇਅਰ ਅਤੇ ਟੈਂਪਲੇਟ ਏਕੀਕਰਣ [S2] ਦੁਆਰਾ ਇਹਨਾਂ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਇੱਕ ਬਿਲਟ-ਇਨ ਰੱਖਿਆ ਪ੍ਰਣਾਲੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਮਿਡਲਵੇਅਰ ਐਕਟੀਵੇਸ਼ਨ

django.middleware.csrf.CsrfViewMiddleware CSRF ਸੁਰੱਖਿਆ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਡਿਫੌਲਟ [S2] ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਵਿਊ ਮਿਡਲਵੇਅਰ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ CSRF ਹਮਲਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ [S2] ਹੈਂਡਲ ਕੀਤਾ ਗਿਆ ਹੈ।

ਟੈਂਪਲੇਟ ਲਾਗੂ ਕਰਨਾ

ਕਿਸੇ ਵੀ ਅੰਦਰੂਨੀ POST ਫਾਰਮ ਲਈ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ <form> ਤੱਤ [S2] ਦੇ ਅੰਦਰ {% csrf_token %} ਟੈਗ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ, ਗੁਪਤ ਟੋਕਨ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨੂੰ ਸਰਵਰ ਫਿਰ ਉਪਭੋਗਤਾ ਦੇ ਸੈਸ਼ਨ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ।

ਟੋਕਨ ਲੀਕੇਜ ਜੋਖਮ

ਇੱਕ ਨਾਜ਼ੁਕ ਲਾਗੂਕਰਨ ਵੇਰਵੇ ਇਹ ਹੈ ਕਿ {% csrf_token %} ਨੂੰ ਕਦੇ ਵੀ ਬਾਹਰੀ URLs [S2] ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੇ ਫਾਰਮਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਨਾਲ ਕਿਸੇ ਤੀਜੀ ਧਿਰ ਨੂੰ ਗੁਪਤ CSRF ਟੋਕਨ ਲੀਕ ਹੋ ਜਾਵੇਗਾ, ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੀ ਸੈਸ਼ਨ ਸੁਰੱਖਿਆ [S2] ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਜਾਵੇਗਾ।

ਬ੍ਰਾਊਜ਼ਰ-ਪੱਧਰ ਦੀ ਰੱਖਿਆ: ਸਮਾਨ ਸਾਈਟ ਕੂਕੀਜ਼

ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੇ Set-Cookie ਸਿਰਲੇਖ ਲਈ SameSite ਵਿਸ਼ੇਸ਼ਤਾ ਪੇਸ਼ ਕੀਤੀ ਹੈ ਤਾਂ ਜੋ ਬਚਾਅ-ਵਿੱਚ-ਡੂੰਘਾਈ ਵਾਲੀ [S1] ਦੀ ਇੱਕ ਪਰਤ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾ ਸਕੇ।

  • ਸਖਤ: ਕੂਕੀ ਸਿਰਫ ਪਹਿਲੀ-ਪਾਰਟੀ ਸੰਦਰਭ ਵਿੱਚ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਭਾਵ URL ਪੱਟੀ ਵਿੱਚ ਸਾਈਟ ਕੁਕੀ ਦੇ ਡੋਮੇਨ [S1] ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
  • ਲੈਕਸ: ਕੂਕੀ ਨੂੰ ਕਰਾਸ-ਸਾਈਟ ਸਬ-ਰਿਵੇਸਟਾਂ (ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ ਜਾਂ ਫ੍ਰੇਮ) 'ਤੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਪਰ ਉਦੋਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਉਪਭੋਗਤਾ ਮੂਲ ਸਾਈਟ 'ਤੇ ਨੈਵੀਗੇਟ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਮਿਆਰੀ ਲਿੰਕ [S1] ਦੀ ਪਾਲਣਾ ਕਰਕੇ।

FixVibe ਇਸਦੇ ਲਈ ਕਿਵੇਂ ਟੈਸਟ ਕਰਦਾ ਹੈ

FixVibe ਵਿੱਚ ਹੁਣ CSRF ਸੁਰੱਖਿਆ ਇੱਕ ਗੇਟਡ ਸਰਗਰਮ ਜਾਂਚ ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ। ਡੋਮੇਨ ਤਸਦੀਕ ਤੋਂ ਬਾਅਦ, active.csrf-protection ਖੋਜੇ ਗਏ ਸਟੇਟ-ਬਦਲਣ ਵਾਲੇ ਫਾਰਮਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, CSRF-ਟੋਕਨ-ਆਕਾਰ ਦੇ ਇਨਪੁਟਸ ਅਤੇ SameSite ਕੂਕੀ ਸਿਗਨਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਘੱਟ ਪ੍ਰਭਾਵ ਵਾਲੇ ਜਾਅਲੀ-ਮੂਲ ਸਬਮਿਸ਼ਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਕੇਵਲ ਉਦੋਂ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਕੂਕੀ ਜਾਂਚਾਂ ਕਮਜ਼ੋਰ SameSite ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੀ ਫਲੈਗ ਕਰਦੀਆਂ ਹਨ ਜੋ CSRF ਰੱਖਿਆ-ਵਿੱਚ-ਡੂੰਘਾਈ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।