🥇 MCS ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦਾ ਸੁਰੱਖਿਆ ਆਡਿਟ

ਸਕਾਈਸ਼ਿੱਪ ਡਸਕ ਸੀਰਲਾਈਟ ਦੁਆਰਾ

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

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

ਡਾਊਨਲੋਡ ਉਤਪਾਦ

Mail.ru ਕਲਾਉਡ ਹੱਲ (MCS) ਕਲਾਉਡ ਵਿੱਚ ਵਰਚੁਅਲ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਉਣ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਹੈ। ਇਸ ਵਿੱਚ IaaS, PaaS, ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਤਿਆਰ ਐਪਲੀਕੇਸ਼ਨ ਚਿੱਤਰਾਂ ਦਾ ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਸ਼ਾਮਲ ਹੈ। MCS ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰਾਂ ਵਿੱਚ ਉਤਪਾਦ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਜਾਂਚ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ:

ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਵਾਤਾਵਰਨ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਰੱਖਿਆ ਕਰਨਾ: ਹਾਈਪਰਵਾਈਜ਼ਰ, ਰੂਟਿੰਗ, ਫਾਇਰਵਾਲ;
ਗਾਹਕਾਂ ਦੇ ਵਰਚੁਅਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸੁਰੱਖਿਆ: ਇੱਕ ਦੂਜੇ ਤੋਂ ਅਲੱਗ-ਥਲੱਗ, SDN ਵਿੱਚ ਨੈਟਵਰਕ, ਪ੍ਰਾਈਵੇਟ ਨੈਟਵਰਕ ਸਮੇਤ;
ਓਪਨਸਟੈਕ ਅਤੇ ਇਸਦੇ ਖੁੱਲੇ ਹਿੱਸੇ;
ਸਾਡੇ ਆਪਣੇ ਡਿਜ਼ਾਈਨ ਦਾ S3;
IAM: ਇੱਕ ਰੋਲ ਮਾਡਲ ਦੇ ਨਾਲ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਪ੍ਰੋਜੈਕਟ;
ਵਿਜ਼ਨ (ਕੰਪਿਊਟਰ ਵਿਜ਼ਨ): ਚਿੱਤਰਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ API ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ;
ਵੈੱਬ ਇੰਟਰਫੇਸ ਅਤੇ ਕਲਾਸਿਕ ਵੈੱਬ ਹਮਲੇ;
PaaS ਭਾਗਾਂ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ;
ਸਾਰੇ ਭਾਗਾਂ ਦਾ API।

ਸ਼ਾਇਦ ਇਹੀ ਸਭ ਕੁਝ ਹੈ ਜੋ ਅਗਲੇ ਇਤਿਹਾਸ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।

ਕਿਸ ਕਿਸਮ ਦਾ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਸੀ?

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

ਕੰਮ ਦੇ ਦੌਰਾਨ, ਜੋ ਔਸਤਨ 1-2 ਮਹੀਨਿਆਂ ਤੱਕ ਰਹਿੰਦਾ ਹੈ, ਆਡੀਟਰ ਸੰਭਾਵੀ ਹਮਲਾਵਰਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਨ ਅਤੇ ਚੁਣੀ ਗਈ ਸੇਵਾ ਦੇ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਭਾਗਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹਨ। MCS ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦੇ ਆਡਿਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਹੇਠਾਂ ਦਿੱਤੇ ਟੀਚਿਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਸੀ:

