GET বা POST হয় অন্যের চেয়ে বেশি সুরক্ষিত?


282

এইচটিটিপি জিইটি এইচটিটিপি পোস্টের সাথে তুলনা করার সময়, সুরক্ষা দৃষ্টিকোণ থেকে পার্থক্যগুলি কী? কোনও একটি পছন্দ কি অন্যের চেয়ে সহজাতভাবে আরও সুরক্ষিত? যদি তাই হয় তবে কেন?

আমি বুঝতে পেরেছি যে পোস্টটি ইউআরএল সম্পর্কিত তথ্য প্রকাশ করে না, তবে এর কোনও বাস্তব মূল্য আছে বা এটি কেবল অস্পষ্টতার মধ্য দিয়ে সুরক্ষা? সুরক্ষা যখন উদ্বেগের বিষয় তখন কখনই থাকতে পারে যে আমার পোষ্টকে পছন্দ করা উচিত?

সম্পাদনা:
এইচটিটিপিএস-এর মাধ্যমে, পোস্টের তথ্য এনকোড করা থাকে, তবে কি কোনও তৃতীয় পক্ষের মাধ্যমে ইউআরএলগুলি শুকানো যেতে পারে? অতিরিক্তভাবে, আমি জেএসপি সাথে কাজ করছি; জেএসপি বা অনুরূপ কাঠামোগত ব্যবহার করার সময়, পোষ্ট বা জিইটি-তে সংবেদনশীল ডেটা পুরোপুরি রাখা এবং পরিবর্তে সংবেদনশীল তথ্য হ্যান্ডেল করার জন্য সার্ভার সাইড কোড ব্যবহার করা এড়ানো সেরা অনুশীলন বলা ভাল?


1
জেফের ব্লগ কোডিং হরর এ সম্পর্কে একটি দুর্দান্ত ব্লগ এন্ট্রি রয়েছে: ক্রস-সাইট অনুরোধ জালিয়াতি এবং আপনি
fhe

আপনি কি বেশিরভাগ জিনিসের জন্য পোষ্ট ব্যবহার করবেন না? উদাহরণস্বরূপ, একটি এআইপিআইর জন্য, কোনও ডিবি থেকে ডেটা পাওয়ার দরকার ছিল, তবে সার্ভারের ডেটা ফেরানোর আগে আপনাকে প্রথমে প্রমাণীকরণ করতে হবে? পোস্ট ব্যবহার করে আপনি অনুরোধের জন্য আপনার প্রয়োজনীয় সমস্ত পরামিতিগুলি কেবল সেশন আইডিটি পাস করবেন। আপনি যদি এর জন্য জিইটি রেক ব্যবহার করেন তবে আপনার সেশন আইডিটি সহজেই আপনার ব্রাউজারের ইতিহাসে বা মাঝখানে অন্য কোথাও পাওয়া যেতে পারে।
জেমস 111

আমি এই আলোচনাটি মনে করি যুদ্ধের আগে (99 'বা '00 বা তার বেশি) যখন https প্রচলিত ছিল না।
ডেভিড টনহোফার

@ ডেভিডটনহোফার, আপনি কোন যুদ্ধের কথা উল্লেখ করছেন? ব্রাউজার যুদ্ধ?
ডেল্টা ফ্লাইয়ার

@ দেলতাফ্লায়ার নো, স্টাফের চিরদিনের যুদ্ধ, ওরফে জিডব্লিউওটি। আমরা কি করলাম.
ডেভিড টনহোফার

উত্তর:


206

সুরক্ষার দিক থেকে এগুলি সহজাতভাবে একই। যদিও এটি সত্য যে পোস্টটি ইউআরএল এর মাধ্যমে তথ্য প্রকাশ করে না, এটি ক্লায়েন্ট এবং সার্ভারের মধ্যে প্রকৃত নেটওয়ার্ক যোগাযোগে জিইটি হিসাবে ঠিক ততটাই তথ্য প্রকাশ করে। আপনার যদি সংবেদনশীল তথ্য পাস করার দরকার হয় তবে আপনার প্রতিরক্ষা প্রথম লাইনটি সিকিউর এইচটিটিপি ব্যবহার করে এটি পাস করা হবে।

কোনও নির্দিষ্ট আইটেম বুকমার্ক করার জন্য, বা অনুসন্ধান ইঞ্জিন অপ্টিমাইজেশান এবং সূচীকরণ আইটেমগুলিতে সহায়তা করার জন্য প্রয়োজনীয় তথ্যগুলির জন্য জিইটি বা কোয়েরি স্ট্রিং পোস্টগুলি সত্যই ভাল।

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


5
জিইটির জন্য লোকেশন বারে প্রদর্শিত ইউআরএল একটি পোস্টে লুকানো থাকা ডেটা প্রকাশ করতে পারে the
tvanfosson

93
এটি কেবল সবচেয়ে নিরীহ অর্থে লুকানো রয়েছে
davetron5000

7
সত্য, তবে আপনি এটিও বলতে পারেন যে কীবোর্ডটি অনিরাপদ কারণ আপনার পাসওয়ার্ডটি টাইপ করার সময় কেউ আপনার কাঁধের উপর নজর রাখতে পারে। অস্পষ্টতার মধ্য দিয়ে সুরক্ষা এবং মোটেই সুরক্ষার মধ্যে খুব কম পার্থক্য রয়েছে।
স্টেফেনবায়ার

65
ইউআরএলে ক্যোরিস্ট্রিংয়ের দৃশ্যমানতা (এবং ক্যাশিং) এবং সুতরাং ঠিকানা বাক্সটি পরিষ্কারভাবে কম সুরক্ষিত। নিরঙ্কুশ সুরক্ষা বলে কোনও জিনিস নেই তাই সুরক্ষার ডিগ্রি প্রাসঙ্গিক।
pbreitenbach

6
এমনকি আপনি যদি কোনও পোস্ট ব্যবহার করেন তবে তা উন্মুক্ত। আপনার ক্ষেত্রে, পোস্টটি কিছুটা বেশি সুরক্ষিত হবে। তবে গুরুত্ব সহকারে .. আমি সারা দিন পোস্ট ভেরিয়েবলগুলি পরিবর্তন করতে পারি ঠিক তত সহজ ভেরিয়েবলগুলি। কুকিজ এমনকি দেখা এবং সংশোধন করা যেতে পারে .. আপনি যে সাইটটি কোনওভাবে আকার বা ফর্মে প্রেরণ করছেন সেই তথ্যের উপর কখনও নির্ভর করবেন না। আপনার যত বেশি সুরক্ষা প্রয়োজন, তত বেশি যাচাইকরণের পদ্ধতিগুলি আপনার জায়গায় থাকা উচিত।
স্টেফেনবায়ার

