సమస్య యొక్క సారాంశం ఏమిటంటే, ఫ్రంటెండ్లు మరియు బ్యాకెండ్లు తరచుగా HTTP ప్రోటోకాల్కు వివిధ స్థాయిల మద్దతును అందిస్తాయి, అయితే అదే సమయంలో వేర్వేరు వినియోగదారుల నుండి అభ్యర్థనలను ఒక సాధారణ ఛానెల్లోకి చేర్చడం. ఫ్రంటెండ్ స్వీకరించే అభ్యర్థనలు మరియు బ్యాకెండ్ ప్రాసెసింగ్ అభ్యర్థనలను కనెక్ట్ చేయడానికి, దీర్ఘకాలిక TCP కనెక్షన్ ఏర్పాటు చేయబడింది, దీని ద్వారా వినియోగదారు అభ్యర్థనలు ప్రసారం చేయబడతాయి, HTTP ప్రోటోకాల్ ద్వారా వేరు చేయబడతాయి. అభ్యర్థనలను వేరు చేయడానికి, హెడర్లు "కంటెంట్-లెంగ్త్" (అభ్యర్థనలోని డేటా మొత్తం పరిమాణాన్ని నిర్ణయిస్తుంది) మరియు "
ఫ్రంటెండ్ "కంటెంట్-లెంగ్త్"కి మాత్రమే మద్దతిస్తే సమస్య తలెత్తుతుంది కానీ "బదిలీ-ఎన్కోడింగ్: చంక్డ్" (ఉదాహరణకు, Akamai CDN దీన్ని చేసింది) లేదా వైస్ వెర్సాను విస్మరిస్తుంది. బదిలీ-ఎన్కోడింగ్: చంక్డ్ రెండు వైపులా సపోర్ట్ చేయబడితే, HTTP హెడర్ పార్సర్ల అమలు లక్షణాలు దాడికి ఉపయోగించబడతాయి (ఉదాహరణకు, ఫ్రంట్ ఎండ్ “ట్రాన్స్ఫర్-ఎన్కోడింగ్: xchunked”, “ట్రాన్స్ఫర్-ఎన్కోడింగ్: చంక్డ్ వంటి పంక్తులను విస్మరించినప్పుడు ”, “బదిలీ-ఎన్కోడింగ్” :[టాబ్]చంక్డ్", "X: X[\n]బదిలీ-ఎన్కోడింగ్: చంక్డ్", "ట్రాన్స్ఫర్-ఎన్కోడింగ్[\n]: చంక్డ్" లేదా "ట్రాన్స్ఫర్-ఎన్కోడింగ్ : చంక్డ్", మరియు బ్యాకెండ్ వాటిని విజయవంతంగా ప్రాసెస్ చేస్తుంది).
ఈ సందర్భంలో, దాడి చేసే వ్యక్తి "కంటెంట్-లెంగ్త్" మరియు "ట్రాన్స్ఫర్-ఎన్కోడింగ్: చంక్డ్" హెడర్లు రెండింటినీ కలిగి ఉన్న అభ్యర్థనను పంపవచ్చు, కానీ "కంటెంట్-లెంగ్త్"లోని పరిమాణం చంక్డ్ చైన్ పరిమాణానికి అనుగుణంగా లేదు. వాస్తవ విలువ కంటే చిన్నది. ఫ్రంటెండ్ "కంటెంట్-లెంగ్త్" ప్రకారం అభ్యర్థనను ప్రాసెస్ చేసి ఫార్వార్డ్ చేస్తే మరియు "బదిలీ-ఎన్కోడింగ్: చంక్డ్" ఆధారంగా బ్లాక్ పూర్తయ్యే వరకు బ్యాకెండ్ వేచి ఉంటే, "బదిలీ-ఎన్కోడింగ్: చంక్డ్" ఆధారంగా డేటా ముగింపు అవుతుంది. ముందుగా నిర్ణయించబడుతుంది మరియు అభ్యర్థన యొక్క మిగిలిన తోక దాడి చేసే వ్యక్తి తదుపరి అభ్యర్థన ప్రారంభంలో ఉంటుంది, అనగా. దాడి చేసే వ్యక్తి తదుపరి ప్రసారం చేయబడిన వేరొకరి అభ్యర్థన ప్రారంభానికి ఏకపక్ష డేటాను జోడించగలరు.
ఉపయోగించిన ఫ్రంటెండ్-బ్యాకెండ్ కలయికలో సమస్యను గుర్తించడానికి, మీరు ఫ్రంటెండ్ ద్వారా ఇలాంటి అభ్యర్థనను పంపవచ్చు:
పోస్ట్ / HTTP/1.1 గురించి
హోస్ట్: example.com
బదిలీ-ఎన్కోడింగ్: చంక్డ్
కంటెంట్-పొడవు: 4
1
Z
Q
బ్యాకెండ్ అభ్యర్థనను తక్షణమే ప్రాసెస్ చేయకపోతే మరియు చంక్డ్ డేటా యొక్క చివరి జీరో బౌండింగ్ బ్లాక్ రాక కోసం వేచి ఉంటే సమస్య ఉంది. మరింత పూర్తి తనిఖీ కోసం
నిజమైన దాడిని నిర్వహించడం అనేది దాడి చేయబడిన సైట్ యొక్క సామర్థ్యాలపై ఆధారపడి ఉంటుంది, ఉదాహరణకు, Trello వెబ్ అప్లికేషన్పై దాడి చేస్తున్నప్పుడు, మీరు అభ్యర్థన యొక్క ప్రారంభాన్ని భర్తీ చేయవచ్చు (“PUT /1/members/1234... x=x&csrf వంటి ప్రత్యామ్నాయ డేటా =1234&username=testzzz&bio=cake”) మరియు థర్డ్-పార్టీ యూజర్ యొక్క అసలు అభ్యర్థన మరియు దానిలో పేర్కొన్న ప్రమాణీకరణ కుకీతో సహా సందేశాన్ని పంపండి. saas-app.comపై దాడి కోసం, అభ్యర్థన పారామితులలో ఒకదానిలో ప్రత్యామ్నాయం చేయడం ద్వారా ప్రతిస్పందనలో జావాస్క్రిప్ట్ కోడ్ను భర్తీ చేయడం సాధ్యమవుతుంది. redhat.comపై దాడి కోసం, దాడి చేసేవారి వెబ్సైట్కి దారి మళ్లించడానికి అంతర్గత హ్యాండ్లర్ ఉపయోగించబడింది (“POST /search?dest=../assets/idx?redir=// ఫారమ్ యొక్క అభ్యర్థన[ఇమెయిల్ రక్షించబడింది]/ HTTP/1.1").
కంటెంట్ డెలివరీ నెట్వర్క్ల కోసం పద్ధతిని ఉపయోగించడం వలన "హోస్ట్:" హెడర్ని ప్రత్యామ్నాయం చేయడం ద్వారా అభ్యర్థించిన సైట్ని భర్తీ చేయడం సాధ్యపడింది. కంటెంట్ కాషింగ్ సిస్టమ్ల కంటెంట్లను విషపూరితం చేయడానికి మరియు కాష్ చేయబడిన రహస్య డేటాను సంగ్రహించడానికి కూడా దాడిని ఉపయోగించవచ్చు. ఈ పద్ధతి యొక్క పరాకాష్ట పేపాల్పై దాడిని నిర్వహించడం, ఇది ప్రామాణీకరణ సమయంలో వినియోగదారులు పంపిన పాస్వర్డ్లను అడ్డగించడం సాధ్యమైంది (paypal.com/us/gifts పేజీ సందర్భంలో JavaScriptను అమలు చేయడానికి iframe అభ్యర్థన సవరించబడింది. ఏ CSP (కంటెంట్ సెక్యూరిటీ పాలసీ) వర్తించబడలేదు).
ఆసక్తికరంగా, 2005 లో ఉంది
మూలం: opennet.ru