ਸੇਵਾ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ. ਇਸ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦੂਜੇ ਲੋਕਾਂ ਦੇ ਖਾਤਿਆਂ ਵਿੱਚ ਤੁਰੰਤ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰਨਗੀਆਂ।
ਵੱਖ-ਵੱਖ ਖਾਤਿਆਂ ਵਿਚਕਾਰ ਰੋਲ ਮਾਡਲ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਦਾ ਅਧਿਐਨ ਕਰਨਾ। ਇੱਕ ਹਮਲਾਵਰ ਲਈ, ਕਿਸੇ ਹੋਰ ਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਇੱਕ ਲੋੜੀਂਦਾ ਟੀਚਾ ਹੈ।
ਕਲਾਇੰਟ ਸਾਈਡ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ। XSS/CSRF/CRLF/ਆਦਿ। ਕੀ ਖਤਰਨਾਕ ਲਿੰਕਾਂ ਰਾਹੀਂ ਦੂਜੇ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਹਮਲਾ ਕਰਨਾ ਸੰਭਵ ਹੈ?
ਸਰਵਰ ਸਾਈਡ ਕਮਜ਼ੋਰੀਆਂ: RCE ਅਤੇ ਹਰ ਕਿਸਮ ਦੇ ਟੀਕੇ (SQL/XXE/SSRF ਅਤੇ ਹੋਰ)। ਸਰਵਰ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਲੱਭਣਾ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ, ਪਰ ਉਹ ਇੱਕੋ ਸਮੇਂ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਸਮਝੌਤਾ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ।
ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਉਪਭੋਗਤਾ ਹਿੱਸੇ ਦੇ ਅਲੱਗ-ਥਲੱਗ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ। ਇੱਕ ਹਮਲਾਵਰ ਲਈ, ਅਲੱਗ-ਥਲੱਗ ਦੀ ਘਾਟ ਦੂਜੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਵਿਰੁੱਧ ਹਮਲੇ ਦੀ ਸਤਹ ਨੂੰ ਬਹੁਤ ਵਧਾਉਂਦੀ ਹੈ।
ਕਾਰੋਬਾਰੀ ਤਰਕ ਵਿਸ਼ਲੇਸ਼ਣ. ਕੀ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਧੋਖਾ ਦੇਣਾ ਅਤੇ ਮੁਫਤ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ?

ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, "ਗ੍ਰੇ-ਬਾਕਸ" ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ: ਆਡੀਟਰਾਂ ਨੇ ਆਮ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੇ ਨਾਲ ਸੇਵਾ ਨਾਲ ਗੱਲਬਾਤ ਕੀਤੀ, ਪਰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ API ਦੇ ਸਰੋਤ ਕੋਡ ਦੇ ਕੋਲ ਸੀ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਵੇਰਵਿਆਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਦਾ ਮੌਕਾ ਸੀ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਕੰਮ ਦਾ ਕਾਫ਼ੀ ਯਥਾਰਥਵਾਦੀ ਮਾਡਲ: ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਅਜੇ ਵੀ ਹਮਲਾਵਰ ਦੁਆਰਾ ਇਕੱਠੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਇਹ ਸਿਰਫ ਸਮੇਂ ਦੀ ਗੱਲ ਹੈ।

ਕਮਜ਼ੋਰੀਆਂ ਲੱਭੀਆਂ

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

ਉਹਨਾਂ ਥਾਵਾਂ ਨੂੰ ਲੱਭਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਸ਼ੱਕੀ ਜਾਪਦੇ ਹਨ ਜਾਂ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਦੂਜਿਆਂ ਤੋਂ ਬਹੁਤ ਵੱਖਰੇ ਹਨ। ਅਤੇ ਪਹਿਲੀ ਖਤਰਨਾਕ ਕਮਜ਼ੋਰੀ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲੱਭੀ ਗਈ ਸੀ.

IDOR

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

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