428

জিইটি অনুরোধটি পোষ্ট অনুরোধের তুলনায় সামান্য কম সুরক্ষিত। উভয়ই নিজের দ্বারা সত্য "সুরক্ষা" সরবরাহ করে না; পোষ্ট অনুরোধগুলি ব্যবহার করা আপনার ওয়েবসাইটকে লক্ষণীয় পরিমাণে দূষিত আক্রমণগুলির বিরুদ্ধে জাদুকরীভাবে সুরক্ষিত করবে না । তবে, জিইটি অনুরোধগুলি ব্যবহার করা অন্যথায় সুরক্ষিত অ্যাপ্লিকেশনটিকে নিরাপত্তাহীন করতে পারে।

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

মাকড়সা এবং ওয়েব ত্বরণকারী অনুসন্ধান করুন

ডেটা পরিবর্তনের জন্য আপনার পোষ্ট অনুরোধগুলি ব্যবহার করা উচিত এটিই আসল কারণ। অনুসন্ধান মাকড়সা আপনার ওয়েবসাইটের প্রতিটি লিঙ্ক অনুসরণ করবে, তবে তারা খুঁজে পাওয়া এলোমেলো ফর্মগুলি জমা দেবে না।

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

বিভ্রান্ত ডেপুটি আক্রমণ

আপনি জিইটি ব্যবহার করেন বা পোষ্টের অনুরোধ নির্বিশেষে একটি বিভ্রান্ত ডেপুটি আক্রমণ (যেখানে ডেপুটি ব্রাউজার হয়) সম্ভব হয়

আক্রমণকারী-নিয়ন্ত্রিত ওয়েবসাইটগুলিতে জিইটি এবং পোষ্টগুলি ব্যবহারকারীর মিথস্ক্রিয়া ছাড়াই জমা দেওয়া সমান সহজ

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

যে কেউ তর্ক করতে পারে যে ওয়েব এক্সিলিটারগুলি বিভ্রান্ত ডেপুটি আক্রমণের উদাহরণ, তবে এটি কেবল সংজ্ঞার বিষয়। যদি কিছু, একটি দূষিত আক্রমণকারী তাই এটি কমই একটি, এই উপর কোন নিয়ন্ত্রণ আছে আক্রমণ , ডেপুটি এমনকি যদি হয় বিভ্রান্ত।

প্রক্সি লগ

প্রক্সি সার্ভারগুলি কোয়েরি স্ট্রিংটি না ছড়িয়ে পুরোপুরি জিইটি ইউআরএল লগ করতে পারে। পোস্ট অনুরোধের পরামিতিগুলি সাধারণত লগ হয় না। কুকিজ উভয় ক্ষেত্রেই লগ ইন হওয়ার সম্ভাবনা নেই। (উদাহরণস্বরূপ)

এটি পোস্টের পক্ষে খুব দুর্বল যুক্তি। প্রথমত, আন-এনক্রিপ্ট হওয়া ট্র্যাফিক সম্পূর্ণরূপে লগ ইন করতে পারে; একটি দূষিত প্রক্সি ইতিমধ্যে এটির প্রয়োজনীয় সমস্ত কিছু রয়েছে। দ্বিতীয়ত, অনুরোধের প্যারামিটারগুলি আক্রমণকারীর সীমিত ব্যবহারের জন্য: তাদের সত্যিকারের যা দরকার তা হ'ল কুকিজ, তাই যদি তাদের কেবলমাত্র প্রক্সি লগ থাকে তবে তারা জিইটি বা পোষ্ট URL- এ আক্রমণ করতে সক্ষম হওয়ার সম্ভাবনা কম।

লগইন অনুরোধগুলির জন্য একটি ব্যতিক্রম রয়েছে: এগুলিতে ব্যবহারকারীর পাসওয়ার্ড থাকে। প্রক্সি লগে এটি সংরক্ষণ করে আক্রমণটির একটি ভেক্টর খোলে যা পোস্টের ক্ষেত্রে অনুপস্থিত। তবে, সরল এইচটিটিপি-তে লগইন করা যাই হোক না কেন সহজাতভাবেই নিরাপত্তাহীন।

প্রক্সি ক্যাশে

ক্যাশে প্রক্সিগুলি জিইটি প্রতিক্রিয়া বজায় রাখতে পারে তবে পোষ্ট প্রতিক্রিয়া নয়। এটি বলার পরে, জিইটি প্রতিক্রিয়াগুলিকে পিওএসটি হ্যান্ডলারের রূপান্তরিত করার চেয়ে কম চেষ্টা করে নন-ক্যাশেযোগ্য করা যায়।

এইচটিটিপি "রেফারার"

যদি কোনও জিইটি অনুরোধের প্রতিক্রিয়া হিসাবে পরিবেশন করা পৃষ্ঠাটি থেকে কোনও তৃতীয় পক্ষের ওয়েবসাইটে নেভিগেট করা হয়, তবে তৃতীয় পক্ষের ওয়েবসাইটটি সমস্ত জিইটি অনুরোধের পরামিতিগুলি দেখতে পাবে।

"তৃতীয় পক্ষের কাছে অনুরোধের পরামিতিগুলি প্রকাশ করে" বিভাগের সাথে সম্পর্কিত, যার তীব্রতা এই পরামিতিগুলিতে উপস্থিত রয়েছে তার উপর নির্ভর করে। পোষ্ট অনুরোধগুলি প্রাকৃতিকভাবে এ থেকে প্রতিরোধী, তবে জিইটি অনুরোধটি কাজে লাগাতে হ্যাকারকে সার্ভারের প্রতিক্রিয়াতে তাদের নিজস্ব ওয়েবসাইটের একটি লিঙ্ক toোকানো দরকার।

ব্রাউজারের ইতিহাস

এটি "প্রক্সি লগগুলি" যুক্তির সাথে খুব মিল: জিইটি অনুরোধগুলি তাদের পরামিতিগুলির সাথে ব্রাউজারের ইতিহাসেও সংরক্ষণ করা হয়। আক্রমণকারী তাদের মেশিনে শারীরিক অ্যাক্সেস থাকলে সহজেই এগুলি পেতে পারে obtain

