অ্যাক্সেস কন্ট্রোল লেয়ারের আগে বৈধতা স্তর থাকা কি ঠিক আছে?


24

আমি একটি এপিআই স্ট্রাকচার্ড ওয়েব অ্যাপ্লিকেশন তৈরি করছি এবং এই অ্যাপ্লিকেশনটিতে আমাদের বিভিন্ন স্তর রয়েছে যা তাদের নিজস্ব কাজ করছে।

প্রথম স্তরটি হ'ল বৈধকরণ স্তর যা ব্যবহারকারীর ইনপুটকে বৈধতা দেয় এবং যদি এটি বৈধতাটি পাস করে তবে আমরা এটিকে দ্বিতীয় স্তরে নিয়ে যাই (যা অ্যাক্সেস কন্ট্রোল স্তর) অন্যথায় ত্রুটি বার্তাটি ফেরত দেয়

দ্বিতীয় স্তরটি অ্যাক্সেস কন্ট্রোল যা পরীক্ষা করে যে ব্যবহারকারীর যে কাজটি সম্পাদন করতে চায় তা সম্পাদনের অনুমতি আছে কিনা তা যাচাই করে, ব্যবহারকারীর অনুমতি থাকলে তা অনুরোধটি পরবর্তী স্তরে সরিয়ে দেয় অন্যথায় ত্রুটি বার্তা ফেরত দেয়

তৃতীয় স্তর হ'ল নিয়ন্ত্রক স্তর যেখানে আমাদের আবেদনের যুক্তি রয়েছে

আমার প্রশ্ন হ'ল অ্যাক্সেস নিয়ন্ত্রণের আগে বৈধতা স্তর থাকা ঠিক আছে? যদি ব্যবহারকারী কোনও কাজ সম্পাদনের চেষ্টা করছেন যা ব্যবহারকারীর অনুমতি নেই এবং আমরা বৈধতা ত্রুটি বার্তাটি প্রেরণ করছি? ব্যবহারকারী একটি শেষ পয়েন্টে অনুরোধগুলি প্রেরণ করবে এবং বৈধতা স্তরটির সাথে কথা বলবে এবং একবার যদি এটি বৈধতাটি পাস করে তবেই তিনি বার্তাটি দেখতে পাবেনYou can't access this!

এটি আমার কাছে অদ্ভুত লাগে তাই এটি কি ঠিক আছে বা অবকাঠামোতে আমার অন্যান্য বিকল্পগুলি কী হতে পারে?


10
এটি উল্লেখ করার মতো বিষয়ও রয়েছে যে বৈধতাগুলি প্রায়শই তাদের কাজটি করার জন্য ডাটাবেসগুলিতে পৌঁছাতে হবে বা একটি ফাইল স্টোর। আপনি যদি অ্যাক্সেস নিয়ন্ত্রণ লঙ্ঘনের জন্য যাচাই করার আগে এটি করেন তবে আপনি আক্রমণকারীদের সেই নির্দিষ্ট URL এ প্রচুর পরিমাণে ট্র্যাফিক ছুঁড়ে দিয়ে আপনার ডাটাবেস বা ফাইল সিস্টেমটি DDoS করার অনুমতি দিন।
গ্রেগ বার্গার্ড্ট

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

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

5
ব্যবহারিক দৃষ্টিকোণ থেকে, যাইহোক যাইহোক বৈধতা দেওয়ার আগে অ্যাক্সেস নিয়ন্ত্রণটি আসা উচিত - যদি কোনও ব্যবহারকারীর অনুরোধটি প্রথম স্থানে অ্যাক্সেস করতে না পারে তবে আপনি কীভাবে তার বৈধতা যাচ্ছেন?
Zibbobz 14

@ জিব্বোবজ বৈধতা যাচাই করা সহজ, ব্যবহারকারী সঠিক স্কিমা প্রেরণ করছে কিনা তা যাচাই করার মতো, যেমনটি প্যারামিটারটি পূর্ণসংখ্যার মতো হওয়া উচিত যা অন্য কোনও কিছু
মুহাম্মদ

উত্তর:


57

