একটি REST API / ওয়েব পরিষেবা সুরক্ষার জন্য সেরা অভ্যাসগুলি [বন্ধ]

Question

কোনও REST এপিআই বা পরিষেবা ডিজাইন করার সময় সুরক্ষা (প্রমাণীকরণ, অনুমোদন, পরিচয় ব্যবস্থাপনার) সাথে আচরণ করার জন্য কি কোনও প্রতিষ্ঠিত সেরা অনুশীলন রয়েছে?

এসওএপি এপিআই তৈরি করার সময় আপনার গাইড হিসাবে ডাব্লুএস-সিকিউরিটি থাকে এবং বিষয়টিতে প্রচুর সাহিত্যের উপস্থিতি রয়েছে। REST শেষের পয়েন্টগুলি সুরক্ষিত করার বিষয়ে আমি কম তথ্য পেয়েছি।

যদিও আমি বুঝতে পারি REST ইচ্ছাকৃতভাবে WS- * এর সাথে সাদৃশ্যযুক্ত স্পেসিফিকেশনগুলির সাদৃশ্য রাখে না আমি আশা করি যে সেরা অনুশীলন বা প্রস্তাবিত নিদর্শনগুলি উদ্ভূত হয়েছে।

প্রাসঙ্গিক নথিতে যে কোনও আলোচনা বা লিঙ্কগুলি খুব প্রশংসা হবে। যদি এটি গুরুত্বপূর্ণ হয়ে থাকে তবে আমরা আমাদের নেট নেটওয়ার্কের ফ্রেমওয়ার্কের v3.5 ব্যবহার করে তৈরি করা REST এপিআই / পরিষেবাগুলির জন্য পক্স / জেএসওএন সিরিয়ালযুক্ত বার্তা সহ ডাব্লুসিএফ ব্যবহার করব।

Comments

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

— প্রিগ্যান্টকোজোনিরো ক্যাব্রন

Answer 1

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

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

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

Comments

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

— নরম্যান এইচ

@ নরম্যানএইচ: আপনার যুক্তিটি স্পষ্টতই, কারণ আমি যদি টুইটারে পোস্ট করার জন্য কেউ যদি পুরো লেনদেনটি দেখতে পাই, তবে তারা আমার নামে ছদ্মবেশ ধারণ করতে এবং নিজের বার্তা আমার নামে পোস্ট করতে পারে।

— গ্রেগ হিউগিল

ডাইজেস্ট প্রমাণীকরণে উইকিপিডিয়া থেকে উদ্ধৃতি দিয়ে, "একটি ওয়েব সার্ভার ব্যবহারকারীর ওয়েব ব্রাউজারের সাথে শংসাপত্রগুলির জন্য আলাপচারিতা ব্যবহার করতে পারে এমন একটির মধ্যে সম্মত একটি পদ্ধতি হ'ল ডাইজেস্ট অ্যাক্সেস প্রমাণীকরণ। এটি নেটওয়ার্কের মাধ্যমে প্রেরণের আগে একটি পাসওয়ার্ডে হ্যাশ ফাংশন প্রয়োগ করে, যা হ'ল বেসিক অ্যাক্সেস প্রমাণীকরণের চেয়ে নিরাপদ, যা প্লেইন টেক্সট প্রেরণ করে। " যা আমি উপরে যা ইঙ্গিত করেছি তা সম্পাদনের একটি মানক উপায় হবে। ( বিশদগুলির জন্য en.wikedia.org/wiki/Digest_access_authentication দেখুন )

— নরম্যান এইচ

"sending plaintext passwords over the net is almost universally a bad thing"- আপনি কি "প্রায়" বিস্তারিত ব্যাখ্যা করতে পারেন? এটি কখনই খারাপ ধারণা নয়?

— টনিডিজ্বয়েডজ

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

— টনিডিজ্বয়েডজ

Answer 2