ব্রাউজার রিফ্রেশ কর্ম

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

ব্রাউজার কোনও সতর্কতা ছাড়াই কোনও পোষ্ট অনুরোধ পুনরায় চেষ্টা করবে না।

ডেটা পরিবর্তনের জন্য কেবল পোষ্ট অনুরোধগুলি ব্যবহার করার এটি একটি ভাল কারণ, তবে এটি দূষিত আচরণ এবং এর ফলে সুরক্ষার সাথে কিছুই করার নেই।

তো এখন আমার কি করা উচিৎ?

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

এইচটিটিপিএসের মাধ্যমে, পোষ্টের ডেটা এনকোড করা থাকে, তবে ইউআরএলগুলিকে কি কোনও তৃতীয় পক্ষের দ্বারা শুকানো যেতে পারে?

না, তাদের শুকানো যাবে না। তবে ব্রাউজারের ইতিহাসে ইউআরএল সংরক্ষণ করা হবে।

পোষ্ট বা জিইটিটিতে পুরোপুরি সংবেদনশীল ডেটা স্থাপন করা এবং সংবেদনশীল তথ্য হ্যান্ডেল করার জন্য সার্ভার সাইড কোড ব্যবহার করা এড়ানো ভাল অভ্যাসটি কি বলা উচিত?

এটি কতটা সংবেদনশীল বা আরও নির্দিষ্টভাবে কীভাবে সংবেদনশীল তা নির্ভর করে। অবশ্যই ক্লায়েন্ট এটি দেখতে পাবেন। ক্লায়েন্টের কম্পিউটারে শারীরিক অ্যাক্সেস সহ যে কেউ তা দেখতে পাবে। ক্লায়েন্টটি এটি আপনার কাছে ফেরত পাঠানোর সময় এটি ছদ্মবেশী করতে পারে। যদি সেগুলি হয়ে থাকে তবে হ্যাঁ, সংবেদনশীল ডেটাটি সার্ভারে রাখুন এবং এটিকে ছেড়ে যাবেন না।


29
আহেম, সিএসআরএফ পোস্টের মাধ্যমে ঠিক সম্ভব।
এভিডি

5
@ লোটাস নোটস, এটি খুব সামান্য বেশি কঠিন, তবে আপনার কোনও ধরণের এক্সএসএসের দরকার নেই। পোস্টের অনুরোধগুলি পুরো স্থানে সর্বদা প্রেরণ করা হচ্ছে, এবং ভুলে যাবেন না যে কোনও ওয়েবসাইট থেকে সিএসআরএফ সংগ্রহ করা যেতে পারে , এক্সএসএস অন্তর্ভুক্ত নয়।
এভিডি

18
না আপনাকে টাইপ করার জন্য বিশেষাধিকার সহ অন্য কাউকে তৈরি করতে হবে না, এটি জিইটির বিপরীতে যা চুপচাপ ব্রাউজারটি পেয়ে যাবে। প্রতিটি পোষ্ট ফর্ম যাচাইযোগ্য উত্স হ্যাশ দিয়ে সুরক্ষিত করা উচিত বিবেচনা করে, এবং একটি জিইটি লিঙ্কের জন্য এর কোনও উপায় নেই, আপনার বক্তব্যটি নির্বোধ।
কিবিট্টর

7
ঠিক আছে, আপনি পোষ্ট ফর্মগুলিতে ঠিক একইভাবে আপনার সমস্ত জিইটি অনুরোধগুলিতে একটি হ্যাশ যুক্ত করতে পারেন ... তবে তথ্যের পরিবর্তনকারী কোনও কিছুর জন্য আপনার এখনও জিইটি ব্যবহার করা উচিত নয়।
এলি

13
জিইটি-র উপরে পোষ্ট ব্যবহার করা কোনও ধরণের সিএসআরএফকে বাধা দেয় না। এটি তাদেরকে করা সহজতর করে তোলে, যেহেতু আপনার নিয়ন্ত্রণাধীন কোনও ওয়েবসাইটে (জাভাস্ক্রিপ্ট থাকার পক্ষে যথেষ্ট) ওয়েবসাইটের চেয়ে মানুষ url থেকে চিত্রগুলিকে মঞ্জুরি দেয় এমন একটি র্যান্ডম ওয়েবসাইটে যেতে লোকের পক্ষে সহজতর কাজ। এরকম <body onload="document.getElementById('a').submit()"><form id="a" action="http://example.com/delete.php" action="post"><input type="hidden" name="id" value="12"></form>সত্যিই একটি লিঙ্কে ক্লিক করে কোথাও স্বয়ংক্রিয়ভাবে একটি পোস্টটি জমা দিন কঠিন নয় (রয়েছে সেটা এমন HTML)
FryGuy

175

আপনার চেয়ে বৃহত্তর সুরক্ষা সরবরাহ করা হয়নি কারণ এইচটিটিপি জিইটি-র মাধ্যমে আপনার ভেরিয়েবলের তুলনায় ভেরিয়েবলগুলি HTTP পোষ্টের মাধ্যমে প্রেরণ করা হয়।

এইচটিটিপি / ১.১ আমাদের একটি অনুরোধ প্রেরণের জন্য একগুচ্ছ পদ্ধতি সরবরাহ করে :

  • পছন্দসমূহ
  • পাওয়া
  • মস্তক
  • পোস্ট
  • PUT
  • মুছে ফেলা
  • চিহ্ন
  • সংযুক্ত

ধরুন আপনার GET ব্যবহার করে নিম্নলিখিত HTML ডকুমেন্ট রয়েছে:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

আপনার ব্রাউজারটি কি জিজ্ঞাসা করে? এটি এটি জিজ্ঞাসা করে:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

এখন ভান করা যাক আমরা সেই অনুরোধ পদ্ধতিটিকে একটি পোস্টে পরিবর্তন করেছি:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

এই HTTP অনুরোধগুলির মধ্যে দুটি হ'ল :

  • এনক্রিপ্ট করা হয়নি
  • উভয় উদাহরণ অন্তর্ভুক্ত
  • প্রচারিত হতে পারে এবং এমআইটিএম আক্রমণের বিষয় হতে পারে।
  • তৃতীয় পক্ষ এবং স্ক্রিপ্ট বটগুলি সহজেই পুনরুত্পাদন করে।

অনেক ব্রাউজার পোষ্ট / জিইটি ব্যতীত এইচটিটিপি পদ্ধতি সমর্থন করে না।

