આ વેબ સિસ્ટમ્સ જ્યાં ફ્રન્ટએન્ડ HTTP / 2 દ્વારા જોડાણો સ્વીકારે છે અને તેમને HTTP / 1.1 h મારફતે બેકએન્ડમાં પસાર કરે છે"HTTP વિનંતી દાણચોરી" હુમલાના નવા સંસ્કરણ સામે આવ્યા છે, તે ફ્રન્ટએન્ડ અને બેકએન્ડ વચ્ચે સમાન પ્રવાહમાં પ્રોસેસ કરેલા અન્ય વપરાશકર્તાઓની વિનંતીઓની સામગ્રીમાં વિશેષરૂપે ડિઝાઇન કરેલ ક્લાયંટ વિનંતીઓ મોકલીને પરવાનગી આપે છે.
હુમલો દૂષિત જાવાસ્ક્રિપ્ટ કોડ દાખલ કરવા માટે વાપરી શકાય છે કાયદેસર સાઇટ સાથેના સત્રમાં, accessક્સેસ પ્રતિબંધ સિસ્ટમોને બાયપાસ કરો અને પ્રમાણીકરણ પરિમાણોને અટકાવો.
અભ્યાસના લેખક Netflix, Verizon, Bitbucket, Netlify CDN અને Atlassian સિસ્ટમો પર હુમલો કરવાની શક્યતા દર્શાવી, અને નબળાઈઓ ઓળખવા માટે પુરસ્કાર કાર્યક્રમોમાં $ 56.000 મેળવ્યા. F5 નેટવર્ક પ્રોડક્ટ્સમાં પણ સમસ્યાની પુષ્ટિ થઈ છે.
સમસ્યા અપાચે http સર્વર પર mod_proxy ને આંશિક રીતે અસર કરે છે (CVE-2021-33193), આવૃત્તિ 2.4.49 માં અપેક્ષિત સુધારા (વિકાસકર્તાઓને મેની શરૂઆતમાં સમસ્યાની જાણ કરવામાં આવી હતી અને તેને સુધારવા માટે 3 મહિનાનો સમય મળ્યો હતો). Nginx માં, "કન્ટેન્ટ-લેન્ગ્થ" અને "ટ્રાન્સફર-એન્કોડિંગ" હેડરોને એક સાથે સ્પષ્ટ કરવાની ક્ષમતા અગાઉના વર્ઝન (1.21.1) માં અવરોધિત કરવામાં આવી હતી.
નવી પદ્ધતિના સંચાલનના સિદ્ધાંત ટ્રાફિકમાં મેળ ખાતી વિનંતીઓ તે જ સંશોધકે બે વર્ષ પહેલા શોધેલી નબળાઈ સમાન છે, પરંતુ તે ઇન્ટરફેસ સુધી મર્યાદિત છે જે HTTP / 1.1 પર વિનંતીઓ સ્વીકારે છે.
ક્લાસિક "HTTP રિક્વેસ્ટ સ્મગલિંગ" એટેક એ હકીકત પર આધારિત હતો કે ફ્રન્ટએન્ડ્સ અને બેકએન્ડ્સ HTTP "કન્ટેન્ટ-લેન્ગ્થ" હેડર્સના ઉપયોગને અલગ રીતે અર્થઘટન કરે છે (વિનંતીમાં ડેટાનું કુલ કદ નક્કી કરે છે) અને "ટ્રાન્સફર-એન્કોડિંગ: ભાગ" ( તમને ભાગોમાં ડેટા સ્થાનાંતરિત કરવાની મંજૂરી આપે છે) ...
ઉદાહરણ તરીકે, જો ઇન્ટરફેસ ફક્ત "સામગ્રી-લંબાઈ" ને સપોર્ટ કરે છે પરંતુ "ટ્રાન્સફર-એન્કોડિંગ: ફ્રેગ્મેન્ટેડ" ને અવગણે છે, તો હુમલાખોર એક વિનંતી મોકલી શકે છે જેમાં "સામગ્રી-લંબાઈ" અને "સ્થાનાંતરણ-એન્કોડિંગ: ખંડિત" હેડરો હોય, પરંતુ કદ gu "વિષયવસ્તુની લંબાઈ" ભાગવાળા તારના કદ સાથે મેળ ખાતી નથી. આ કિસ્સામાં, ફ્રન્ટએન્ડ "કન્ટેન્ટ લેન્ગ્થ" અનુસાર વિનંતી પર પ્રક્રિયા કરશે અને રીડાયરેક્ટ કરશે, અને બેકએન્ડ "ટ્રાન્સફર એન્કોડિંગ: ચંકડ" ના આધારે બ્લોક પૂર્ણ થવાની રાહ જોશે.
ટેક્સ્ટ્યુઅલ 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 હુમલાના ઉદાહરણ તરીકે, સ્યુડો-હેડરમાં ખોટું માપ સ્પષ્ટ થયેલ છે વિનંતી સબમિટ કરતી વખતે સામગ્રીની લંબાઈ HTTP / 2 થી Netflix. આ વિનંતી હેડરના ઉમેરા તરફ દોરી જાય છે HTTP સામગ્રી-લંબાઈ HTTP / 1.1 દ્વારા બેકએન્ડને whenક્સેસ કરતી વખતે સમાન, પરંતુ કદમાં હોવાથી સામગ્રી-લંબાઈ વાસ્તવિક કરતાં ઓછી છે, કતારમાં ડેટાનો એક ભાગ આગલી વિનંતીની શરૂઆત તરીકે પ્રક્રિયા કરવામાં આવે છે.
બર્પની ટૂલકિટમાં એટેક ટૂલ્સ પહેલેથી જ ઉમેરી દેવામાં આવ્યા છે અને ટર્બો ઘુસણખોર એક્સ્ટેંશન તરીકે ઉપલબ્ધ છે. વેબ પ્રોક્સી, લોડ બેલેન્સર, વેબ એક્સિલરેટર્સ, કન્ટેન્ટ ડિલિવરી સિસ્ટમ્સ અને અન્ય રૂપરેખાંકનો જ્યાં ફ્રન્ટ-એન્ડ-બેકએન્ડ સ્કીમમાં વિનંતીઓ રીડાયરેક્ટ કરવામાં આવે છે તે સમસ્યા માટે સંવેદનશીલ છે.
સ્રોત: https://portswigger.net