এইচটিটিপি ব্যতীত আরএসইএসটির জন্য কোনও মানদণ্ড নেই। সেখানে প্রতিষ্ঠিত আরইএসটি পরিষেবা রয়েছে। আমি আপনাকে তাদের দেখার জন্য পরামর্শ দিচ্ছি এবং তারা কীভাবে কাজ করে সে সম্পর্কে একটি অনুভূতি পান।

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

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

Comments

RESTful ওয়েব পরিষেবাদি অবশ্যই একটি দুর্দান্ত বই। এই অঞ্চলে একটি অবশ্যই পড়তে হবে। এটা নিখুঁত অনুপ্রেরণা ছিল।

— এডগারভেরোনা

এটি কীভাবে হয় যে @ahlke মন্তব্যটি বিবেচনার জন্য এতগুলি উপার্জন পেয়েছে (1) আরইএসটি স্পেসিফিকেশন এবং (2) আর্কিটেকচারাল স্টাইলগুলিতে ফিল্ডিং গবেষণামূলক এবং নেটওয়ার্ক-ভিত্তিক সফ্টওয়্যার আর্কিটেকচারের নকশায় স্পষ্টভাবে REST উল্লেখ করা হয়েছে এবং 6.3 এ এইচটিটিপি: এইচটিটিপিতে REST প্রয়োগ করা হয়েছে।

REST- এর জন্য এইচটিটিপি প্রয়োজন হয় না।

— এনটোগড

আরএসএফুল ওয়েব সার্ভিস বইটি তাদের ওয়েবসাইট থেকে বিনামূল্যে পাওয়া যায়: crummy.com/writing/RESTful-

— আইসিসি 9

আমি বইটি পড়ার পরিকল্পনা করছিলাম এবং তখন আমি বুঝতে পারি এটি মূলত এক্সএমএল ফর্ম্যাটের জন্য লক্ষ্যযুক্ত। JSON এর জনপ্রিয়তা বিবেচনা করে আমার এই বইটি ব্যবহার করা উচিত? অথবা এটি ডেটা ইন্টারচেঞ্জ ফর্ম্যাটের উপর নির্ভর করে না। গাইডেন্স দরকার।

— ভার্গব ঝাভেরি

Answer 3

এছাড়াও আপনি কটাক্ষপাত করা করতে পারেন OAuth এর টোকেন-ভিত্তিক অনুমোদন বিশেষভাবে লক্ষ্য করে HTTP API গুলির জন্য একটি উঠতি খোলা প্রোটোকল।

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

Comments

তবে মনে হয় যে 2-লেগড ওআউথ, যা আমি এখানে যা প্রয়োজন তা needাকা নেই (তথ্যের অভাব) ততটা 3-লেগডের মতো নয়।

— 04

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

— ডেভিড ব্রসার্ড

Answer 4

গিথুবে একটি দুর্দান্ত চেকলিস্ট পাওয়া গেছে :

প্রমাণীকরণ

• প্রমাণীকরণ, টোকেন জেনারেশন, পাসওয়ার্ড স্টোরেজে চাকাটি পুনরায় উদ্ভাবন করবেন না। মান ব্যবহার করুন।

• লগইনে ব্যবহার Max Retryএবং কারাগার বৈশিষ্ট্য।

• সমস্ত সংবেদনশীল ডেটাতে এনক্রিপশন ব্যবহার করুন।

জেডব্লিউটি (জেএসন ওয়েব টোকন)

• টোকেনকে খুব শক্ত করে জোর করে ব্রুট তৈরি করতে একটি এলোমেলো জটিল কী (জেডাব্লুটি সিক্রেট) ব্যবহার করুন।

• পে-লোড থেকে অ্যালগরিদম বের করবেন না। ব্যাকএন্ডে (এইচএস 256 বা আরএস 256) অ্যালগরিদমকে জোর করুন।