অনেক ব্রাউজারের আচরণ পৃষ্ঠার ঠিকানা সঞ্চয় করে তবে এর অর্থ এই নয় যে আপনি এই অন্যান্য সমস্যার কোনওটিকেই উপেক্ষা করতে পারবেন।

সুতরাং নির্দিষ্ট করা:

একের মধ্যে কি অন্তর্নিহিতভাবে আরও সুরক্ষিত থাকে? আমি বুঝতে পেরেছি যে পোস্টটি ইউআরএলটিতে তথ্য প্রকাশ করে না তবে এর মধ্যে কোনও আসল মূল্য আছে বা এটি কেবল অস্পষ্টতার মধ্য দিয়ে সুরক্ষা? এখানে সেরা অনুশীলন কি?

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

Https- র উপরে, POST ডেটা এনকোড করা আছে, তবে কি কোনও তৃতীয় পক্ষের মাধ্যমে ইউআরএলগুলি শুকানো যেতে পারে?

এসএসএল কীভাবে কাজ করে তা এখানে। উপরে যে দুটি অনুরোধ প্রেরণ করেছি তা মনে আছে? এসএসএলে তারা দেখতে কেমন তা এখানে দেখুন: (আমি পৃষ্ঠাটি https://encrypted.google.com/ এ পরিবর্তন করেছি যেমন উদাহরণ.কম SSL- তে সাড়া দেয় না)।

এসএসএলে পোস্ট করুন

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

এসএসএলের মাধ্যমে পান

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(দ্রষ্টব্য: আমি এইচএক্সকে এএসসিআইআইতে রূপান্তর করেছি, এর কয়েকটি অবশ্যই প্রদর্শনযোগ্য হবে না)

পুরো HTTP কথোপকথনটি এনক্রিপ্ট করা হয়েছে, যোগাযোগের একমাত্র দৃশ্যমান অংশটি টিসিপি / আইপি স্তরতে রয়েছে (যার অর্থ আইপি ঠিকানা এবং সংযোগ পোর্টের তথ্য)।

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

একমাত্র পোষ্টটি কি সুরক্ষা ব্যবস্থা? আপনার ব্রাউজারের ইতিহাসের মধ্যে alousর্ষা প্রাক্তন উল্টানো বিরুদ্ধে সুরক্ষা। এটাই. পৃথিবীর বাকি অংশগুলি আপনাকে দেখে হাসতে হাসতে আপনার অ্যাকাউন্টে লগইন হয়।

পোষ্ট কেন সুরক্ষিত নয় তা আরও প্রমাণ করার জন্য, ফেসবুক সমস্ত জায়গায় POST অনুরোধগুলি ব্যবহার করে, সুতরাং কীভাবে ফায়ারশিপের মতো সফ্টওয়্যার পারেন উপস্থিত থাকতে পারে?

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


1
আপনি সিএসআরএফ :-) সম্পর্কে কথা বলেননি এমন লজ্জা। আপনার সাথে যোগাযোগ করার কোনও উপায় আছে?
ফ্লোরিয়ান মার্জাইন

@ ফ্লোরিয়ানমারগাইন টুইটারে আমাকে যুক্ত করুন এবং আমি আপনাকে আমার ইমেলটি ডিএম করব। twitter.com/#!/BrianJGraham
ছদ্মবেশী

কে বলেছে ফেসবুক নিরাপদ? ভাল উত্তর যদিও। +1
অমল মুরালি

1
"[...] সুতরাং অস্পষ্টতার মধ্য দিয়ে এই পুরো সুরক্ষা কেবল স্ক্রিপ্ট কিডিজ এবং হিংসা বান্ধবীগুলিকেই অস্পষ্টতা সরবরাহ করে [[...]"। এটি সম্পূর্ণরূপে হিংসা জিএফ এর দক্ষতার উপর নির্ভর করে। তদতিরিক্ত, কোনও জিএফ / বিএফ আপনার ব্রাউজারের ইতিহাস দেখার অনুমতি দেওয়া উচিত নয়। কি। হাঃ হাঃ হাঃ.
তুর্কিউব

34

কোনও অতিরিক্ত সুরক্ষা নেই।

পোস্ট ডেটা ইতিহাস এবং / অথবা লগ ফাইলগুলিতে প্রদর্শিত হয় না তবে যদি ডেটা সুরক্ষিত রাখা উচিত তবে আপনার এসএসএল দরকার।
অন্যথায়, ওয়্যার স্নিগ্ধ কেউ যে কোনওভাবে আপনার ডেটা পড়তে পারে।


2
আপনি যদি এসএসএলের মাধ্যমে একটি ইউআরএল পান তবে একটি তৃতীয় পক্ষ ইউআরএল দেখতে পাবে না, তাই
সুরক্ষাটি

7
প্রাপ্ত তথ্য কেবল এসএসএল টানেলের শুরু এবং শেষে দেখা যাবে
জ্যাকো

1
লগ ফাইলগুলি গ্রাইপ করার সময় সিস্ট অ্যাডমিনরা।
টমলাক

1
আমি বলব যে পোস্টে ডেটা ব্যবহারকারীর ব্রাউজারের ইতিহাসে সংরক্ষণ করা হবে না এমন কিছু যুক্ত সুরক্ষা আছে, তবে জিইটি ডেটা হবে।
কিপ করুন

3
এসএসএল / টিএলএসের উপরে এইচটিটিপি (সঠিকভাবে প্রয়োগ করা) আক্রমণকারীকে কেবল দুটি জিনিসই দেখার সুযোগ দেয় - গন্তব্যের আইপি ঠিকানা এবং উভয় উপায়ে যাওয়ার পরিমাণের পরিমাণ the
হারুন

29

এমনকি লগইন ফর্ম বা অপেক্ষাকৃত সংবেদনশীল তথ্যের সাথে অন্য কোনও ফর্মের তুলনায় POSTসত্যিকারের সুরক্ষা সুবিধা না দিয়েও GET, আপনি এটি ব্যবহার করছেন তা নিশ্চিত করুন POST:

  1. তথ্য POSTএড ব্যবহারকারীর ইতিহাসে সংরক্ষণ করা হবে না।
  2. ফর্মটিতে প্রেরিত সংবেদনশীল তথ্য (পাসওয়ার্ড ইত্যাদি) পরে ইউআরএল বারে প্রদর্শিত হবে না (ব্যবহার করে GETএটি ইতিহাসে এবং ইউআরএল বারে দৃশ্যমান হবে)।