MCS ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਆਡੀਟਰਾਂ ਨੇ ਹੁਣੇ ਹੀ ਗੈਰ-ਸੁਰੱਖਿਅਤ ਪਛਾਣਕਰਤਾਵਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਇੱਕ IDOR ਕਮਜ਼ੋਰੀ ਦੀ ਖੋਜ ਕੀਤੀ ਹੈ। ਉਪਭੋਗਤਾ ਦੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ, UUID ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਿਸੇ ਵੀ ਵਸਤੂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਸੀ, ਜੋ ਜਾਪਦਾ ਸੀ, ਜਿਵੇਂ ਕਿ ਸੁਰੱਖਿਆ ਮਾਹਰ ਕਹਿੰਦੇ ਹਨ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਅਸੁਰੱਖਿਅਤ (ਭਾਵ, ਵਹਿਸ਼ੀ ਤਾਕਤ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ)। ਪਰ ਕੁਝ ਇਕਾਈਆਂ ਲਈ, ਇਹ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨਿਯਮਤ ਅਨੁਮਾਨਯੋਗ ਸੰਖਿਆਵਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਉਪਭੋਗਤਾ ID ਨੂੰ ਇੱਕ ਦੁਆਰਾ ਬਦਲਣਾ ਸੰਭਵ ਸੀ, ਦੁਬਾਰਾ ਬੇਨਤੀ ਭੇਜੋ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ACL (ਐਕਸੈਸ ਕੰਟਰੋਲ ਸੂਚੀ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਡੇਟਾ ਐਕਸੈਸ ਨਿਯਮ) ਨੂੰ ਬਾਈਪਾਸ ਕਰਕੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰੋ.

ਸਰਵਰ ਸਾਈਡ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (SSRF)

ਓਪਨਸੋਰਸ ਉਤਪਾਦਾਂ ਬਾਰੇ ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਕੋਲ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਵਿਸਤ੍ਰਿਤ ਤਕਨੀਕੀ ਵਰਣਨ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਫੋਰਮਾਂ ਹਨ ਅਤੇ, ਜੇਕਰ ਤੁਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਹੋ, ਤਾਂ ਹੱਲ ਦਾ ਵੇਰਵਾ। ਪਰ ਇਸ ਸਿੱਕੇ ਦਾ ਇੱਕ ਉਲਟ ਪਾਸੇ ਹੈ: ਜਾਣੀਆਂ ਗਈਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਵੀ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਓਪਨਸਟੈਕ ਫੋਰਮ 'ਤੇ ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਸ਼ਾਨਦਾਰ ਵਰਣਨ ਹਨ [XSS] и [SSRF], ਜਿਸ ਨੂੰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਕੋਈ ਵੀ ਠੀਕ ਕਰਨ ਦੀ ਕਾਹਲੀ ਵਿੱਚ ਨਹੀਂ ਹੈ।

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

SSRF ਕਮਜ਼ੋਰੀਆਂ ਹਮਲੇ ਦੇ ਵਿਕਾਸ ਨੂੰ ਬਹੁਤ ਅੱਗੇ ਵਧਾ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਹਮਲਾਵਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ:

ਹਮਲਾ ਕੀਤੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਤੱਕ ਸੀਮਤ ਪਹੁੰਚ, ਉਦਾਹਰਨ ਲਈ, ਸਿਰਫ਼ ਕੁਝ ਨੈੱਟਵਰਕ ਹਿੱਸਿਆਂ ਰਾਹੀਂ ਅਤੇ ਇੱਕ ਖਾਸ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ;
ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ, ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਤੋਂ ਟ੍ਰਾਂਸਪੋਰਟ ਪੱਧਰ ਤੱਕ ਡਾਊਨਗ੍ਰੇਡ ਕਰਨਾ ਸੰਭਵ ਹੈ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ ਪੂਰਾ ਲੋਡ ਪ੍ਰਬੰਧਨ;
ਸਰਵਰ 'ਤੇ ਲੋਕਲ ਫਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਪਹੁੰਚ (ਜੇਕਰ file:/// ਸਕੀਮ ਸਮਰਥਿਤ ਹੈ);
ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ.