• টোকেনের মেয়াদোত্তীর্ণকরণ ( TTL, RTTL) যতটা সম্ভব সংক্ষিপ্ত করুন।

• JWTপে - লোডে সংবেদনশীল ডেটা সংরক্ষণ করবেন না , এটি সহজেই ডিকোড করা যায়।

OAuth এর

• redirect_uriকেবল শ্বেত তালিকাভুক্ত ইউআরএলকে অনুমতি দেওয়ার জন্য সর্বদা সার্ভার- সাইডটি বৈধ করুন ।

• সর্বদা কোডের জন্য বিনিময় করার চেষ্টা করুন এবং টোকেন নয় (অনুমতি দেবেন না response_type=token)।

• রোধ করার জন্য একটি র্যান্ডম হ্যাশ সঙ্গে রাষ্ট্র পরামিতি ব্যবহার করুন CSRFউপর OAuthপ্রমাণীকরণ প্রক্রিয়া।

• ডিফল্ট স্কোপ সংজ্ঞা দিন এবং প্রতিটি অ্যাপ্লিকেশনের জন্য স্কোপ প্যারামিটারগুলি বৈধ করুন।

প্রবেশ

• DDoS / জন্তু-আক্রমণ আক্রমণ এড়াতে অনুরোধ (থ্রোটলিং) সীমাবদ্ধ করুন।

• এমআইটিএম এড়াতে সার্ভার সাইডে এইচটিটিপিএস ব্যবহার করুন (মধ্য আক্রমণে ম্যান)

• HSTSএসএসএল স্ট্রিপ আক্রমণ এড়াতে এসএসএল সহ শিরোনাম ব্যবহার করুন ।

ইনপুট

• অপারেশন অনুযায়ী সঠিক HTTP পদ্ধতিটি ব্যবহার করুন: GET(পড়ুন), POST(তৈরি করুন), PUT/PATCH(প্রতিস্থাপন / আপডেট করুন), এবং DELETE(একটি রেকর্ড মুছতে), এবং 405 Method Not Allowedঅনুরোধকৃত পদ্ধতিটি যদি অনুরোধকৃত উত্সের জন্য উপযুক্ত না হয় তবে প্রতিক্রিয়া জানান।

• অনুরোধে যাচাই সামগ্রী-প্রকার Acceptহেডার (বিষয়বস্তু আলোচনার মাধ্যমে স্থির করা) শুধুমাত্র আপনার সমর্থিত ফর্ম্যাটে (যেমন অনুমতি application/xml, application/jsonসঙ্গে, ইত্যাদি) এবং সাড়া 406 Not Acceptableপ্রতিক্রিয়া যদি মেলে না।

• যাচাই content-typeএর (যেমন পোস্ট ডেটা আপনি গ্রহণ যেমন application/x-www-form-urlencoded, multipart/form-data, application/json, ইত্যাদি)।

• সাধারণ দুর্বলতাগুলি এড়াতে ব্যবহারকারীর ইনপুটকে বৈধ করুন (যেমন এক্সএসএস, এসকিউএল-ইনজেকশন, রিমোট কোড এক্সিকিউশন ইত্যাদি)।

• ইউআরএলে কোনও সংবেদনশীল ডেটা (শংসাপত্র, পাসওয়ার্ড, সুরক্ষা টোকেন, বা এপিআই কী) ব্যবহার করবেন না, তবে মানক Authorizationশিরোনাম ব্যবহার করুন ।

• ক্যাচিং, Rate Limitনীতিগুলি (যেমন কোটা, স্পাইক অ্যারেস্ট, সমকালীন হার সীমা) সক্ষম করার জন্য একটি এপিআই গেটওয়ে পরিষেবা ব্যবহার করুন এবং এপিআই সংস্থানগুলি গতিশীলভাবে মোতায়েন করুন।

প্রসেসিং