এছাড়াও, GETডেটা একটি তাত্ত্বিক সীমা আছে। POSTনা।

বাস্তব সংবেদনশীল তথ্যের জন্য, ব্যবহার নিশ্চিত করুন SSL( HTTPS)


ডিফল্ট সেটিংসে, আমি যখনই ফায়ারফক্স / আইআই-তে একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রবেশ করি তখন এটি আমাকে জিজ্ঞাসা করে যে আমি এই তথ্যটি সংরক্ষণ করতে চাই, বিশেষত আমাকে পরে এটি টাইপ করতে হবে না।
কিব্বি

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

হ্যাঁ, ভাল, এটি স্বয়ংক্রিয়-সম্পূর্ণ হওয়ার বিষয়টি নয়, তাই না। আমি যা বোঝাতে চেয়েছি তা আসলে ইতিহাস ছিল, স্বয়ংক্রিয়ভাবে সম্পূর্ণ নয়।
অ্যান্ড্রু মুর

আক্রমণকারী যদি সম্পূর্ণ ব্রাউজারের ইতিহাসে অ্যাক্সেস করতে পারে তবে তারও সম্পূর্ণ ব্রাউজার স্বয়ংক্রিয়-সম্পূর্ণ ডেটাতে অ্যাক্সেস রয়েছে।
মিক্কো রেন্টালাইনেন

19

ফ্যাক্স এবং ফোনগুলির মধ্যে একটিও অন্যটির চেয়ে "বেশি সুরক্ষিত" নয় ঠিক তেমনই জিইটি এবং পোষ্টগুলির মধ্যে একটিও অন্যের চেয়ে সহজাতভাবে "বেশি সুরক্ষিত" নয়। বিভিন্ন HTTP পদ্ধতি সরবরাহ করা হয়েছে যাতে আপনি যে সমস্যার সমাধান করতে চাইছেন তার জন্য সবচেয়ে বেশি প্রশংসিত একটি বেছে নিতে পারেন। পান আরো appropiate হয় idempotent প্রশ্নের যখন পোষ্ট "ACTION" প্রশ্নের জন্য আরো appropiate হয়, কিন্তু আপনি তাদের সাথে ঠিক যেমন সহজে পায়ে নিজেকে অঙ্কুর পারেন যদি আপনি আবেদন আপনি বজায় রাখার করছি জন্য নিরাপত্তা স্থাপত্য বুঝতে পারছি না।

এটা সম্ভবত সেরা যদি আপনি পড়তে হচ্ছে পদ্ধতি সংজ্ঞা: অধ্যায় 9 এর HTTP- র / 1.1 জন্য RFC কি পেতে এবং পোস্টটি মূলত গড় OT envisioned হয়েছিল একটি সামগ্রিক ধারণা পেতে।


16

জিইটি এবং পোষ্টের মধ্যে পার্থক্যটিকে সুরক্ষার দিক থেকে দেখা উচিত নয়, বরং সার্ভারের দিকে তাদের উদ্দেশ্য হিসাবে। GET এর সার্ভারে কখনই ডেটা পরিবর্তন করা উচিত নয় - লগগুলিতে অন্তত অন্য - তবে পোস্ট নতুন সংস্থান তৈরি করতে পারে।

চমৎকার প্রক্সিগুলি পোষ্টের ডেটা ক্যাশে করবে না, তবে তারা ইউআরএল থেকে জিইটি ডেটা ক্যাশে করতে পারে, তাই আপনি বলতে পারেন যে পোস্টটি আরও সুরক্ষিত থাকার কথা। তবে পোষ্ট ডেটা এখনও এমন প্রক্সিগুলির জন্য উপলব্ধ থাকবে যা দুর্দান্তভাবে খেলেন না।

অনেক উত্তরে যেমন উল্লেখ করা হয়েছে, কেবলমাত্র নিশ্চিত বাজি এসএসএলের মাধ্যমে।

তবে এটি নিশ্চিত করুন যে জিইটি পদ্ধতিগুলি কোনও পরিবর্তন করে না, যেমন ডাটাবেস সারিগুলি মোছা ইত্যাদি commit


1
আমি এটার সাথে একমত. প্রশ্নটি সুরক্ষা নয়, এটিই পোষ্ট এবং জিইটি ডিজাইনের জন্য তৈরি করা হয়েছে।
pbreitenbach

6

নির্বাচনের জন্য আমার স্বাভাবিক পদ্ধতিটি এমন কিছু:

  • যে আইটেমগুলি পুনরুদ্ধার করা হবে তা পেতে পানURL এর মাধ্যমে পরে
    • উদাহরণস্বরূপ অনুসন্ধানটি জিইটি হওয়া উচিত যাতে আপনি পরে অনুসন্ধান.এফপি? এস = XXX করতে পারেন
  • যে আইটেমগুলি প্রেরণ করা হবে তার জন্য পোস্ট করুন
    • এটি জিইটি-তে তুলনামূলকভাবে অদৃশ্য কোমাপ্রেড এবং প্রেরণে আরও শক্ত, তবে সিআরএল এর মাধ্যমে ডেটা প্রেরণ করা যায়।

তবে জিইটি-র চেয়ে পোষ্ট করা শক্ত। একটি জিইটি হ'ল ঠিকানা বাক্সে কেবল একটি URL। একটি পোষ্টের জন্য এইচটিএমএল পৃষ্ঠায় বা সিআরএলে একটি <for>> প্রয়োজন।
pbreitenbach 5

2
সুতরাং একটি নকল পোস্ট নোটপ্যাড এবং 5 মিনিটের সময় নেয় ... সত্যিই খুব বেশি শক্ত নয়। অস্তিত্বহীন এমন একটি ফোন সিস্টেমে বৈশিষ্ট্যগুলি যুক্ত করতে আমি নোটপ্যাড ব্যবহার করেছি। আমি সিস্টেমটির জন্য অ্যাডমিন ফর্মগুলির একটি অনুলিপি তৈরি করতে সক্ষম হয়েছি যা আমাকে যতক্ষণ না বিক্রেতার সাথে সম্পর্কিত, "সম্ভাব্য ছিল না" বোতামগুলিতে কমান্ডগুলি অর্পণ করতে দেয়।
ম্যাথু হোয়াইট


6

