ਐਡਮਿਨ ਸਬਡੋਮੇਨ CSRF ਨਹੀਂ ਰੋਕਦਾ: ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਜਾਂਚਾਂ

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

ਓਰੀਜਨ ਅਤੇ ਸਾਈਟ ਨੂੰ ਦੋ ਵੱਖਰੇ ਸ਼ਬਦਾਂ ਵਾਂਗ ਪੜ੍ਹੋ

ਓਰੀਜਨ ਦਾ ਮਤਲਬ ਸਕੀਮ, ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਹੈ, ਇਸ ਲਈ https://www.example.com ਅਤੇ https://admin.example.com ਵੱਖਰੇ ਓਰੀਜਨ ਹਨ। SameSite ਅਰਥ ਵਿੱਚ ਸਾਈਟ ਦਾ ਮਤਲਬ ਸਕੀਮ ਜਮ੍ਹਾਂ ਰਜਿਸਟਰਯੋਗ ਡੋਮੇਨ ਹੈ, ਇਸ ਲਈ ਉਹ ਦੋ ਹੋਸਟਨਾਮ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕੋ ਸਾਈਟ ਹੁੰਦੇ ਹਨ। ਇਹੀ ਫ਼ਰਕ ਪੂਰਾ ਜਾਲ ਹੈ: SameSite ਗੁਣ ਭੈਣ ਸਬਡੋਮੇਨਾਂ ਵਿਚਕਾਰ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਬੇਨਤੀ ਨੂੰ ਸਾਈਟ-ਪਾਰ ਹੀ ਨਹੀਂ ਮੰਨਦਾ। ਐਡਮਿਨ ਇੰਟਰਫੇਸ ਨੂੰ ਸੱਚਮੁੱਚ ਵੱਖਰੇ ਰਜਿਸਟਰਯੋਗ ਡੋਮੇਨ, ਜਿਵੇਂ admin-example.net, ਵੱਲ ਮੋੜੋ, ਤਾਂ ਬੇਨਤੀ ਸੱਚਮੁੱਚ ਸਾਈਟ-ਪਾਰ ਬਣਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ SameSite=Lax ਜਾਂ Strict ਭਰੋਸੇਯੋਗ ਕੰਮ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਇਸ ਬਾਰੇ ਤਰਕ ਕਰਨ ਦੀ ਬਜਾਏ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਪਰਖੋ।

ਜਨਤਕ ਸਾਈਟ ਲੋਡ ਕਰੋ, ਡਿਵੈਲਪਰ ਟੂਲ ਖੋਲ੍ਹੋ ਅਤੇ ਵੇਖੋ ਕਿ ਐਡਮਿਨ ਹੋਸਟ ਵੱਲ ਜਾਣ ਵਾਲੀ ਬੇਨਤੀ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਕਿਹੜੀਆਂ ਕੂਕੀਜ਼ ਜੋੜਦਾ ਹੈ। ਜੇ ਕੂਕੀ ਵਿੱਚ Domain ਗੁਣ ਨਹੀਂ ਹੈ ਤਾਂ ਇਹ ਸਿਰਫ਼ ਹੋਸਟ ਲਈ ਹੈ ਅਤੇ ਆਪਣੇ ਨਾਮ ਉੱਤੇ ਰਹਿੰਦੀ ਹੈ; ਜੇ Domain=example.com ਹੈ ਤਾਂ ਇਹ ਹਰ ਭੈਣ ਕੋਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਸਬਡੋਮੇਨ ਨੇ ਉਸ ਕੂਕੀ ਲਈ ਕੁਝ ਨਹੀਂ ਦਿੱਤਾ।

ਜਵਾਬ ਪੜ੍ਹਨਾ ਅਤੇ ਬੇਨਤੀ ਭੇਜਣਾ ਵੱਖ ਕਰੋ

ਇੱਕੋ ਓਰੀਜਨ ਦੀ ਨੀਤੀ ਓਰੀਜਨਾਂ ਵਿਚਕਾਰ ਜਵਾਬ ਪੜ੍ਹਨ ਨੂੰ ਸੀਮਿਤ ਕਰਦੀ ਹੈ। ਇਹ ਬੇਨਤੀ ਭੇਜਣ ਨੂੰ ਨਹੀਂ ਰੋਕਦੀ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਨੂੰ ਫਾਰਮ ਦੁਆਰਾ ਲਿਜਾਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦੀ। ਸਧਾਰਨ ਬੇਨਤੀ, ਫਾਰਮ ਸਮੱਗਰੀ ਕਿਸਮ ਜਾਂ ਸਾਧਾਰਨ GET ਨਾਲ, ਪਹਿਲਾਂ ਜਾਂਚ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚਦੀ ਹੈ; ਫਿਰ CORS ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਸੱਦਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਜਵਾਬ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। CSRF ਪੂਰੀ ਤਰ੍ਹਾਂ ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ ਰਹਿੰਦਾ ਹੈ।

