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

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

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

ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜੇਕਰ ਫਰੰਟਐਂਡ ਸਿਰਫ "ਸਮੱਗਰੀ-ਲੰਬਾਈ" ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਪਰ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਚੰਕਡ" ਨੂੰ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Akamai CDN ਨੇ ਅਜਿਹਾ ਕੀਤਾ) ਜਾਂ ਇਸਦੇ ਉਲਟ। ਜੇਕਰ ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: chunked ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਸਮਰਥਿਤ ਹੈ, ਤਾਂ HTTP ਹੈਡਰ ਪਾਰਸਰਾਂ ਦੀਆਂ ਲਾਗੂਕਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਹਮਲੇ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਫਰੰਟ ਐਂਡ "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: xchunked", "ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: chunked" ਵਰਗੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ ”, “ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ” :[ਟੈਬ]ਚੰਕਡ”, “X: X[\n]ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਚੰਕਡ”, “ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ[\n]: ਚੰਕਡ” ਜਾਂ “ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਚੰਕਡ”, ਅਤੇ ਬੈਕਐਂਡ ਉਹਨਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ)

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

ਵਰਤੇ ਗਏ ਫਰੰਟਐਂਡ-ਬੈਕਐਂਡ ਸੁਮੇਲ ਵਿੱਚ ਸਮੱਸਿਆ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ, ਤੁਸੀਂ ਫਰੰਟਐਂਡ ਰਾਹੀਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਇੱਕ ਬੇਨਤੀ ਭੇਜ ਸਕਦੇ ਹੋ:

HTTP/1.1 ਬਾਰੇ ਪੋਸਟ ਕਰੋ
ਹੋਸਟ: example.com
ਟ੍ਰਾਂਸਫਰ-ਏਨਕੋਡਿੰਗ: ਟੁਕੜਾ
ਸਮਗਰੀ-ਲੰਬਾਈ: ਐਕਸਐਨਯੂਐਮਐਕਸ

1
Z
Q

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

ਅਸਲ ਹਮਲਾ ਕਰਨਾ ਹਮਲਾ ਕੀਤਾ ਸਾਈਟ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਟ੍ਰੇਲੋ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਹਮਲਾ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਬੇਨਤੀ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ("PUT /1/members/1234... x=x&csrf ਵਰਗੇ ਡੇਟਾ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ) =1234&username=testzzz&bio=cake") ਅਤੇ ਇੱਕ ਤੀਜੀ-ਧਿਰ ਉਪਭੋਗਤਾ ਦੀ ਅਸਲ ਬੇਨਤੀ ਅਤੇ ਇਸ ਵਿੱਚ ਨਿਰਦਿਸ਼ਟ ਪ੍ਰਮਾਣਿਕਤਾ ਕੂਕੀ ਸਮੇਤ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜੋ। saas-app.com 'ਤੇ ਹਮਲੇ ਲਈ, ਜਵਾਬ ਵਿੱਚ JavaScript ਕੋਡ ਨੂੰ ਬੇਨਤੀ ਮਾਪਦੰਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਬਦਲ ਕੇ ਬਦਲਣਾ ਸੰਭਵ ਹੋਇਆ। redhat.com 'ਤੇ ਹਮਲੇ ਲਈ, ਹਮਲਾਵਰ ਦੀ ਵੈੱਬਸਾਈਟ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਹੈਂਡਲਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ (ਫਾਰਮ ਦੀ ਬੇਨਤੀ “POST/search?dest=../assets/idx?redir=//[ਈਮੇਲ ਸੁਰੱਖਿਅਤ]/ HTTP/1.1")।

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

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ 2005 ਵਿਚ ਸੀ ਪ੍ਰਸਤਾਵਿਤ ਇੱਕ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਸਮਾਨ ਬੇਨਤੀ ਸਪੂਫਿੰਗ ਤਕਨੀਕ ਜੋ ਤੁਹਾਨੂੰ ਕੈਚਿੰਗ ਪ੍ਰੌਕਸੀਜ਼ (ਟੌਮਕੈਟ, ਸਕੁਇਡ, ਮੋਡ_ਪ੍ਰੌਕਸੀ) ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਧੋਖਾ ਦੇਣ ਜਾਂ ਇੱਕ HTTP ਸੈਸ਼ਨ ਵਿੱਚ ਕਈ "GET" ਜਾਂ "POST" ਬੇਨਤੀਆਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਕੇ ਫਾਇਰਵਾਲ ਬਲਾਕਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਸਰੋਤ: opennet.ru