কেউই কোনও অনুরোধে যাদুকরীভাবে সুরক্ষা দেয় না, তবে জিইটি কিছু পার্শ্ব প্রতিক্রিয়া বোঝায় যা সাধারণত এটি সুরক্ষিত হতে বাধা দেয়।

ইউআরএলগুলি ব্রাউজারের ইতিহাস এবং ওয়েবসার্ভার লগগুলিতে প্রদর্শিত হবে। এই কারণে, এগুলি কখনই লগইন ফর্ম এবং ক্রেডিট কার্ড নম্বরগুলির মতো ব্যবহার করা উচিত নয়।

তবে, কেবল সেই তথ্য পোস্ট করা কোনওভাবেই এটি সুরক্ষিত করে না। তার জন্য আপনি এসএসএল চান। এইচটিটিপি ব্যবহার করার সময় জিইটি এবং পোষ্ট উভয়ই তারের মাধ্যমে প্লেইন টেক্সটে ডেটা প্রেরণ করে।

পোষ্ট ডেটাতে অন্যান্য ভাল কারণও রয়েছে - যেমন সীমাহীন পরিমাণে ডেটা জমা দেওয়ার ক্ষমতা বা নৈমিত্তিক ব্যবহারকারীদের কাছ থেকে প্যারামিটারগুলি লুকিয়ে রাখার ক্ষমতা।

ক্ষতিটি হ'ল ব্যবহারকারীরা পোষ্টের মাধ্যমে প্রেরিত কোনও প্রশ্নের ফলাফল বুকমার্ক করতে পারে না। তার জন্য আপনার জিইটি দরকার।


5

এই পরিস্থিতিটি বিবেচনা করুন: একটি opড়ু এপিআই GET অনুরোধগুলি গ্রহণ করে:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

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

দুর্ভাগ্যক্রমে, এখানে সত্যিকারের এপিআই কাজ করছে।

লগগুলিতে কিছু সংবেদনশীল তথ্য থাকা বা সেগুলি ব্রাউজারে প্রদর্শন করার ধারণাটি আমি পছন্দ করি না। পোষ্ট এবং জিইটি এক নয়। উপযুক্ত যেখানে প্রতিটি ব্যবহার করুন।


3
  1. ট্রানজিটে ডেটা সুরক্ষার হিসাবে সুরক্ষা: পোষ্ট এবং জিইটি-র মধ্যে কোনও পার্থক্য নেই।

  2. কম্পিউটারে ডেটা সুরক্ষার হিসাবে সুরক্ষা: পোস্ট নিরাপদ (কোনও ইউআরএল ইতিহাস নেই)


2

সুরক্ষার ধারণাটি অর্থহীন, যদি না আপনি এটির সংজ্ঞা দেন তবে আপনি যেটি থেকে সুরক্ষিত থাকতে চান।

আপনি যদি সঞ্চিত ব্রাউজারের ইতিহাস, কিছু প্রকারের লগিং এবং আপনার ইউআরএলগুলি দেখছেন এমন লোকদের বিরুদ্ধে সুরক্ষিত থাকতে চান তবে POST আরও সুরক্ষিত।

আপনি যদি নিজের নেটওয়ার্ক ক্রিয়াকলাপ স্নিগ্ধ করে কারও বিরুদ্ধে সুরক্ষিত থাকতে চান তবে কোনও পার্থক্য নেই।


1

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


4
আসলে এটি কোনও "কনভেনশন" নয় এটি HTTP স্ট্যান্ডার্ডের অংশ। আরএফসি বিভিন্ন পদ্ধতি থেকে কী প্রত্যাশা করবে তা খুব স্পষ্ট।
জন নিলসন

প্রকৃতপক্ষে যদি আপনি জিইটি অনুরোধগুলিকে স্থিতি সংশোধন করার অনুমতি দেন তবে এটি এমন একটি ব্রাউজার সম্ভব যা আপনি যে পৃষ্ঠাগুলিতে প্রাক-আনয়ন করছেন মনে করে যে আপনি ভিজিট করতে পারেন তা ঘটনাক্রমে এমন পদক্ষেপ নেবে যা আপনি চান না।
জেসেস্তা

1

কোনও পোস্টের অনুরোধ পরিবর্তন করা শক্ত (এটি ক্যোরির স্ট্রিং সম্পাদনা করার চেয়ে আরও বেশি প্রচেষ্টা প্রয়োজন)। সম্পাদনা: অন্য কথায়, এটি কেবল অস্পষ্টতার দ্বারা সুরক্ষা এবং সবেমাত্র এটি।


3
আমি ফায়ারফক্সের জন্য কয়েকটি অ্যাড অন ব্যবহার করে ক্যোরি স্ট্রিংয়ের অনুরোধগুলির মতোই সহজ পোস্টের অনুরোধগুলি পরিবর্তন করতে পারি। এমনকি আমি আমার হৃদয়ের সামগ্রীতে কুকি ডেটা পরিবর্তন করতে পারি।
স্টিফেনবায়ার

এটি স্ক্রিপ্ট কিডিজকে কমিয়ে দেবে না, এটি হ'ল ধরণের স্ক্রিপ্ট কিডিজ সর্বদা চেষ্টা করে। সমস্যাটি হ'ল তারা কখনও কখনও সফল হয়।
জ্যাকো

2
উহ। ফায়ারফক্সের জন্য অ্যাডন ব্যবহার করা = ক্যোরি স্ট্রিংয়ের চেয়ে বেশি প্রচেষ্টা।
চোখের পলকহীনতা

আপনার উত্তরটি লোকেদের একটি ভ্রান্ত ধারণা দেবে যে কোনও পোস্ট ব্যবহার করার সময় তারা আরও সুরক্ষিত হচ্ছে, যখন বাস্তবে তারা তা নয়। খারাপ উত্তর, খারাপ মানুষ।
ক্রিস মারাস্তি-জর্জি

আমি আমার উত্তরটির অভিপ্রায়টি আরও স্পষ্ট করতে সম্পাদনা করেছি। আশা করি এটি সাহায্য করবে।
চোখের পলকহীনতা

1

আমি অন্য সমস্ত উত্তরগুলির পুনরাবৃত্তি করতে যাচ্ছি না, তবে এর মধ্যে একটি দিক রয়েছে যা আমি এখনও উল্লেখ করে দেখিনি - এটি ডেটা অদৃশ্য হওয়ার গল্প। আমি কোথায় এটি খুঁজে পেতে জানি না, কিন্তু ...