ਓਪਨਸਟੈਕ ਵਿੱਚ ਇੱਕ SSRF ਕਮਜ਼ੋਰੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਣੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਕੁਦਰਤ ਵਿੱਚ "ਅੰਨ੍ਹਾ" ਹੈ: ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਤੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ, ਪਰ ਬੇਨਤੀ ਦੇ ਨਤੀਜੇ ਦੇ ਆਧਾਰ 'ਤੇ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਗਲਤੀਆਂ/ਦੇਰੀ ਮਿਲਦੀਆਂ ਹਨ। . ਇਸਦੇ ਆਧਾਰ 'ਤੇ, ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ 'ਤੇ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਇੱਕ ਪੋਰਟ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਨਾਲ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਨਤੀਜਿਆਂ ਨੂੰ ਘੱਟ ਨਹੀਂ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਉਤਪਾਦ ਵਿੱਚ ਇੱਕ ਬੈਕ-ਆਫਿਸ API ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸਿਰਫ ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੈ। ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਨਾਲ (ਅੰਦਰੂਨੀ ਬਾਰੇ ਨਾ ਭੁੱਲੋ), ਇੱਕ ਹਮਲਾਵਰ ਅੰਦਰੂਨੀ ਤਰੀਕਿਆਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ SSRF ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਉਪਯੋਗੀ URL ਦੀ ਇੱਕ ਅਨੁਮਾਨਿਤ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ, ਤਾਂ SSRF ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ - ਮੁਕਾਬਲਤਨ ਤੌਰ 'ਤੇ, ਖਾਤੇ ਤੋਂ ਖਾਤੇ ਵਿੱਚ ਪੈਸੇ ਟ੍ਰਾਂਸਫਰ ਕਰੋ ਜਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ।

ਇਹ ਪਹਿਲੀ ਵਾਰ ਨਹੀਂ ਹੈ ਜਦੋਂ ਓਪਨਸਟੈਕ ਵਿੱਚ ਇੱਕ SSRF ਕਮਜ਼ੋਰੀ ਦੀ ਖੋਜ ਕੀਤੀ ਗਈ ਹੈ। ਅਤੀਤ ਵਿੱਚ, ਸਿੱਧੇ ਲਿੰਕ ਤੋਂ VM ISO ਚਿੱਤਰਾਂ ਨੂੰ ਡਾਉਨਲੋਡ ਕਰਨਾ ਸੰਭਵ ਸੀ, ਜਿਸ ਦੇ ਨਤੀਜੇ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ ਸਨ। ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਹੁਣ OpenStack ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਭਾਈਚਾਰੇ ਨੇ ਇਸ ਨੂੰ ਸਮੱਸਿਆ ਦਾ ਸਭ ਤੋਂ ਸਰਲ ਅਤੇ ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ ਹੱਲ ਮੰਨਿਆ ਹੈ।

ਅਤੇ ਅੰਦਰ ਇਹ ਹੈਕਰਓਨ ਸੇਵਾ (h1) ਤੋਂ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਰਿਪੋਰਟ, ਉਦਾਹਰਣ ਦੇ ਮੈਟਾਡੇਟਾ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ ਹੁਣ ਅੰਨ੍ਹੇ SSRF ਦਾ ਸ਼ੋਸ਼ਣ ਪੂਰੇ Shopify ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਤੱਕ ਰੂਟ ਪਹੁੰਚ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

MCS ਵਿੱਚ, SSRF ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਇੱਕੋ ਜਿਹੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਨਾਲ ਦੋ ਥਾਵਾਂ 'ਤੇ ਖੋਜੀਆਂ ਗਈਆਂ ਸਨ, ਪਰ ਫਾਇਰਵਾਲਾਂ ਅਤੇ ਹੋਰ ਸੁਰੱਖਿਆ ਦੇ ਕਾਰਨ ਉਹਨਾਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਨਾ ਲਗਭਗ ਅਸੰਭਵ ਸੀ। ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, MCS ਟੀਮ ਨੇ ਭਾਈਚਾਰੇ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ, ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ।

ਸ਼ੈੱਲ ਲੋਡ ਕਰਨ ਦੀ ਬਜਾਏ XSS

ਸੈਂਕੜੇ ਅਧਿਐਨਾਂ ਦੇ ਲਿਖੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਸਾਲ ਦਰ ਸਾਲ XSS (ਕਰਾਸ-ਸਾਈਟ ਸਕ੍ਰਿਪਟਿੰਗ) ਹਮਲਾ ਅਜੇ ਵੀ ਸਭ ਤੋਂ ਵੱਧ ਹੈ ਅਕਸਰ ਸਾਹਮਣਾ ਕੀਤਾ ਵੈੱਬ ਕਮਜ਼ੋਰੀ (ਜਾਂ ਹਮਲਾ?).