• ভাঙা প্রমাণীকরণ প্রক্রিয়া এড়াতে সমস্ত শেষ পয়েন্ট প্রমাণীকরণের পিছনে সুরক্ষিত আছে কিনা তা পরীক্ষা করুন।

• ব্যবহারকারীর নিজস্ব সংস্থান আইডি এড়ানো উচিত। / ব্যবহারকারীর / 654321 / আদেশের পরিবর্তে / আমি / আদেশ ব্যবহার করুন।

• স্বতঃবৃদ্ধি আইডি করবেন না। পরিবর্তে ইউআইডি ব্যবহার করুন।

• আপনি যদি এক্সএমএল ফাইলগুলি পার্সিং করে থাকেন তবে নিশ্চিত হয়ে নিন যে সেক্সি পার্সিং XXX (এক্সএমএল বহিরাগত সত্তা আক্রমণ) এড়াতে সক্ষম নয়।

• আপনি যদি এক্সএমএল ফাইলগুলি বিশ্লেষণ করে থাকেন তবে নিশ্চিত হয়ে নিন যে ঘনিষ্ঠ সত্তা সম্প্রসারণ আক্রমণের মাধ্যমে বিলিয়ন লাফ / এক্সএমএল বোমা এড়াতে সত্তা সম্প্রসারণ সক্ষম নয়।

• ফাইল আপলোডের জন্য একটি সিডিএন ব্যবহার করুন।

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

• DEBUG মোডটি বন্ধ করতে ভুলবেন না ।

আউটপুট

• X-Content-Type-Options: nosniffশিরোনাম প্রেরণ করুন ।

• X-Frame-Options: denyশিরোনাম প্রেরণ করুন ।

• Content-Security-Policy: default-src 'none'শিরোনাম প্রেরণ করুন ।

• হেডার আঙ্গুলের ছাপ সরান - X-Powered-By, Server, X-AspNet-Versionইত্যাদি

• ফোর্স content-typeআপনার প্রতিক্রিয়ার জন্য, যদি আপনি আসতে application/jsonতারপর আপনার প্রতিক্রিয়া সামগ্রী-প্রকার হয় application/json।

• শংসাপত্র, পাসওয়ার্ড, সুরক্ষা টোকেনের মতো সংবেদনশীল ডেটা ফেরত দেবেন না।

• অপারেশন সম্পন্ন অনুযায়ী যথাযথ স্থিতি কোডটি ফিরিয়ে দিন। (যেমন 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, ইত্যাদি)।

Comments

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

— জোহানোদো

আপনি ঠিক বলেছেন, এইচটিটিপিএস সহ বেসিকআউথটি সাধারণ, তবে এটি উত্তপ্তভাবে বিতর্কিত - সিকিউরিটি.স্ট্যাকেক্সেঞ্জঞ্জ / প্রশ্নগুলি / ৯৮৮/২ । আমি যাই হোক না কেন এই পয়েন্টটি মুছে ফেলব।

— Andrejs

Answer 5

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

Comments

আমরা এটি কিছু সংহতকরণের পাশাপাশি এনক্রিপ্ট করা ভিপিএন টানেলগুলি পুরানো সিস্টেমগুলিকে সমর্থন করতে ব্যবহার করি যা আমরা নিয়ন্ত্রণ করি না যা https- র মাধ্যমে যোগাযোগ করতে পারে না।

— কেসি

আপনার যখন ভার ভারসাম্যের প্রয়োজন হয় তখন ক্লায়েন্ট শংসাপত্রগুলি সমস্যা তৈরি করতে পারে ... এটি করা যেতে পারে তবে এটি সরাসরি সোজা-সামনের দিকে কম।

— জেরেমি লোগান

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

— stinkymatt

ওহ, আপনি এটি করতে পারেন .... আপনি কেবলমাত্র টিসিপি ট্র্যাফিককে লোড ব্যালান্সার ফরোয়ার্ড করতে পারেন, তবে আপনি উদাহরণস্বরূপ, লোড ব্যালান্সারকে এসএসএল-এর সমাপ্তির পয়েন্ট হতে পারবেন না।