মূলত এটি এমন একটি ওয়েব অ্যাপ্লিকেশন সম্পর্কিত যা প্রতি কয়েক রাতে অলৌকিকভাবে তার সমস্ত ডেটা আলগা করে দেয় এবং কেন এটি জানত না। লগগুলি পরিদর্শন করে পরে প্রকাশিত হয়েছিল যে গুগল বা অন্য একটি নির্বিচারে মাকড়সার দ্বারা সাইটটি সন্ধান পেয়েছিল, যে খুশিতে সাইটে এটির সমস্ত লিঙ্কগুলি খুঁজে পেয়েছিল (পড়ুন: জিওটি) - "এই প্রবেশিকাটি মুছুন" এবং "আপনি কি নিশ্চিত?" লিঙ্ক।

আসলে - এর একটি অংশ উল্লেখ করা হয়েছে। এটি "GET- তে ডেটা পরিবর্তন করবেন না কেবলমাত্র পোস্টে" এর পিছনের গল্প। ক্রোলাররা আনন্দের সাথে জিইটি অনুসরণ করবে, কখনও পোস্ট করবে না। এমনকি রোবটস.টেক্সট ক্রলরদের খারাপ ব্যবহারের বিরুদ্ধে সহায়তা করে না।


1

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


1

RFC7231:

"ইউআরআইগুলি ভাগ করে নেওয়ার উদ্দেশ্য, সুরক্ষিত নয়, এমনকি তারা সুরক্ষিত সংস্থানগুলি সনাক্ত করে U সংবেদনশীল, ব্যক্তিগতভাবে সনাক্তযোগ্য বা প্রকাশের ঝুঁকিপূর্ণ এমন একটি ইউআরআইয়ের মধ্যে থাকা তথ্য।

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

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


1

আগে যেমন কিছু লোক বলেছে, এইচটিটিপিএস সুরক্ষা নিয়ে আসে।

তবে জিইটি তুলনায় পোষ্টটি কিছুটা বেশি নিরাপদ কারণ জিইটি ইতিহাসে সংরক্ষণ করা যেতে পারে।

তবে আরও দুঃখের বিষয়, কখনও কখনও পোষ্ট বা জিইটি-র নির্বাচন বিকাশকারীদের হাতে আসে না। উদাহরণস্বরূপ একটি হাইপারলিঙ্ক সর্বদা জিইটি দ্বারা প্রেরণ করা হয় (যদি না এটি জাভাস্ক্রিপ্ট ব্যবহার করে কোনও পোস্ট ফর্মে রূপান্তরিত হয়)।


0

GET যে কারও কাছে দৃশ্যমান (এমনকি এখন আপনার কাঁধে থাকা একটি) এবং ক্যাশে সংরক্ষণ করা হয়েছে, তাই পোষ্ট ব্যবহার করা কম সুরক্ষিত, কিছু ক্রিপ্টোগ্রাফিক রুটিন ছাড়া বিটিডব্লু পোস্ট নিশ্চিত নয়, কিছুটা সুরক্ষার জন্য আপনাকে SSL ব্যবহার করতে হবে ( HTTPS)


0

পোষ্টটি সুরক্ষার জন্য আরও খারাপ হওয়ার একটি কারণ হ'ল জিইটি ডিফল্টরূপে, পরামিতিগুলি দ্বারা লগ হয় এবং সমস্ত ডেটা প্রায় সর্বজনীনভাবে আপনার ওয়েব সার্ভার দ্বারা লগ হয়।

POST এর বিপরীত , এটি প্রায় সর্বজনীনভাবে লগ হয় নি , যার ফলে আক্রমণকারীদের ক্রিয়াকলাপ স্পট করা খুব কঠিন হয়ে পড়ে।

আমি "এটি খুব বড়" যুক্তিটি কিনছি না, এটি কোনও কিছু লগ না করার কোনও কারণ নেই , কমপক্ষে 1KB, লোকদের আক্রমণাত্মকদের দুর্বল প্রবেশ-পয়েন্টে দূরে কাজ করার শনাক্ত করার জন্য এটি দীর্ঘস্থায়ী হবে, যতক্ষণ না এটি পপ হয়, তারপরে পোস্টটি করে ডাবল ডিস-পরিষেবা, যে কোনও এইচটিটিপি ভিত্তিক ব্যাক-ডোর সক্রিয় করে সীমিতভাবে সীমাহীন পরিমাণে ডেটা পাস করার জন্য।


0

পার্থক্যটি হ'ল জিইটি ডেটা খোলা এবং পোষ্ট লুকিয়ে রাখে (HTTP- শিরোনামে)।

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


0

সম্প্রতি একটি আক্রমণ প্রকাশিত হয়েছিল, যা মাঝখানে মানুষকে সংকুচিত এইচটিটিপিএস অনুরোধগুলির অনুরোধের অংশটি প্রকাশ করতে দেয়। অনুরোধ শিরোনাম এবং URL টি এইচটিটিপি দ্বারা সংকুচিত না হওয়ার কারণে, জিইটি অনুরোধগুলি এই বিশেষ আক্রমণটির বিরুদ্ধে আরও সুরক্ষিত।

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

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


0

দাবি অস্বীকার: নিম্নলিখিত পয়েন্টগুলি কেবলমাত্র ইউপিআই কলগুলির জন্য প্রযোজ্য এবং ওয়েবসাইট ইউআরএল নয়।

নেটওয়ার্কের উপর সুরক্ষা : আপনাকে অবশ্যই HTTPS ব্যবহার করতে হবে। জিইটি এবং পোষ্ট এই ক্ষেত্রে সমানভাবে নিরাপদ।

ব্রাউজারের ইতিহাস : ফ্রন্ট-এন্ড অ্যাপ্লিকেশনগুলির জন্য যেমন অ্যাংুলার জেএস, রিএ্যাক্ট জেএস ইত্যাদি এপিআই কলগুলি ফ্রন্ট-এন্ড দ্বারা করা এজেএক্স কল হয়। এগুলি ব্রাউজার ইতিহাসের অংশ হয় না। সুতরাং, পোষ্ট এবং জিইটি সমানভাবে সুরক্ষিত।

সার্ভারের সাইড লগস : ডেটা-মাস্কিংয়ের লেখার সেট এবং অ্যাক্সেস লগ ফর্ম্যাটটি ব্যবহারের মাধ্যমে অনুরোধ-ইউআরএল থেকে সমস্ত বা কেবল সংবেদনশীল ডেটা লুকানো সম্ভব।