ਇਸ ਲਈ ਸਰਵਰ ਨੂੰ ਸਥਿਤੀ ਬਦਲਣ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਸਪੱਸ਼ਟ ਜਾਂਚ ਚਾਹੀਦੀ ਹੈ। ਸੈਸ਼ਨ ਨਾਲ ਬੱਧਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਰ ਟੋਕਨ, ਜਾਂ ਸਰਵਰ ਉੱਤੇ ਤੁਲਨਾ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਦੋਹਰੀ ਸਬਮਿਟ ਕੂਕੀ ਇਹ ਹਾਲਤ ਢਕਦੀ ਹੈ; Origin ਜਾਂ Referer ਤੁਲਨਾ ਦੂਜੇ ਗੇਟ ਵਜੋਂ ਜੋੜਨਾ ਯੋਗ ਹੈ, ਪਰ ਇਕੱਲੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਹਰ ਬੇਨਤੀ ਉਹ ਹੈਡਰ ਨਹੀਂ ਲਿਆਉਂਦੀ ਅਤੇ ਹਰ ਪ੍ਰੌਕਸੀ ਉਹ ਸੰਭਾਲਦਾ ਨਹੀਂ। CSRF ਰੋਕਥਾਮ ਲਈ OWASP ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ SameSite ਨੂੰ ਕਈ ਪਰਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੰਨਦਾ ਹੈ, ਇਸੇ ਕਾਰਨ।

ਨੈੱਟਵਰਕ ਗੇਟ ਸੱਚਮੁੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ

ਐਡਮਿਨ ਹੋਸਟ ਸਾਹਮਣੇ VPN ਨਿਕਾਸ ਦੀ ਆਗਿਆ ਸੂਚੀ ਚੰਗਾ ਕੰਟਰੋਲ ਅਤੇ ਕਮਜ਼ੋਰ ਪਛਾਣ ਦਾਅਵਾ ਹੈ। ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਬੇਨਤੀ VPN ਵੱਲੋਂ ਦਿੱਤੇ ਪਤੇ ਤੋਂ ਆਈ, ਜਿਸ ਨੂੰ ਉਸ ਨਿਕਾਸ ਉੱਤੇ ਸਾਰੇ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਪਿੱਛੇ ਕਿਹੜਾ ਵਿਅਕਤੀ ਜਾਂ ਯੰਤਰ ਹੈ। ਇਸ ਨੂੰ ਦਾਖਲਾ ਫਿਲਟਰ ਸਮਝੋ, ਪਛਾਣ ਦੀ ਜਾਂਚ ਨਹੀਂ।

ਇਸ ਨੂੰ ਬੇਨਤੀ-ਪੱਧਰ ਦੀਆਂ ਜਾਂਚਾਂ ਤੋਂ ਸੁਤੰਤਰ ਰੱਖੋ। ਜੇ ਸੂਚੀ ਹਮਲਾਵਰ ਅਤੇ ਸਥਿਤੀ ਬਦਲਣ ਵਾਲੇ ਅੰਤਿਮ ਬਿੰਦੂ ਵਿਚਕਾਰ ਇੱਕੋ ਚੀਜ਼ ਹੈ, ਤਾਂ ਇੱਕ ਗਲਤ ਸੰਰਚਿਤ ਰੂਟ, ਇੱਕ split-tunnel ਕਲਾਇੰਟ ਜਾਂ ਇੱਕ ਉਧਾਰ ਲਿਆ ਲੈਪਟਾਪ ਕੰਟਰੋਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ।

ਉਮੀਦ ਕੀਤੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰਲੇ ਰੱਦ ਵੀ ਲੌਗ ਕਰੋ। ਉਨ੍ਹਾਂ ਦਾ ਉਭਾਰ ਇਹ ਦੱਸਣ ਵਾਲਾ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਸੰਕੇਤ ਹੈ ਕਿ ਕੋਈ ਤੁਹਾਡੀ ਹੁਣੇ ਬਣਾਈ ਸੀਮਾ ਟੋਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਚੁੱਪ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਫਿਲਟਰ ਤੱਕ ਕੁਝ ਪਹੁੰਚਦਾ ਹੀ ਨਹੀਂ।

ਕੂਕੀ, ਲੌਗਇਨ ਅਤੇ ਅਧਿਕਾਰ ਸਪੱਸ਼ਟ ਰੱਖੋ