— জেরেমি লোগান

ক্লায়েন্টের শংসাপত্র এবং এর মূল কর্তৃপক্ষ স্ব-স্বাক্ষরিত থাকলে কী এটি এখনও নিরাপদ? রুট কর্তৃপক্ষ ক্লায়েন্টের বিশ্বস্ত রুট শংসাপত্র কর্তৃপক্ষগুলিতে আমদানি করা হবে।

— জয়েস

Answer 6

এই উত্তরগুলির প্রত্যেকে সত্যিকারের অ্যাক্সেস নিয়ন্ত্রণ / অনুমোদনকে অগ্রাহ্য করেছে।

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

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

এই সূক্ষ্ম সূক্ষ্ম অনুমোদনের সংজ্ঞা এবং প্রয়োগ করতে আপনার এক্সটেনসিবল অ্যাক্সেস কন্ট্রোল মার্কআপ ল্যাঙ্গুয়েজ XXML নামে একটি অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ ভাষা ব্যবহার করতে হবে।

অন্যান্য মান এখানে নীচের জন্য:

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

এক্সএইচএমএল প্রযুক্তি-অজ্ঞাতনামা। এটি জাভা অ্যাপস,। নেট, পাইথন, রুবি ... ওয়েব পরিষেবাদি, আরএসটি এপিআই এবং আরও অনেক কিছুতে প্রয়োগ করা যেতে পারে।

নিম্নলিখিত আকর্ষণীয় সংস্থানসমূহ:

• OASIS XACML ওয়েবসাইট ML
• , NIST ABAC মান

Comments

আমি বুঝতে পারছি না কেন আপনি কেবল টোকেন সিস্টেমটি প্রয়োগ করতে পারবেন না যা ব্যবহারকারী এবং তার অনুমতিগুলি পাবে যা মূলত একই জিনিস হবে?

— স্ট্যান

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

— ডেভিড ব্রসার্ড

পার্শ্ব মন্তব্য হিসাবে, "9 থেকে 5" সুরক্ষায় কী অবদান রাখে? যেন আক্রমণকারীরা কেবল রাতে সক্রিয় থাকে? গুরুতর ব্যবহারের প্রভাবগুলির কথা বলতে হবে না, যেন চিকিত্সকরা কেবল "9 থেকে 5" কাজ করেন।

— রোল্যান্ড

স্বাস্থ্যসেবা পরিস্থিতিতে এটি একটি সাধারণ প্রয়োজন। উদাহরণস্বরূপ HL7 দেখুন 7 কোনও চিকিত্সকের বাইরে বাইরে কয়েক ঘন্টার অ্যাক্সেসের প্রয়োজন পড়ার ক্ষেত্রেও ব্রেক-দ্য গ্লাসের পরিস্থিতি রয়েছে। হ্যাকারদের হিসাবে, একবার তারা সমস্ত বেটে চলে যায়

— ডেভিড ব্রসার্ড

আমার কিছু সহকর্মী সত্যই এটি তদন্ত করছে। ধন্যবাদ @ সিম্পলজি।

— ডেভিড ব্রসার্ড

Answer 7

আমি কয়েকবার OAuth ব্যবহার করেছি এবং অন্যান্য কিছু পদ্ধতিও ব্যবহার করেছি (বেসিক / ডিজিট)। আমি আন্তরিকভাবে OAuth পরামর্শ দিচ্ছি। নীচের লিঙ্কটি আমি OAuth ব্যবহার করে দেখেছি সেরা টিউটোরিয়াল:

http://hueniverse.com/oauth/guide/

Comments