ব্রাউজার কনসোলে ডেটা দৃশ্যমানতা: দূষিত অভিপ্রায় সহকারীর জন্য, জিইটি-র মতো পোস্টের ডেটা দেখার প্রায় একই প্রচেষ্টা।

সুতরাং, ডান লগিং অনুশীলনগুলির সাথে, GET এপিআই POST এপিআই এর মতোই সুরক্ষিত। POST সর্বত্র অনুসরণ করে, দুর্বল API সংজ্ঞা জোর করে এবং এড়ানো উচিত।


-2

এসএসএল ইনস্টল করা সহ পোস্টটি সর্বাধিক সুরক্ষিত কারণ এটি বার্তা শরীরে সংক্রমণ করে।

তবে এই সমস্ত পদ্ধতিই অনিরাপদ কারণ এটি এর নীচে এটি ব্যবহার করে bit বিট প্রোটোকল পলায়ন সহ হ্যাক-সক্ষম। এমনকি একটি স্তর 4 ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল মাধ্যমে।

সকেটগুলিও কোনও গ্যারান্টি নয় ... যদিও এটি নির্দিষ্ট উপায়ে আরও সুরক্ষিত।


-3

এটি একটি পুরানো পোস্ট, তবে আমি উত্তরগুলির কয়েকটিতে আপত্তি জানাতে চাই। যদি আপনি সংবেদনশীল ডেটা স্থানান্তর করেন তবে আপনি এসএসএল ব্যবহার করতে চাইবেন। আপনি যদি জিইটি প্যারামিটার সহ SSL ব্যবহার করেন (যেমন? ইউজারআইডিড = 123), সেই তথ্যটি সরল পাঠ্যে প্রেরণ করা হবে! আপনি যদি কোনও পোষ্ট ব্যবহার করে প্রেরণ করেন তবে মানগুলি বার্তার এনক্রিপ্ট করা মূল অংশে প্রবেশ করে এবং তাই বেশিরভাগ এমআইটিএম আক্রমণে পাঠযোগ্য হয় না।

বড় পার্থক্যটি হল যেখানে ডেটা পাস করা হয়। এটি কেবলমাত্র বোঝায় যে যদি ডেটাটি কোনও ইউআরএলতে রাখা হয় তবে এটি এনক্রিপ্ট করা যাবে না অন্যথায় আপনি সার্ভারে যেতে পারবেন না কারণ কেবলমাত্র আপনি URL টি পড়তে পারেন। এটি একটি জিইটি কাজ করে।

সংক্ষেপে, আপনি নিরাপদে এসএসএলের মাধ্যমে কোনও পোষ্টে ডেটা প্রেরণ করতে পারেন, তবে আপনি এসএসএল ব্যবহার করে বা না করে জিইটি দিয়ে এটি করতে পারবেন না।


4
এটি সম্পূর্ণ অসত্য। এসএসএল একটি পরিবহন স্তর প্রোটোকল। এটি সার্ভারের সাথে সংযুক্ত হয় FIRST, তারপরে সমস্ত অ্যাপ্লিকেশন ডেটা একটি এনক্রিপ্ট করা বাইনারি স্ট্রিম হিসাবে প্রেরণ করে। এই থ্রেডটি দেখুন: উত্তর. google.com/answers/threadview/id/758002.html
সাইমন জি

একটি টিসিপিডাম্প করুন এবং আপনি দেখতে পাবেন যে এটি 100% সত্য। সার্ভারের সাথে সংযোগ করার জন্য আপনাকে আপনার অনুরোধটি এনক্রিপ্ট না করে পাঠাতে হবে। আপনি যদি এটি জিইটি হিসাবে করেন তবে আপনার আরোগুলি প্রাথমিক অনুরোধে যুক্ত হবে এবং তাই এনক্রিপ্ট করা হয়নি are আপনি যে পোস্টে লিঙ্ক করেছেন তাতে আপনি যা দেখেন না কেন, আপনি এটি টিসিপিডাম্প (বা অনুরূপ) দিয়ে পরীক্ষা করতে পারেন।
এলভিএম

1
সম্পন্ন! সবেমাত্র আমার ম্যাকের উপর tcpdump চালিয়েছেন। এবং আপনার উত্তর এসেছে 100% মিথ্যা। আমি যে কমান্ডটি ব্যবহার করেছি তা এখানে রইল: sudo tcpdump -w ssl.data -A -i en1 -n dst Port 443 তারপর যখন আমি ssl.data এ দেখলাম অবশ্যই আমি গব্লি গ্রুক দেখেছি। সমস্ত HTTP ডেটা এনক্রিপ্ট করা হয়েছিল। এবং একটি সাধারণ নন-এসএসএল কল কাজ করেছে তা নিশ্চিত করার জন্য, আমি ব্যবহার করেছি: sudo tcpdump -w Clear.data -A -i en1 -n dst Port 80 এবং নিশ্চিতভাবেই, পরিষ্কার.ডেটাতে আমি সমস্ত শিরোনাম এবং ইউআরআই পরিষ্কার করে দেখিয়েছিলাম । আমি এটি আমার জিমেইল এবং গুগল প্লাস (যা এইচটিটিপিএস) এবং গুগল ডটকমের মতো কিছু নন এসএসএল পৃষ্ঠায় পরীক্ষা করেছি।
শিমোন জি

আমি কোনও নেটওয়ার্ক বিশেষজ্ঞ নই তাই আপনি যদি ভাবেন আমি tcpdump এ ভুল কমান্ড ব্যবহার করেছি দয়া করে আমাকে সংশোধন করতে দ্বিধা বোধ করবেন।
শিমোন জি

আমার কাছে কমান্ড অফহ্যান্ড নেই, তবে আপনি এটি ওয়্যারশার্ক / ইথেরিয়ালের সাথেও পরীক্ষা করতে পারেন।
এলভিএম

-3

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

এর সমাধান হ'ল সার্ভারের পাশে ফিল্টারগুলি (জাভা ফিল্টারগুলি ই হিসাবে) প্রয়োগ করা এবং কোনও স্ট্রিং কোয়েরি জিইটি আর্গুমেন্ট হিসাবে পাস করা হয় না তা সনাক্ত করে।


2
সত্য না! এটি POST গুলি কোড গ্রহণকারীরা জিইটিও গ্রহণ করে কিনা তা সম্পূর্ণভাবে আপনার ব্যাকএন্ডের উপর নির্ভর করে।
কলিন টি হার্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.