ਫਾਈਲ ਅਪਲੋਡ ਕਿਸੇ ਵੀ ਸੁਰੱਖਿਆ ਖੋਜਕਰਤਾ ਲਈ ਇੱਕ ਪਸੰਦੀਦਾ ਸਥਾਨ ਹਨ। ਇਹ ਅਕਸਰ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਆਰਬਿਟਰਰੀ ਸਕ੍ਰਿਪਟ (asp/jsp/php) ਲੋਡ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ OS ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹੋ, ਪੈਨਟੇਸਟਰਾਂ ਦੀ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ - "ਲੋਡ ਸ਼ੈੱਲ"। ਪਰ ਅਜਿਹੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਪ੍ਰਸਿੱਧੀ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ: ਉਹਨਾਂ ਨੂੰ ਯਾਦ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਿਰੁੱਧ ਉਪਚਾਰ ਵਿਕਸਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਹਾਲ ਹੀ ਵਿੱਚ "ਇੱਕ ਸ਼ੈੱਲ ਲੋਡ ਕਰਨ" ਦੀ ਸੰਭਾਵਨਾ ਜ਼ੀਰੋ ਹੋ ਜਾਂਦੀ ਹੈ.

ਹਮਲਾਵਰ ਟੀਮ (ਡਿਜ਼ੀਟਲ ਸੁਰੱਖਿਆ ਦੁਆਰਾ ਪ੍ਰਸਤੁਤ ਕੀਤੀ ਗਈ) ਖੁਸ਼ਕਿਸਮਤ ਸੀ। ਠੀਕ ਹੈ, ਸਰਵਰ ਸਾਈਡ 'ਤੇ MCS ਵਿੱਚ ਡਾਉਨਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਦੀ ਸਮੱਗਰੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਸਿਰਫ਼ ਚਿੱਤਰਾਂ ਦੀ ਇਜਾਜ਼ਤ ਸੀ। ਪਰ SVG ਵੀ ਇੱਕ ਤਸਵੀਰ ਹੈ. SVG ਚਿੱਤਰ ਖਤਰਨਾਕ ਕਿਵੇਂ ਹੋ ਸਕਦੇ ਹਨ? ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚ JavaScript ਸਨਿੱਪਟਾਂ ਨੂੰ ਏਮਬੈਡ ਕਰ ਸਕਦੇ ਹੋ!

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਡਾਉਨਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ MCS ਸੇਵਾ ਦੇ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਉਪਲਬਧ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੂਜੇ ਕਲਾਉਡ ਉਪਭੋਗਤਾਵਾਂ, ਅਰਥਾਤ ਪ੍ਰਬੰਧਕਾਂ 'ਤੇ ਹਮਲਾ ਕਰਨਾ ਸੰਭਵ ਹੈ.

ਫਿਸ਼ਿੰਗ ਲੌਗਇਨ ਫਾਰਮ 'ਤੇ XSS ਹਮਲੇ ਦੀ ਇੱਕ ਉਦਾਹਰਣ

XSS ਹਮਲੇ ਦੇ ਸ਼ੋਸ਼ਣ ਦੀਆਂ ਉਦਾਹਰਨਾਂ:

