প্রিফলাইট অনুরোধগুলি প্রবর্তনের পিছনে অনুপ্রেরণা কি ছিল?
প্রিফলাইট অনুরোধগুলি প্রবর্তিত হয়েছিল যাতে কোনও ব্রাউজার নিশ্চিত হতে পারে যে এটি নির্দিষ্ট অনুরোধগুলি প্রেরণের আগে এটি কোনও সিওআরএস-সচেতন সার্ভারের সাথে কাজ করছে। এই অনুরোধগুলি এমন দুটি হিসাবে সংজ্ঞায়িত করা হয়েছিল যেগুলি উভয়ই সম্ভাব্য বিপজ্জনক (রাষ্ট্র-পরিবর্তনকারী) এবং নতুন ( একই উত্স নীতিমালার কারণে সিওআরএসের আগে সম্ভব নয় ) ছিল। প্রিফলাইট অনুরোধগুলি ব্যবহার করার অর্থ সার্ভারগুলির অবশ্যই নতুন, সম্ভাব্য বিপজ্জনক প্রকারের অনুরোধটি সিওআরএস সম্ভাব্য করে তুলবে opt
স্পেসিফিকেশনের এই অংশটির এটিই অর্থ : "ক্রস-অরিজিন অনুরোধগুলির বিরুদ্ধে যে এই স্পেসিফিকেশনটির অস্তিত্ব ছিল না তার আগে নির্দিষ্ট ব্যবহারকারী এজেন্টদের কাছ থেকে উত্স তৈরি হতে পারে না এমন সংস্থান থেকে এই সুরক্ষাটি এই স্পেসিফিকেশন সম্পর্কে সচেতন কিনা তা নিশ্চিত করার জন্য একটি প্রিফলাইট অনুরোধ করা হয়েছে।"
তুমি কি আমাকে একটা উদাহরণ দিতে পারবে?
আসুন কল্পনা করুন যে কোনও ব্রাউজার ব্যবহারকারী তাদের ব্যাংকিং সাইটে লগ ইন করেছেন A.com। যখন তারা দূষিতদের নেভিগেট করে B.com, তখন সেই পৃষ্ঠাটিতে কিছু জাভাস্ক্রিপ্ট অন্তর্ভুক্ত থাকে যা একটি DELETEঅনুরোধ প্রেরণ করার চেষ্টা করে A.com/account। যেহেতু ব্যবহারকারী লগ ইন করেছেন A.com, সেই অনুরোধটি যদি প্রেরণ করা হয় তবে এতে কুকিজ অন্তর্ভুক্ত থাকবে যা ব্যবহারকারীকে সনাক্ত করে।
সিওআরএসের আগে ব্রাউজারের একই উত্স নীতিটি এই অনুরোধটি প্রেরণ করা থেকে এটিকে অবরুদ্ধ করে দিত। কিন্তু যেহেতু সিওআরএসের উদ্দেশ্য কেবল এই ধরণের ক্রস-আদি যোগাযোগকে সম্ভব করে তোলা, এটি আর উপযুক্ত নয়।
ব্রাউজারটি কেবল প্রেরণ করতে পারেDELETE এবং সার্ভারটিকে কীভাবে এটি পরিচালনা করতে হয় তা সিদ্ধান্ত নিতে দেয়। কিন্তু যদি A.comসিওআরএস প্রোটোকল সম্পর্কে সচেতন না হয় তবে কী হবে ? এটি এগিয়ে যেতে পারে এবং বিপজ্জনক কার্যকর করতে পারে DELETE। এটি ধরেই নেওয়া যেতে পারে - ব্রাউজারের একই উত্স নীতিমালার কারণে - এটি কখনও অনুরোধটি গ্রহণ করতে পারে নি, এবং এই জাতীয় আক্রমণটির বিরুদ্ধে এটি কখনও কঠোর হতে পারে না।
এই জাতীয় নন-সিআরএস-সচেতন সার্ভারগুলি সুরক্ষিত করার জন্য, প্রোটোকলের জন্য প্রথমে ব্রাউজারটির একটি প্রিফলাইট অনুরোধ প্রেরণ করা প্রয়োজন । এই নতুন ধরণের অনুরোধটি এমন কিছু যা কেবল CORS- সচেতন সার্ভারগুলি যথাযথভাবে প্রতিক্রিয়া জানাতে পারে, এটি ব্রাউজারটিকে আসল পাঠানো নিরাপদ কিনা তা জানার অনুমতি দেয় DELETE।
ব্রাউজারটি সম্পর্কে কেন এই সমস্ত গোলমাল, আক্রমণকারী কেবল DELETEনিজের কম্পিউটার থেকে একটি অনুরোধ পাঠাতে পারে না ?
অবশ্যই, তবে এই জাতীয় অনুরোধে ব্যবহারকারীর কুকিজ অন্তর্ভুক্ত থাকবে না। এই আক্রমণটি প্রতিরোধ করার জন্য ডিজাইন করা হয়েছে এমন আক্রমণটির উপর নির্ভর করে যে ব্রাউজারটি অনুরোধের সাথে অন্যান্য ডোমেনের জন্য কুকিজ (বিশেষত, ব্যবহারকারীর জন্য প্রমাণীকরণের তথ্য) প্রেরণ করবে।
চাই যে শব্দসমূহ ক্রস সাইট অনুরোধ জালিয়াতি , যেখানে সাইটে একটি ফর্ম B.comকরতে POSTকরতে A.comব্যবহারকারীর কুকি ও ক্ষতি না।
সেটা ঠিক. এটি রাখার আরেকটি উপায় হ'ল প্রিফলাইট অনুরোধগুলি তৈরি করা হয়েছিল যাতে নন-সিওআরএস-সচেতন সার্ভারগুলির জন্য সিএসআরএফ আক্রমণ আক্রমণ বৃদ্ধি না করে।
কিন্তু এ খুঁজছেন প্রয়োজনীয়তা "সরল" অনুরোধ preflights প্রয়োজন বোধ করেন না, আমি দেখতে POSTএখনো অনুমোদিত হয়। এটি রাষ্ট্রের পরিবর্তন করতে পারে এবং ঠিক একইভাবে ডেটা মুছতে পারে DELETE!
সেটা সত্য! সিওআরএস আপনার সাইটকে সিএসআরএফ আক্রমণ থেকে রক্ষা করে না। তারপরে আবার সিওআরএস ছাড়া আপনিও সিএসআরএফ আক্রমণ থেকে সুরক্ষিত নন। প্রিফলাইট অনুরোধগুলির উদ্দেশ্যটি কেবল আপনার সিএসআরএফ এক্সপোজারকে প্রাক-সিওআরএস জগতে ইতিমধ্যে বিদ্যমান সীমাবদ্ধ করা।
দীর্ঘশ্বাস. ঠিক আছে, আমি প্রফ্লাইট অনুরোধগুলির প্রয়োজনীয়তার জন্য কৃপণভাবে গ্রহন করি। তবে সার্ভারে থাকা প্রতিটি সংস্থান (URL) এর জন্য কেন আমাদের এটি করতে হবে? সার্ভার হয় হয় CORS পরিচালনা করে না হয় না।
আপনি কি এ ব্যাপারে নিশ্চিত? একক ডোমেনের জন্য অনুরোধগুলি পরিচালনা করার জন্য একাধিক সার্ভারের পক্ষে এটি অস্বাভাবিক নয়। উদাহরণস্বরূপ, এটি এমন এক ক্ষেত্রে হতে পারে যা অনুরোধগুলি A.com/url1এক ধরণের সার্ভার দ্বারা পরিচালিত হয় এবং অনুরোধগুলি A.com/url2অন্য ধরণের সার্ভার দ্বারা পরিচালিত হয়। এটি সাধারণত এমন হয় না যে কোনও একক সংস্থান পরিচালিত সার্ভার সেই ডোমেনের সমস্ত সংস্থান সম্পর্কে সুরক্ষা গ্যারান্টি দিতে পারে।
ফাইন। আপোষ করি। আসুন একটি নতুন সিওআরএস শিরোলেখ তৈরি করুন যা সার্ভারকে ঠিক কোন সংস্থানগুলির জন্য কথা বলতে পারে তা ঠিক করার অনুমতি দেয়, যাতে সেই ইউআরএলগুলিতে অতিরিক্ত প্রিফলাইট অনুরোধগুলি এড়ানো যায়।
ভাল ধারণা! আসলে, শিরোনামটি Access-Control-Policy-Pathকেবল এই উদ্দেশ্যে প্রস্তাব করা হয়েছিল। শেষ পর্যন্ত, যদিও এটি স্পেসিফিকেশনটির বাইরে চলে গেল, স্পষ্টতই কিছু সার্ভারগুলি ভুলভাবে ইউআরআই স্পেসিফিকেশনটি এমনভাবে প্রয়োগ করেছিল যাতে ব্রাউজারের কাছে নিরাপদ বলে মনে হওয়া পাথগুলিতে অনুরোধ করা আসলে ভাঙা সার্ভারগুলিতে নিরাপদ না হত।
এটি কি একটি বুদ্ধিমান সিদ্ধান্ত যা কার্যক্ষমতার চেয়ে সুরক্ষাকে অগ্রাধিকার দিয়েছিল, ব্রাউজারগুলি তত্ক্ষণাত্ বিদ্যমান সার্ভারগুলিকে ঝুঁকিতে না ফেলেই সিওআরএস স্পেসিফিকেশন বাস্তবায়ন করতে দেয়? অথবা কেবলমাত্র নির্দিষ্ট সময়ে একটি নির্দিষ্ট সার্ভারে বাগগুলি সংযুক্ত করার জন্য ব্যান্ড ব্যান্ডউইথ এবং দ্বিগুণ দ্বিগুণতার জন্য ইন্টারনেট ডুমকে সংক্ষিপ্ত করা হয়েছিল?
মতামত পৃথক।
ভাল, খুব কমপক্ষে ব্রাউজারগুলি একটি একক URL- এর জন্য প্রিফলাইটটি ক্যাশে করবে?
হ্যাঁ. যদিও সম্ভবত খুব দীর্ঘ জন্য না। ওয়েবকিট ব্রাউজারগুলিতে সর্বাধিক প্রিফলাইট ক্যাশে সময় বর্তমানে 10 মিনিট ।
দীর্ঘশ্বাস. ঠিক আছে, যদি আমি জানি যে আমার সার্ভারগুলি কর্স-সচেতন, এবং অতএব প্রিফলাইট অনুরোধগুলির দ্বারা প্রদত্ত সুরক্ষাটির প্রয়োজন নেই, তবে সেগুলি এড়াতে কি আমার কোনও উপায় আছে?
আপনার "আসল " অনুরোধগুলির প্রয়োজনীয়তা পূরণ করেছেন তা নিশ্চিত করা আপনার একমাত্র আসল বিকল্প । এর অর্থ হতে পারে কাস্টম শিরোনামগুলি বাদ দেওয়া যা আপনি অন্যথায় অন্তর্ভুক্ত করবেন (যেমন X-Requested-With), মিথ্যা কথা বলা Content-Type, বা আরও অনেক কিছু।
আপনি যা-ই করুন না কেন, আপনাকে অবশ্যই নিশ্চিত করতে হবে যে আপনার জায়গায় যথাযথ সিএসআরএফ সুরক্ষা রয়েছে কারণ সিওআরএস স্পেসিফিকেশন অনিরাপদ সহ "সাধারণ" অনুরোধগুলি প্রত্যাখ্যান করে না POST। যেমন স্পেসিফিকেশনটিতে বলা হয়েছে : "যে সংস্থানগুলির জন্য সহজ অনুরোধগুলির পুনরুদ্ধার ব্যতীত অন্য গুরুত্ব রয়েছে তাদের অবশ্যই ক্রস-সাইট অনুরোধ জালিয়াতি থেকে তাদের রক্ষা করতে হবে"।