ફ્રન્ટ-એન્ડ-બેક-એન્ડ સિસ્ટમ્સ પર હુમલો જે અમને તૃતીય-પક્ષ વિનંતીઓમાં ફાચર કરવાની મંજૂરી આપે છે

જાહેર કર્યું ફ્રન્ટ-એન્ડ-બેક-એન્ડ મોડલનો ઉપયોગ કરતી સાઇટ્સ પરના નવા હુમલાની વિગતો, જેમ કે સામગ્રી ડિલિવરી નેટવર્ક્સ, લોડ બેલેન્સર્સ અથવા પ્રોક્સીઓ દ્વારા ચાલતી સાઇટ્સ. હુમલો, અમુક વિનંતીઓ મોકલીને, ફ્રન્ટ એન્ડ અને બેકએન્ડ વચ્ચે સમાન થ્રેડમાં પ્રક્રિયા કરાયેલી અન્ય વિનંતીઓની સામગ્રીમાં ફાચર કરવાની મંજૂરી આપે છે. પ્રસ્તાવિત પદ્ધતિનો સફળતાપૂર્વક ઉપયોગ હુમલાને ગોઠવવા માટે કરવામાં આવ્યો હતો જેણે પેપાલ સેવાના વપરાશકર્તાઓના પ્રમાણીકરણ પરિમાણોને અટકાવવાનું શક્ય બનાવ્યું હતું, જેણે સંશોધકોને અનપેચ્ડ નબળાઈઓની હાજરી વિશે જાણ કરવા માટેના પ્રોગ્રામના ભાગ રૂપે લગભગ 40 હજાર ડોલર ચૂકવ્યા હતા. હુમલો અકામાઈ કન્ટેન્ટ ડિલિવરી નેટવર્કનો ઉપયોગ કરતી સાઇટ્સ પર પણ લાગુ પડે છે.

સમસ્યાનું મુખ્ય કારણ એ છે કે ફ્રન્ટ એન્ડ અને બેકએન્ડ ઘણીવાર HTTP પ્રોટોકોલ માટે વિવિધ સ્તરના સપોર્ટ પૂરા પાડે છે, પરંતુ તે જ સમયે વિવિધ વપરાશકર્તાઓની વિનંતીઓને એક સામાન્ય ચેનલમાં સમાવિષ્ટ કરે છે. ફ્રન્ટએન્ડ પ્રાપ્ત વિનંતીઓ અને બેકએન્ડ પ્રોસેસિંગ વિનંતીઓને જોડવા માટે, લાંબા સમય સુધી ચાલતું TCP કનેક્શન સ્થાપિત કરવામાં આવે છે, જેના દ્વારા વપરાશકર્તા વિનંતીઓ ટ્રાન્સમિટ થાય છે, એક પછી એક સાંકળ સાથે પ્રસારિત થાય છે, HTTP પ્રોટોકોલ દ્વારા અલગ કરવામાં આવે છે. વિનંતીઓને અલગ કરવા માટે, હેડરો "સામગ્રી-લંબાઈ" (વિનંતિમાં ડેટાનું કુલ કદ નક્કી કરે છે) અને "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ"("{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" ફોર્મેટમાં વિવિધ કદના બ્લોક્સનો ઉલ્લેખ કરીને, તમને ભાગોમાં ડેટા ટ્રાન્સફર કરવાની મંજૂરી આપે છે).

સમસ્યા ઊભી થાય છે જો ફ્રન્ટએન્ડ ફક્ત "સામગ્રી-લંબાઈ" ને સપોર્ટ કરે છે પરંતુ "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" (ઉદાહરણ તરીકે, અકામાઈ સીડીએનએ આ કર્યું) અથવા તેનાથી વિપરીત અવગણના કરે છે. જો ટ્રાન્સફર-એનકોડિંગ: chunked બંને બાજુએ સપોર્ટેડ છે, તો HTTP હેડર પાર્સર્સની અમલીકરણ સુવિધાઓનો ઉપયોગ હુમલા માટે થઈ શકે છે (ઉદાહરણ તરીકે, જ્યારે આગળનો છેડો "ટ્રાન્સફર-એનકોડિંગ: xchunked", "ટ્રાન્સફર-એનકોડિંગ: chunked" જેવી રેખાઓને અવગણે છે. ”, “ટ્રાન્સફર-એનકોડિંગ” :[ટૅબ]ચંક્ડ", "X: X[\n]ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ", "ટ્રાન્સફર-એનકોડિંગ[\n]: ચંક્ડ" અથવા "ટ્રાન્સફર-એનકોડિંગ : કટ્ડ", અને બેકએન્ડ તેમને સફળતાપૂર્વક પ્રક્રિયા કરે છે).

આ કિસ્સામાં, હુમલાખોર એવી વિનંતી મોકલી શકે છે જેમાં "સામગ્રી-લંબાઈ" અને "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" હેડર બંને હોય છે, પરંતુ "સામગ્રી-લંબાઈ" માંનું કદ ચંક કરેલ સાંકળના કદને અનુરૂપ નથી, જે વાસ્તવિક મૂલ્ય કરતાં નાનું છે. જો ફ્રન્ટએન્ડ "સામગ્રી-લંબાઈ" અનુસાર વિનંતીને પ્રક્રિયા કરે છે અને ફોરવર્ડ કરે છે અને બેકએન્ડ "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" ના આધારે બ્લોક પૂર્ણ થવાની રાહ જુએ છે, તો પછી "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" પર આધારિત ડેટાનો અંત આવશે. અગાઉ નિર્ધારિત કરો અને વિનંતીની બાકીની પૂંછડી હુમલાખોરની આગલી વિનંતીની શરૂઆતમાં હશે, એટલે કે. હુમલાખોર પછીથી પ્રસારિત કરવામાં આવેલી અન્ય કોઈની વિનંતીની શરૂઆતમાં મનસ્વી ડેટા જોડવામાં સક્ષમ હશે.

વપરાયેલ ફ્રન્ટએન્ડ-બેકએન્ડ સંયોજનમાં સમસ્યાને નિર્ધારિત કરવા માટે, તમે ફ્રન્ટએન્ડ દ્વારા આના જેવી વિનંતી મોકલી શકો છો:

HTTP/1.1 વિશે પોસ્ટ કરો
હોસ્ટ: example.com
ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ
સામગ્રી લંબાઈ: 4

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 ચલાવવા માટે iframe વિનંતીમાં ફેરફાર કરવામાં આવ્યો હતો જે CSP (સામગ્રી સુરક્ષા નીતિ) લાગુ કરવામાં આવી ન હતી).

રસપ્રદ રીતે, 2005 માં હતી સૂચિત અનિવાર્યપણે સમાન વિનંતી સ્પૂફિંગ તકનીક કે જે તમને કેશીંગ પ્રોક્સીઝ (ટોમકેટ, સ્ક્વિડ, મોડ_પ્રોક્સી) માં ડેટાને સ્પૂફ કરવા અથવા એક HTTP સત્રમાં ઘણી “GET” અથવા “POST” વિનંતીઓનો ઉલ્લેખ કરીને બાયપાસ ફાયરવોલ અવરોધિત કરવાની મંજૂરી આપે છે.

સોર્સ: opennet.ru