এটি আপনাকে কোনও কাজের জন্য অনুমতি দেয় না এমন কোনও কাজের জন্য কিছু ইনপুটটির বৈধতা জেনে রাখা কিনা এটি নির্ভর করে ak যদি এটি হয় তবে আপনার অন্যভাবে এটি করা উচিত।

অননুমোদিত ব্যবহারকারীর একমাত্র নিরাপদ প্রতিক্রিয়া হ'ল "অ্যাক্সেস অস্বীকৃত"। যদি কখনও কখনও প্রতিক্রিয়াটি "খারাপ অনুরোধ" হয় এবং অন্য সময় "অ্যাক্সেস অস্বীকার" হয় তবে আপনি অননুমোদিত ব্যবহারকারীর কাছে তথ্য প্রেরণ করছেন।

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


7
+1, একেবারে। যদি আপনার ডেটা কোনও উপায়ে ব্যক্তিগতভাবে শনাক্তযোগ্য বা সংবেদনশীল হয় তবে সুরক্ষা সম্পর্কিত প্রভাবগুলি ব্যবহারযোগ্যতার প্রভাবগুলির চেয়ে অনেক বেশি গুরুতর।
কিলিয়ান ফট

4
@ ক্যালথ আসলে এটি আপনাকে জানাতে দেয় না যদি কোনও নির্দিষ্ট নথি সিস্টেমে থাকে বা না থাকে তবে এই ধরণের তথ্য কেবলমাত্র আপনি যখন নিয়ামক স্তরে পৌঁছান তখনই দেওয়া হবে। বৈধতা কেবল স্কিমা পরীক্ষা করে, এটি ডাটাবেস অ্যাক্সেস করে না - কেবল অ্যাক্সেস নিয়ন্ত্রণ এবং গভীর স্তরগুলি ডাটাবেস অ্যাক্সেস করে। এছাড়াও, অ্যাক্সেস কন্ট্রোল লেয়ারটি কেবল আপনাকে একই জিনিস দেখায় যখন কোনও সংস্থান থাকে বা না থাকে stuff একমাত্র আপসকারী জিনিস হ'ল সেই স্কিমা যা আমি ভাবছি ঠিক আছে কি না
মুহাম্মদ মুহাম্মদ

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

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

4
@ কামিলড্রাকারি এটি চরম উদাহরণ নয়, এটি একটি সম্পূর্ণ যুক্তিসঙ্গত উদাহরণ। অন্য একটি উপায় রাখুন - আপনি অ্যাক্সেস নিয়ন্ত্রণের আগে যদি বৈধতা করেন, কোনও বিকাশকারী যে কোনও সময় যাচাইকরণের পদক্ষেপ যুক্ত করতে চান, সেই বৈধতা সংবেদনশীল কিছু প্রকাশ করে কিনা সে বিষয়ে তাদের সিদ্ধান্ত নিতে হবে। প্রতিটি দেবের সেই কলটি পাওয়ার সুযোগটি খুব ছোট বলে মনে হচ্ছে।
mfrankli

24

ঠিক আছে, বৈধতার একাধিক প্রকার রয়েছে:

  1. সস্তা বেসিক স্যানিটি-যাচাই, যা নিশ্চিত করে যে অনুরোধটি স্পষ্টতই ত্রুটিযুক্ত নয়।

    নিরর্থক বৃত্তাকার ভ্রমণের এড়াতে এটি সাধারণত কমপক্ষে আংশিকভাবে নকল ক্লায়েন্ট-সাইড।

    যাইহোক, জিনিসগুলিকে সহজ এবং কম ত্রুটি-প্রবণ করতে অ্যাক্সেস-কন্ট্রোলের আগে এটি করা উচিত, কারণ এটি কোনও তথ্য-ফাঁসের ঝুঁকি নেয় না।

  2. আরও ব্যয়বহুল বৈধতা যা এখনও কোনও সুরক্ষিত অ্যাপ্লিকেশন-ডেটার উপর নির্ভর করে না।

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

    যদি প্রথম পদক্ষেপের সমস্ত বৈধতা সদৃশ হয় তবে এটি এই ক্লায়েন্ট-সাইডের অংশগুলিও নকল করতে পারে।

  3. সুরক্ষিত অ্যাপ্লিকেশন-ডেটার উপর নির্ভর করে অতিরিক্ত বৈধতা।

    অ্যাক্সেস-নিয়ন্ত্রণের আগে এটি করা স্পষ্টতই তথ্য-ফাঁসের ঝুঁকি নিয়ে। সুতরাং, প্রথমে অ্যাক্সেস-নিয়ন্ত্রণ করুন।


