আমি কি ব্যবহারকারীদের উদ্দেশ্যমূলক ভুল বিবেচনা করি?


12

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

স্পষ্ট করার জন্য, আমি এই জাতীয় একটি সহজ JSON বিশ্রাম পরিষেবাটি প্রকাশ করছি:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

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

প্রমাণীকরণ SSL এর মাধ্যমে বেসিক প্রমাণীকরণের মাধ্যমে সম্পন্ন হয়।

আমি এর মতো একটি সম্ভাব্য "ক্ষতিকারক" আচরণ সম্পর্কে বলছি:

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

উপরের দৃশ্যটি অত্যন্ত অসম্ভব, এবং আমি জানি যে ব্যবসার দৃষ্টিকোণ থেকে আমার খুব বেশি চিন্তা করা উচিত নয়। তবে পরিস্থিতির উন্নতির স্বার্থে, আপনি কি ভাবেন যে JSON পোস্টের ডেটাতেও যদি ব্যবহারকারীর নাম / পাসওয়ার্ড প্রয়োজন হয়, তবে সাহায্য করবে?

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

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


3
আমার উত্তরের পাশাপাশি আমি এই বিবৃতিটিও ছেড়ে দিতে চাই, আমি মনে করি এসও বা সুরক্ষা সম্পর্কে সম্ভবত
এটির

1
আমি মনে করি আপনি আরএফসি 2616 ( সরঞ্জামস.এইটিএফ.আর.এফটিএইচটিএমএল / আরএফসি 2616# section-9.5 ) দ্বারা সংজ্ঞায়িত হিসাবে PUT এবং পোস্ট স্যুইচ করেছেন ।
সোভান্তে

উত্তর:


6

ওভার-ইঞ্জিনিয়ারিং? একেবারেই না. অ্যান্টি-এক্সএসআরএফ ব্যবস্থাগুলি কোনও সুরক্ষিত ওয়েব অ্যাপ্লিকেশন বা পরিষেবার একটি প্রয়োজনীয় অংশ। এটি "অত্যন্ত সম্ভাব্য" নাও হতে পারে যে কেউ আপনাকে আক্রমণ করতে বেছে নেবে, তবে এটি আপনার সফ্টওয়্যারটিকে কম সুরক্ষিত করে না।

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

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

আমাকে জিইটি থেকে মুক্তি দেওয়া উচিত?

না, জিইটি অনুরোধগুলি পঠন-অনুরোধগুলির জন্য ব্যবহৃত হয় যার কোনও সক্রিয় লেখার ক্রিয়া নেই (তারা "আদর্শবান")। এটি কেবল লেখার ক্রিয়াকলাপ যাতে এক্সএসআরএফ সুরক্ষা প্রয়োজন।


জিইটি অনুরোধ যদি সংবেদনশীল তথ্য প্রকাশ করতে পারে?
সানি

@ সানি: সংবেদনশীল ডেটা আপনি কী বিবেচনা করছেন?
ক্রিস

2
ক্রিস, যদি আমি ভৌতিক হয়ে যাই তবে প্রতিটি তথ্য সংবেদনশীল, যদি এটি "ভুল" ব্যবহারকারীর দ্বারা গ্রহণ করা হয় :)। এর তাত্ত্বিক।
সানি 21 ই 21 'এ

প্লিজ, আমি যুক্ত করা প্রশ্নের পরিবর্তনগুলি পর্যালোচনা করুন।
সানি

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

32

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

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


4
প্যারানাইয়ার জন্য হ্যাঁ! আপনার শত্রু আছে! (এবং প্রতিটি অনুরোধের জন্য +1 একটি আক্রমণ ))
ট্রাব

0

কোডটি যদি প্রতিষ্ঠিত ও বজায় থাকে তবে এজ কেসগুলি কেস-কেস-কেস ভিত্তিতে দেখা উচিত এবং তাদের মোকাবেলা করা উচিত।

আমার অংশে কিছু ত্রুটি ঘটানোর ডিক্স ফিক্সিং:

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

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

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


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

1
@ সানি: পোষ্ট এই বিষয়ে জিইটি হিসাবে ঠিক উন্মুক্ত exposed টেলনেট ফায়ার করুন এবং আপনি যদি বিশ্বাস না করেন তবে একটি ওয়েব সার্ভারের সাথে কথা বলুন।
টিডামার্স

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

1
@ জেরেমি: পোষ্ট অ্যাড্রেস বারে প্যারামিটারগুলি দেখায় না, তবে যেহেতু তথ্যটি সত্যিকারের এইচটিটিপি প্রবাহে ঠিক তেমন দৃশ্যমান তাই আপনি পুরোপুরি ঠিক।
টিডামার্স

7
GET অনুরোধগুলি রিসোর্সগুলি পুনরুদ্ধার করতে ব্যবহৃত হয় এবং পুট / পোষ্ট ব্যবহার করা হয় সংস্থানগুলি আপডেট / আপডেট করার জন্য যাতে কোনও আস্থাপ্রাপ্ত এপিআইয়ের ডেটা পাওয়ার জন্য PUT / POST ব্যবহার করা সম্পূর্ণ প্রত্যাশার বিরুদ্ধে থাকে।
লি

0

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

তবে একই সময়ে, আপনার সাফল্য হ্যাকের প্রভাব এবং একটি প্রচেষ্টা হওয়ার সম্ভাবনাও মূল্যায়ন করা উচিত। এই ক্ষেত্রে:

  • একটি শক্ত ফায়ারওয়াল দ্বারা সুরক্ষিত একটি অভ্যন্তরীণ পরিষেবা পাবলিক ইন্টারনেটের কোনও পরিষেবার চেয়ে আক্রমণের শিকার হওয়ার সম্ভাবনা কম।

  • গ্রাহক আলোচনার ফোরামের কারও উপর প্রভাব ফেললে গ্রাহকের ক্রেডিট কার্ড চুরি করা তার প্রভাবের চেয়ে কম হয়।


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


ধন্যবাদ। প্রশ্নটি ব্যবহারকারীকে "থেকে" রক্ষা করার বিষয়ে নয়, তারা যদি দায়িত্বজ্ঞানহীন আচরণ করে তবে ব্যবহারকারীকে নিজের সুরক্ষার বিষয়ে নয়। তবে আপনার উত্তরটি কয়েকটি ভাল পয়েন্ট দেয়।
সানি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.