যদিও এটি OAuth 1.0 সম্পর্কিত একটি খুব পুরানো উত্তর, এটি লক্ষণীয় যে আপনি যে লিঙ্কটি উদ্ধৃত করেছেন তার লেখক ওআউথ 2.0 সম্পর্কে এই কথাটি বলেছিলেন : "আমি এই সিদ্ধান্তে পৌঁছেছি যে OAuth 2.0 একটি খারাপ প্রোটোকল ... ওআউথের সাথে তুলনা করা হলে 1.0, 2.0 স্পেসিফিকেশনটি আরও জটিল, কম ইন্টারঅ্যাপেবল, কম দরকারী, আরও অসম্পূর্ণ এবং সবচেয়ে গুরুত্বপূর্ণভাবে, কম সুরক্ষিত "" । স্পষ্টতই, আমি যে মন্তব্যটি উদ্ধৃত করছি তা আপনার উত্তর পোস্ট করার কয়েক বছর পরে করা হয়েছিল।

— স্কোমিসা

Answer 8

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

Comments

লিঙ্কটির জন্য ধন্যবাদ (1 রেইনড্রপ) - এটি সুর সম্পর্কিত খুব আকর্ষণীয় আলোচনা যেমন এটি এসওএপি বনাম রিস্টের সাথে সম্পর্কিত

— নাথান

Answer 9

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

Comments

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

— গিলি

হুম ... নিশ্চিত যে আপনি ঠিক সে সম্পর্কে ঠিক বলেছেন। আমি বিশ্বাস করি যে কয়েকটি ধরণের শিরোনামগুলি কী ধরণের এনক্রিপশন প্রয়োজন তা বোঝার জন্য ব্যতীত অন্য সমস্ত শিরোনাম এনক্রিপ্ট করা আছে।

— নাথান

এটা ভুল। HTTPS সমস্ত কিছু রক্ষা করে। এটি যায়: টিসিপি হ্যান্ডশেক ... টিএলএস হ্যান্ডশেক ... <ENCRYPTED> GET / foo 200 ঠিক আছে ... টিয়ারডাউন </ translation>

— মার্ক রেনুফ

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

— ব্রুস অলডারসন

— ওয়েব্যাক মেশিনটি

Answer 10

OWASP (ওপেন ওয়েব অ্যাপ্লিকেশন সুরক্ষা প্রকল্প) এর ওয়েব অ্যাপ্লিকেশন বিকাশের সমস্ত দিক সম্পর্কে কিছু চিট শীট রয়েছে। এই প্রকল্পটি তথ্যের একটি অত্যন্ত মূল্যবান এবং নির্ভরযোগ্য উত্স। আরআরএসটি পরিষেবাদি সম্পর্কিত আপনি এটি পরীক্ষা করতে পারেন: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Answer 11

আমি OAuth 2/3 সুপারিশ করব। আপনি http://oauth.net/2/ এ আরও তথ্য পেতে পারেন

Comments

বিশদভাবে যত্ন নেওয়ার জন্য কেন আপনি 2 সংস্করণ সুপারিশ করবেন যখন এটি বেশিরভাগ ক্ষেত্রে অসম্পূর্ণ থেকে যায়? আইএমএইচও, সংস্করণ 1.0a বেশিরভাগ অ্যাপ্লিকেশনগুলির একটি কঠিন সমাধান হিসাবে রয়ে গেছে।

— বুতিফাররা

Answer 12

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

Answer 13

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

.NET পরিবেশ হিসাবে আমি খুব বেশি সাহায্য করব না, তবে "জাভা দিয়ে ওয়েব পরিষেবা তৈরি করা" (10 ডলার লেখকযুক্ত একটি ইট) ডাব্লুএস- * সুরক্ষা আর্কিটেকচার এবং বিশেষত এর কিরকগুলি বোঝার ক্ষেত্রে আমাকে অনেক সাহায্য করেছিল।

Answer 14

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

Answer 15