3
আপনার API এ পৌঁছানোর আগেই আপনার অবকাঠামোতে নীতি প্রয়োগকারী পয়েন্টে অ্যাক্সেস নিয়ন্ত্রণ সম্পাদন করা আদর্শ হবে। বৈধতার একটি মৌলিক স্ট্যাটিক সেট (প্রাক্তন: ওপেনপিআই) প্রথমে হবে, তারপরে আরও গভীর ব্যবসায়িক বৈধতা থাকবে। এমনকি কিছু স্থির বৈধতা আপনার অ্যাপ্লিকেশন - রেডোস আক্রমণগুলির প্রাপ্যতার উপর প্রভাব ফেলতে পারে ।
felickz

@ ফেলিক্জ: হ্যাঁ, ডস আক্রমণগুলি অনুমোদনের পরে অবধি বৈধতা স্থগিত করার একটি বৈধ কারণ। এটি ভারসাম্যহীন কাজ। যাইহোক, আমি এটিকে আমলে নিতে আমার প্রথম পয়েন্টটি বিভক্ত করেছি।
হস্তান্তরকারী

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

@ লাইআরয়ান: অ্যাক্সেস-কন্ট্রোলের পূর্বে সম্ভাব্য যে সমস্ত বৈধতা কোনও কারণেই সুরক্ষিত অ্যাপ্লিকেশন ডেটার উপর নির্ভর করে না the
হস্তান্তরকারী

13

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

ওএটিওএইচ, যেমন ক্যালথ এবং গ্রেগ উল্লেখ করেছেন, অ্যাক্সেস নিয়ন্ত্রণের আগে আরও ব্যাপক বৈধতা স্থাপন করা সম্ভাব্য সুরক্ষা ঝুঁকি।

তাই কঠিন নিয়ম

  1. ব্যবহারকারীর অন্যথায় এটি সন্ধান করতে সক্ষম হবেন না বলে বৈধতার মাধ্যমে আপনাকে অবশ্যই কোনও তথ্য প্রকাশ করতে হবে না।
  2. অ্যাক্সেস কন্ট্রোলের যতটুকু অ্যাক্সেস কন্ট্রোলের এটির প্রয়োজন হয় ততক্ষণ আপনাকে অ্যাক্সেস কন্ট্রোলটি এটি ব্যবহার করতে পারার আগে আপনাকে অবশ্যই ডেটা বৈধ করতে হবে।

এই দুটি নিয়ম অনুসরণ করার অর্থ এই হতে পারে যে আপনার অ্যাক্সেস নিয়ন্ত্রণের আগে কিছুটা বৈধতা থাকতে হবে।


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

এটি ধরে নেয় উত্তরগুলি সর্বজনীন। আমি সাহস করে বলছি অনেকগুলি এপিআই এমনকি আপনাকে প্রমাণীকরণ সহ ডেটাও দেখায় না।
টমটম

6

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


2

এটি বৈধতা স্তর দ্বারা আপনি কী বোঝাতে চান তার উপর নির্ভর করে - যদি আপনি কেবল অনুরোধের বাক্য গঠনটি পরীক্ষা করে বোঝাতে চান, এটি নিরাপদ এবং আপনাকে যেভাবে কিছু করতে হবে something যদি আপনার 'বৈধতা' এমন কোনও তথ্য ব্যবহার করে যা একটি অনিবদ্ধ ব্যবহারকারীর ব্যবহারের অ্যাক্সেস না করে তবে এটি আর নিরাপদ নয়।

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

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


1

না এটা ঠিক নেই।

আপনার বৈধতা স্তরটিতে যদি আপনার বাগ থাকে তবে এটি সুরক্ষা স্তরটিকে বাইপাস করতে পারে।

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

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

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