নিরাপদে কোনও ক্লায়েন্ট-সাইড ওয়েব অ্যাপ্লিকেশনটিতে গোপন তথ্য সংরক্ষণ করা


11

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

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

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

সম্পূর্ণরূপে ক্লায়েন্ট পক্ষ চলমান এমন কোনও অ্যাপ্লিকেশন পাওয়ার কোনও উপায় কী সার্ভারের পাশের মাঝারি স্তর ছাড়াই কোনও গোপন তথ্য নিরাপদে সংরক্ষণ করতে সক্ষম হবে?



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

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

উত্তর:


9

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

আপনি জিনিসগুলি আড়াল করতে পারেন এবং স্টাফগুলিতে উঠতে অসুবিধা তৈরি করতে পারেন, তবে শেষ পর্যন্ত তারা যদি যথেষ্ট চেষ্টা করেন তবে তারা তা খুঁজে পেতে পারেন।


4
^ করেছেন। গোপন তথ্যটি কীভাবে "গোপন" হয় এবং সময় এবং অর্থ এটি কতটা মূল্যবান তা রক্ষা করে? "শিল্প মান" প্রচেষ্টা যথেষ্ট হতে পারে।
ডেভই

+1 দুর্দান্ত উত্তর। একটি জাভাস্ক্রিপ্ট ডিবাগারের সাহায্যে, আমি আপনার অ্যাপ্লিকেশনটি পরিবর্তন করতে পারি, মধ্যবর্তী মানগুলি ইত্যাদি দেখতে পারি I
রস প্যাটারসন

2

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


0

একটি বিকল্প হ'ল REST এপিআইর জন্য কোনও ব্যবহারকারী লগইনের উপর ভিত্তি করে অ্যাক্সেস মঞ্জুর করা বা না; এটি একটি সেশন-ভিত্তিক টোকেন (গাইড, হ্যাশ স্ট্রিং, আপনার যা পছন্দ হোক) ফেরত দিতে পারে যা অ্যাক্সেসের প্রমাণীকরণের জন্য অন্য REST API কলগুলিতে যেতে পারে

আপনি যদি ক্লায়েন্ট মেশিনে ব্যবহারকারীর লগইন তথ্য সংরক্ষণ করার বিষয়ে উদ্বিগ্ন হন তবে তা করবেন না তবে ব্যবহারকারীকে প্রতিবার অ্যাকাউন্ট এবং পাসওয়ার্ডের তথ্য প্রবেশ করতে হবে

ওআউথ এট আল এর সাথে তেমন পরিচিত নয়, তবে প্রমাণীকরণের তথ্য অবিরামভাবে সঞ্চয় করার জন্য আমি উপরের কোনও বাধ্যতামূলক কারণ দেখতে পাচ্ছি না ...


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