ਕੂਕੀ ਦਾ ਦਾਇਰਾ ਬਹੁਤਾ ਨਤੀਜਾ ਤੈਅ ਕਰਦਾ ਹੈ। ਮਾਪੇ-ਡੋਮੇਨ ਦੀ ਕੂਕੀ ਐਡਮਿਨ ਹੋਸਟ ਨੂੰ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਜਨਤਕ ਸਾਈਟ ਉੱਤੇ ਸਕ੍ਰਿਪਟ ਇੰਜੈਕਸ਼ਨ ਐਡਮਿਨ ਦੇ ਸੈਸ਼ਨ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ; ਸਿਰਫ਼ ਹੋਸਟ ਲਈ ਕੂਕੀ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਸਿਰਫ਼ ਹੋਸਟ ਵਾਲਾ ਰੂਪ ਚੁਣੋ, Secure ਗੁਣ ਜੋੜੋ ਅਤੇ ਪਲੇਟਫਾਰਮ ਜਿੱਥੇ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ __Host- ਅਗੇਤਰ ਵਰਤੋ, ਕਿਉਂਕਿ ਉਹ ਅਗੇਤਰ Secure, Path=/ ਅਤੇ Domain ਗੁਣ ਨਾ ਹੋਣ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਕੂਕੀ ਜਾਰ ਨਹੀਂ, ਜਵਾਬ ਹੈਡਰ ਪੜ੍ਹੋ: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, Domain ਗੁਣ ਤੋਂ ਬਿਨਾਂ। ਬ੍ਰਾਊਜ਼ਰ Domain ਵਾਲੀ __Host- ਕੂਕੀ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਭੈਣ ਹੋਸਟਾਂ ਉੱਤੇ ਅਜੇ ਵੀ ਦਿਖਣ ਵਾਲੀ ਕੂਕੀ ਸਬੂਤ ਹੈ ਕਿ ਅਗੇਤਰ ਕਦੇ ਲਾਗੂ ਨਹੀਂ ਹੋਇਆ।

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

ਵੰਡ ਤੋਂ ਬਾਅਦ ਸੀਮਾ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਸਿਰਫ਼ ਸੁਖਦ ਰਾਹ ਨਹੀਂ, ਨਕਾਰਾਤਮਕ ਪਰਖ ਚਲਾਓ: ਟੋਕਨ ਤੋਂ ਬਿਨਾਂ ਸਾਈਟ-ਪਾਰ ਫਾਰਮ ਰੱਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਦੂਜੇ ਸੈਸ਼ਨ ਦਾ ਟੋਕਨ ਵੀ ਰੱਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੋਈ GET ਸਥਿਤੀ ਨਹੀਂ ਬਦਲਣੀ ਚਾਹੀਦੀ। ਡਿਵੈਲਪਰ ਟੂਲ ਵਿੱਚ ਕੂਕੀ ਗੁਣ ਜਾਂਚੋ, ਨਾ-ਮਿਲਦੀ ਬੇਨਤੀ ਉੱਤੇ Origin ਜਾਂਚ ਸਰਗਰਮ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਫਿਲਟਰ ਕੰਮ ਕਰਦਾ ਵੇਖਣ ਲਈ VPN ਦਾਇਰੇ ਤੋਂ ਬਾਹਰੋਂ ਐਡਮਿਨ ਹੋਸਟ ਅਜ਼ਮਾਓ।

ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਐਡਮਿਨ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰਲੀ XSS ਖਾਮੀ ਨਹੀਂ ਹਟਾਉਂਦਾ। ਵੱਖਰਾ ਹੋਸਟਨਾਮ ਸੱਚੇ ਮੁੱਲ ਵਾਲੀ ਬ੍ਰਾਊਜ਼ਰ-ਪਾਸੇ ਅਲੱਗਾਵ ਸੀਮਾ ਹੈ, ਅਤੇ ਇਹ ਅਸੁਰੱਖਿਅਤ ਕੋਡ ਚਲਾਉਣ ਦੀ ਰੋਕਥਾਮ ਜਾਂ ਸਰਵਰ-ਪਾਸੇ ਬੇਨਤੀ ਸੁਰੱਖਿਆ ਦਾ ਬਦਲ ਨਹੀਂ। ਵੰਡ ਤੋਂ ਬਾਅਦ ਸੂਚੀ ਦਿਖਣ ਨਾਲੋਂ ਛੋਟੀ ਹੈ: ਵੱਖਰਾ ਓਰੀਜਨ, ਸਿਰਫ਼ ਹੋਸਟ ਲਈ ਕੂਕੀਜ਼, ਹਰ ਤਬਦੀਲੀ ਉੱਤੇ ਟੋਕਨ, ਪਛਾਣ ਵਜੋਂ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲਾ ਦਾਖਲਾ ਫਿਲਟਰ, ਅਤੇ ਹਰ ਬੇਨਤੀ ਲਈ ਤੈਅ ਹੋਣ ਵਾਲਾ ਅਧਿਕਾਰ।