ਇੱਕ ਸੈਸ਼ਨ ਨੂੰ ਚੋਰੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਿਉਂ ਕਰੋ (ਖਾਸ ਤੌਰ 'ਤੇ ਕਿਉਂਕਿ ਹੁਣ HTTP- ਸਿਰਫ਼ ਕੂਕੀਜ਼ ਹਰ ਥਾਂ ਹਨ, ਜੇਐਸ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਚੋਰੀ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹਨ), ਜੇਕਰ ਲੋਡ ਕੀਤੀ ਸਕ੍ਰਿਪਟ ਤੁਰੰਤ ਸਰੋਤ API ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੀ ਹੈ? ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪੇਲੋਡ ਸਰਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਬਦਲਣ ਲਈ XHR ਬੇਨਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਹਮਲਾਵਰ ਦੀ ਜਨਤਕ SSH ਕੁੰਜੀ ਨੂੰ ਜੋੜੋ ਅਤੇ ਸਰਵਰ ਤੱਕ SSH ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰੋ।
ਜੇਕਰ CSP ਨੀਤੀ (ਸਮੱਗਰੀ ਸੁਰੱਖਿਆ ਨੀਤੀ) JavaScript ਨੂੰ ਇੰਜੈਕਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਰੋਕਦੀ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਇਸ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਸ਼ੁੱਧ HTML ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਈਟ ਲਈ ਇੱਕ ਜਾਅਲੀ ਲੌਗਇਨ ਫਾਰਮ ਬਣਾਓ ਅਤੇ ਇਸ ਉੱਨਤ ਫਿਸ਼ਿੰਗ ਦੁਆਰਾ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਪਾਸਵਰਡ ਚੋਰੀ ਕਰੋ: ਉਪਭੋਗਤਾ ਲਈ ਫਿਸ਼ਿੰਗ ਪੰਨਾ ਉਸੇ URL 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਲਈ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਹਮਲਾਵਰ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦਾ ਹੈ ਗਾਹਕ DoS - 4 KB ਤੋਂ ਵੱਡੀਆਂ ਕੂਕੀਜ਼ ਸੈੱਟ ਕਰੋ। ਉਪਭੋਗਤਾ ਨੂੰ ਸਿਰਫ ਇੱਕ ਵਾਰ ਲਿੰਕ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਾਰੀ ਸਾਈਟ ਉਦੋਂ ਤੱਕ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਉਪਭੋਗਤਾ ਖਾਸ ਤੌਰ 'ਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦਾ: ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਵੈਬ ਸਰਵਰ ਅਜਿਹੇ ਗਾਹਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦੇਵੇਗਾ।

ਆਉ ਇੱਕ ਹੋਰ ਖੋਜੀ XSS ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਵੇਖੀਏ, ਇਸ ਵਾਰ ਇੱਕ ਹੋਰ ਚਲਾਕ ਸ਼ੋਸ਼ਣ ਦੇ ਨਾਲ. MCS ਸੇਵਾ ਤੁਹਾਨੂੰ ਫਾਇਰਵਾਲ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸਮੂਹਾਂ ਵਿੱਚ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਸਮੂਹ ਦਾ ਨਾਮ ਉਹ ਸੀ ਜਿੱਥੇ XSS ਦਾ ਪਤਾ ਲਗਾਇਆ ਗਿਆ ਸੀ। ਇਸਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਸੀ ਕਿ ਵੈਕਟਰ ਨੂੰ ਤੁਰੰਤ ਚਾਲੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ ਦੇਖਦੇ ਸਮੇਂ ਨਹੀਂ, ਪਰ ਜਦੋਂ ਇੱਕ ਸਮੂਹ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ:

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

MCS ਡਿਵੈਲਪਰਾਂ ਲਈ, ਡਾਊਨਲੋਡ ਕੀਤੇ SVG ਚਿੱਤਰਾਂ ਵਿੱਚ XSS ਤੋਂ ਸੁਰੱਖਿਆ ਲਈ (ਜੇ ਉਹਨਾਂ ਨੂੰ ਛੱਡਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ), ਡਿਜੀਟਲ ਸੁਰੱਖਿਆ ਟੀਮ ਨੇ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ:

ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਅਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੋਮੇਨ 'ਤੇ ਰੱਖੋ ਜਿਸਦਾ "ਕੂਕੀਜ਼" ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ। ਸਕ੍ਰਿਪਟ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੋਮੇਨ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਚਲਾਇਆ ਜਾਵੇਗਾ ਅਤੇ MCS ਲਈ ਖ਼ਤਰਾ ਨਹੀਂ ਹੋਵੇਗਾ।
ਸਰਵਰ ਦੇ HTTP ਜਵਾਬ ਵਿੱਚ, “ਸਮੱਗਰੀ-ਵਿਵਸਥਾ: ਅਟੈਚਮੈਂਟ” ਸਿਰਲੇਖ ਭੇਜੋ। ਫਿਰ ਫਾਈਲਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਡਾਊਨਲੋਡ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ ਅਤੇ ਚਲਾਈਆਂ ਨਹੀਂ ਜਾਣਗੀਆਂ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹੁਣ ਡਿਵੈਲਪਰਾਂ ਲਈ XSS ਸ਼ੋਸ਼ਣ ਦੇ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਉਪਲਬਧ ਹਨ:

"ਸਿਰਫ਼ HTTP" ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਸੈਸ਼ਨ "ਕੂਕੀਜ਼" ਸਿਰਲੇਖਾਂ ਨੂੰ ਖਤਰਨਾਕ JavaScript ਲਈ ਪਹੁੰਚਯੋਗ ਬਣਾ ਸਕਦੇ ਹੋ;
CSP ਨੀਤੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਇੱਕ ਹਮਲਾਵਰ ਲਈ XSS ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਨਾ ਹੋਰ ਵੀ ਮੁਸ਼ਕਲ ਬਣਾ ਦੇਵੇਗਾ;
ਆਧੁਨਿਕ ਟੈਂਪਲੇਟ ਇੰਜਣ ਜਿਵੇਂ ਕਿ ਐਂਗੁਲਰ ਜਾਂ ਰੀਐਕਟ ਉਪਭੋਗਤਾ ਦੇ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ ਡੇਟਾ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਰੋਗਾਣੂ-ਮੁਕਤ ਕਰਦੇ ਹਨ।

ਦੋ-ਕਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਕਮਜ਼ੋਰੀਆਂ

ਖਾਤਾ ਸੁਰੱਖਿਆ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਹਮੇਸ਼ਾ 2FA (ਦੋ-ਕਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ) ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਦਰਅਸਲ, ਜੇਕਰ ਉਪਭੋਗਤਾ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਹਮਲਾਵਰ ਨੂੰ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਰੋਕਣ ਦਾ ਇਹ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ ਹੈ।

ਪਰ ਕੀ ਦੂਜੇ ਪ੍ਰਮਾਣਿਕਤਾ ਕਾਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹਮੇਸ਼ਾ ਖਾਤੇ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ? 2FA ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਸੁਰੱਖਿਆ ਮੁੱਦੇ ਹਨ:

OTP ਕੋਡ (ਇੱਕ-ਵਾਰ ਕੋਡ) ਦੀ ਬਰੂਟ-ਫੋਰਸ ਖੋਜ। ਓਪਰੇਸ਼ਨ ਦੀ ਸਾਦਗੀ ਦੇ ਬਾਵਜੂਦ, ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਦੁਆਰਾ OTP ਬਰੂਟ ਫੋਰਸ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਦੀ ਘਾਟ ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਵੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਢਿੱਲਾ ਕੇਸ, ਫੇਸਬੁੱਕ ਕੇਸ.
ਕਮਜ਼ੋਰ ਪੀੜ੍ਹੀ ਐਲਗੋਰਿਦਮ, ਉਦਾਹਰਨ ਲਈ ਅਗਲੇ ਕੋਡ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਯੋਗਤਾ।
ਤਰਕ ਸੰਬੰਧੀ ਤਰੁੱਟੀਆਂ, ਜਿਵੇਂ ਕਿ ਤੁਹਾਡੇ ਫ਼ੋਨ 'ਤੇ ਕਿਸੇ ਹੋਰ ਦੇ OTP ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਯੋਗਤਾ, ਇਸ ਤਰ੍ਹਾਂ ਇਹ ਸੀ Shopify ਤੋਂ.

MCS ਦੇ ਮਾਮਲੇ ਵਿੱਚ, 2FA ਨੂੰ Google Authenticator ਦੇ ਅਧਾਰ ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜੋੜੀ. ਪ੍ਰੋਟੋਕੋਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਸਮੇਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਚੁੱਕੀ ਹੈ, ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਸਾਈਡ 'ਤੇ ਕੋਡ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਜਾਂਚ ਦੇ ਯੋਗ ਹੈ।

MCS 2FA ਕਈ ਥਾਵਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:

ਉਪਭੋਗਤਾ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਵੇਲੇ. ਬਰੂਟ ਫੋਰਸ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਹੈ: ਉਪਭੋਗਤਾ ਕੋਲ ਇੱਕ ਵਾਰ ਦਾ ਪਾਸਵਰਡ ਦਰਜ ਕਰਨ ਲਈ ਸਿਰਫ ਕੁਝ ਕੋਸ਼ਿਸ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਫਿਰ ਇੰਪੁੱਟ ਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ ਬਲੌਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ OTP ਦੀ ਬਰੂਟ-ਫੋਰਸ ਚੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਰੋਕਦਾ ਹੈ।
2FA ਕਰਨ ਲਈ ਔਫਲਾਈਨ ਬੈਕਅੱਪ ਕੋਡ ਤਿਆਰ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਇਸਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਵੇਲੇ। ਇੱਥੇ, ਕੋਈ ਵੀ ਬਰੂਟ ਫੋਰਸ ਸੁਰੱਖਿਆ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ, ਜਿਸ ਨਾਲ ਇਹ ਸੰਭਵ ਹੋ ਗਿਆ ਸੀ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਖਾਤੇ ਲਈ ਇੱਕ ਪਾਸਵਰਡ ਹੈ ਅਤੇ ਇੱਕ ਕਿਰਿਆਸ਼ੀਲ ਸੈਸ਼ਨ ਹੈ, ਤਾਂ ਬੈਕਅੱਪ ਕੋਡਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਜਾਂ 2FA ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਯੋਗ ਕਰਨਾ।

ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਬੈਕਅੱਪ ਕੋਡ ਸਤਰ ਮੁੱਲਾਂ ਦੀ ਉਸੇ ਸੀਮਾ ਵਿੱਚ ਸਥਿਤ ਸਨ ਜੋ OTP ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ, ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ ਕੋਡ ਨੂੰ ਲੱਭਣ ਦੀ ਸੰਭਾਵਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੀ।

"Burp: Intruder" ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ 2FA ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਇੱਕ OTP ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ

ਇਸ ਦਾ ਨਤੀਜਾ

ਕੁੱਲ ਮਿਲਾ ਕੇ, MCS ਇੱਕ ਉਤਪਾਦ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਜਾਪਦਾ ਹੈ। ਆਡਿਟ ਦੇ ਦੌਰਾਨ, ਪੇਂਟਿੰਗ ਟੀਮ ਕਲਾਇੰਟ VM ਅਤੇ ਉਹਨਾਂ ਦੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ, ਅਤੇ ਲੱਭੀਆਂ ਗਈਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ MCS ਟੀਮ ਦੁਆਰਾ ਜਲਦੀ ਠੀਕ ਕੀਤਾ ਗਿਆ ਸੀ।

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

ਹੁਣ MCS ਵਿੱਚ ਦੱਸੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕੀਤੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ। ਅਤੇ ਨਵੇਂ ਲੋਕਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਰੱਖਣ ਅਤੇ ਉਹਨਾਂ ਦੇ ਜੀਵਨ ਕਾਲ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਪਲੇਟਫਾਰਮ ਟੀਮ ਇਹ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ:

ਬਾਹਰੀ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਆਡਿਟ ਕਰਨਾ;
ਸਹਿਯੋਗ ਅਤੇ ਭਾਗੀਦਾਰੀ ਦਾ ਵਿਕਾਸ Mail.ru ਗਰੁੱਪ ਬੱਗ ਬਾਊਂਟੀ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ;
ਸੁਰੱਖਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ. 🙂

ਸਰੋਤ: www.habr.com

MCS ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦਾ ਸੁਰੱਖਿਆ ਆਡਿਟ