আমি যুক্ত করতে চাই (স্টিনকিমেটের সাথে সামঞ্জস্য রেখে), সবচেয়ে সহজ সমাধান হ'ল আপনার সাইটে এসএসএল শংসাপত্র যুক্ত করা। অন্য কথায়, নিশ্চিত হয়ে নিন যে আপনার ইউআরএল এইচটিটিপিএস: //। এটি আপনার পরিবহণের সুরক্ষা (বকরের ধাক্কা) .েকে দেবে। রিস্টফুল ইউআরএলগুলির সাথে , ধারণাটি এটিকে সহজ রাখা (ডাব্লুএস * সুরক্ষা / এসএএমএল থেকে আলাদা), আপনি oAuth2 / ওপেনআইডি সংযোগ বা এমনকি বেসিক আথ (সাধারণ ক্ষেত্রে) ব্যবহার করতে পারেন । তবে আপনার এখনও এসএসএল / এইচটিটিপিএস লাগবে। দয়া করে এখানে এএসপি.নেট ওয়েব এপিআই 2 সুরক্ষা পরীক্ষা করুন: http://www.asp.net/web-api/overview/ সুরক্ষা (নিবন্ধ এবং ভিডিও)

Answer 16

@ নাথন শেষ হওয়ার সাথে সাথে এটি একটি সাধারণ এইচটিটিপি শিরোনাম, এবং কেউ কেউ OAuth2 এবং ক্লায়েন্টের পক্ষে এসএসএল শংসাপত্র বলেছিল। এর সূচনাটি হ'ল ... আপনার REST এপিআই-তে সুরক্ষা হ্যান্ডেল করা উচিত নয় কারণ এটি সত্যই এপিআইয়ের আওতার বাইরে হওয়া উচিত।

পরিবর্তে এটির উপরে একটি সুরক্ষা স্তর স্থাপন করা উচিত, এটি কোনও ওয়েব প্রক্সি (সাইটমিন্ডার, জেরমেট বা এমনকি অ্যাপাচি এইচটিপিটি এর মতো একটি সাধারণ পদ্ধতি) এর পিছনে এইচটিটিপি শিরোনাম, বা OAuth 2 এর মতো জটিল whether

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

ডাব্লুসিএফ বিশ্বে, আমি ServiceSecurityContext.Currentবর্তমান সুরক্ষা প্রসঙ্গটি পেতে ব্যবহার করব । প্রমাণীকরণের জন্য আপনাকে নিজের অ্যাপ্লিকেশনটি কনফিগার করতে হবে।

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

Answer 17

ওয়েব অ্যাপ্লিকেশন সুরক্ষার জন্য, আপনার ওডাব্লুএএসপি ( https://www.owasp.org/index.php/Main_Page ) এ নজর দেওয়া উচিত যা বিভিন্ন সুরক্ষার আক্রমণে চিটশিট সরবরাহ করে। আপনার অ্যাপ্লিকেশনটি সুরক্ষিত করার জন্য আপনি যথাসময়ে ব্যবস্থা গ্রহণ করতে পারেন। এপিআই সুরক্ষার সাথে সম্মতি (অনুমোদন, প্রমাণীকরণ, পরিচয় পরিচালনা), ইতিমধ্যে উল্লিখিত হিসাবে একাধিক উপায় রয়েছে (বেসিক, ডাইজেস্ট এবং ওআউথ)। OAuth1.0 এ লুপ গর্ত রয়েছে, সুতরাং আপনি OAuth1.0a ব্যবহার করতে পারেন (নির্দিষ্টকরণের সাথে উদ্বেগের কারণে OAuth2.0 ব্যাপকভাবে গ্রহণ করা হয় না)

Answer 18

এটি একটি সময় হয়েছে কিন্তু প্রশ্ন এখনও প্রাসঙ্গিক, যদিও উত্তর কিছুটা পরিবর্তন হতে পারে।

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

এক্সপ্রেস- গেটওয়ে.আইও আরও সাম্প্রতিক এবং এটি একটি এপিআই গেটওয়ে।