টোকেন প্যারামিটার সহ https ইউআরএল: এটি কতটা নিরাপদ?


91

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

আমরা তাদের লিঙ্ক সহ একটি ইমেল প্রেরণের কথা ভেবেছি, সেখান থেকে তারা তাদের ফলাফলগুলি ফিরে পেতে পারে। তবে, স্বাভাবিকভাবেই, আমাদের এই URL টি সুরক্ষিত করতে হবে, কারণ ব্যক্তিগত ডেটা ঝুঁকির মধ্যে রয়েছে।

সুতরাং আমরা URL- এ একটি টোকন (চিঠি এবং অঙ্কের 40 টি অক্ষরের সংমিশ্রণ, বা একটি MD5 হ্যাশ) পাস করার এবং এসএসএল ব্যবহার করার ইচ্ছা করছি।

অবশেষে, তারা এর মতো একটি ইমেল পাবেন:

হাই,
আপনার ফলাফলগুলি https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn এ ফিরে আসুন

আপনি এটি সম্পর্কে কি মনে করেন? এটি কি যথেষ্ট নিরাপদ? টোকেন প্রজন্মের জন্য আপনি আমাকে কী পরামর্শ করবেন? একটি https অনুরোধে ইউআরএল প্যারামিটারগুলি পাস করার বিষয়ে কী?


উত্তর:


101

এসএসএল ট্রানজিটে ক্যোয়ারী প্যারামিটারগুলি সুরক্ষিত করবে; তবে ইমেল নিজেই নিরাপদ নয় এবং ইমেলটি তার গন্তব্যে পৌঁছানোর আগে যে কোনও সংখ্যক সার্ভারের সাথে বাউন্স করতে পারে।

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

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

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

আমার মতে এটি একটি খারাপ ধারণা।


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

6
এইচটিটিপিএস থেকে এইচটিটিপিতে যাওয়ার সময় বেশিরভাগ ব্রাউজারগুলি রেফারারটি সরিয়ে দেয় না?
কেভিন মার্ক

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

4
তাহলে সমাধান কি?
আরটি

4
যদি ইউআরএল-তে টোকেনটি এপিআই অনুরোধের জন্য ব্যবহৃত টোকেনের মতো না হয় এবং এটি কেবল এক ঘন্টা স্থায়ী হয়, তবে ক্ষতি কী হবে?
ব্যবহারকারী1709076

14

আমি তার জন্য একটি কুকি ব্যবহার করব। কর্মপ্রবাহটি এই জাতীয় হওয়া উচিত:

  1. ব্যবহারকারী প্রথমবারের জন্য আপনার সাইটে আসে।
  2. সাইট একটি কুকি সেট করে
  3. ব্যবহারকারী ডেটা প্রবেশ করে। কুকিতে সঞ্চিত কিছু কী ব্যবহার করে ডেবিটি ডিবিতে সংরক্ষণ করা হয়।
  4. ব্যবহারকারী চলে গেলে আপনি তাদের https: লিঙ্ক সহ একটি ইমেল প্রেরণ করেন
  5. ব্যবহারকারী ফিরে এলে সাইটটি কুকি আবিষ্কার করে এবং ব্যবহারকারীকে পুরানো ডেটা সহ উপস্থাপন করতে পারে।

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


4

এসএসএল ট্রানজিটে ডেটার সামগ্রীগুলি সুরক্ষিত করে তবে আমি ইউআরএল সম্পর্কে নিশ্চিত নই।

নির্বিশেষে, আক্রমণকারীকে ইউআরএল টোকেনটি পুনরায় ব্যবহার করে প্রশমিত করার এক উপায় হ'ল প্রতিটি টোকেন কেবল একবার ব্যবহার করা যেতে পারে তা নিশ্চিত করা। আপনি এমনকি একটি কুকি সেট করতে পারেন যাতে বৈধ ব্যবহারকারীর লিঙ্কটি ব্যবহার করা চালিয়ে যেতে পারে তবে প্রথম অ্যাক্সেসের পরে এটি কেবল কুকিযুক্ত ব্যক্তির পক্ষে কাজ করবে।

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


11
ইউএসএল সংক্রমণের আগে এসএসএল সংযোগটি সুরক্ষিত।
ডেভিড

1

ই-মেইল সহজাতভাবে নিরাপত্তাহীন। যদি কেউ সেই লিঙ্কটিতে ক্লিক করতে পারেন এবং ডেটা পেতে পারেন, আপনি সত্যিই এটি রক্ষা করছেন না।


সঠিক তবে অনেকগুলি সাইট এটি নিয়ে মাথা ঘামায় না এবং লগইন / পাসওয়ার্ডগুলি মেলের মাধ্যমে প্রেরণ করে। তবে
এগুলি

আমি তাদের অনুকরণ করার কোনও কারণ মানি না তবে তারা আপনাকে প্রথমবার লগইন করার পরে পাসওয়ার্ড পরিবর্তন করতে বলে।
জেসন পুনিউন

1

ওয়েল টোকেন এসএসএল মাধ্যমে পাস করার সময় সুরক্ষিত। আপনি যে সমস্যার মুখোমুখি হচ্ছেন তা হ'ল এটি ইউআরএলটি দেখতে সক্ষম হয়ে লোকেদের জন্য (এটি যাদের উদ্দেশ্যে নয়) তাদের পক্ষে উপলভ্য।

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


4
আপনি ঠিক বলেছেন: ইউআরএল ব্রাউজারের ইতিহাসে থাকবে উদাহরণস্বরূপ
ফ্ল্যাকউ

0

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

কোনও ঘটনাক্রমে https অনুরোধে প্যারামিটারগুলির সাথে কোনও সমস্যা নেই।


বর্বর বাহিনীর আক্রমণগুলির ঝুঁকি সম্পর্কে আপনি ঠিক বলেছেন। আমি দেখতে পাচ্ছি না কীভাবে আমরা এই ধরণের আক্রমণ থেকে বটকে আটকাতে পারি। নিষেধাজ্ঞার "জোর দিয়ে" আইপিগুলি পর্যাপ্ত সুরক্ষা হবে না। আপনি কি বিষয় সম্পর্কে ধারণা আছে?
ফ্লাকৌ

প্রকৃতপক্ষে, আমরা কী কী স্পেসের সাথে কথা বলছি তার সাথে একটি রাখি (যদি এই_আইপি_সংখ্যার_সংশ্লিষ্ট_আন_ইনওয়েড_ টোকেন_টডে ()) ঘুম (5); আপনার লোড_সিমুলেশন স্ক্রিপ্টে পুরোপুরি যথেষ্ট সুরক্ষা হবে। (হার সীমাবদ্ধতা ভাল প্রমাণীকরণ ব্যবস্থার সেই বৈশিষ্ট্যগুলির মধ্যে একটি))
বিশৃঙ্খলা

আপনার উত্তরের জন্য ধন্যবাদ. তবে আমি ভেবেছিলাম যে একই বট সহজেই বিভিন্ন আইপি নিতে পারে যা আইপি রেট সীমাটি পর্যাপ্ত নয়। আমি কি ভূল?
ফ্লাকৌ

এগুলি যেগুলি পায় তা হ'ল আইপি প্রতি একটি অনির্দিষ্ট প্রচেষ্টা। আইপি অ্যাড্রেস স্পেস এত সহজে উপলভ্য নয় যে এটি সহায়ক।
বিশৃঙ্খলা

0

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

তথ্যটি অ্যাক্সেস করার জন্য সেরা হবে একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রমাণীকরণ।

আমি কুকি ধারণাটি কম বেশি পছন্দ করি। আপনার পাশাপাশি কুকির তথ্য এনক্রিপ্ট করা উচিত। আক্রমণের সম্ভাবনা সীমাবদ্ধ করার জন্য আপনার লবণ এবং কী বাক্যাংশের সাথে $ _SERVER ['HTTP_USER_AGENT'] সহ টোকেনও তৈরি করা উচিত। যাচাইকরণের ব্যবহারের জন্য কুকিতে ক্লায়েন্ট সম্পর্কে যতটা সংবেদনশীল তথ্য সংরক্ষণ করুন।

মূল বাক্যাংশটি সহজে ব্যবহারের জন্য কুকিতে সংরক্ষণ করা যেতে পারে তবে মনে রাখবেন যে কুকিও চুরি হয়ে যেতে পারে = ()।

ক্লায়েন্টকে তার দেওয়া মূল বাক্যাংশটি টাইপ করা যাক, যা তার ডেটা সহ ডেটাবেসেও সঞ্চিত থাকে।

অথবা, যদি ব্যক্তি কোনও আলাদা মেশিন ব্যবহার করে যা $ _SERVER ['HTTP_USER_AGENT'] পরামিতিতে আলাদা হয় বা কেবল কুকিটি মিস করে তবে কী ব্যবহার করা যেতে পারে। সুতরাং কুকি স্থানান্তরিত বা সেট করা যেতে পারে।

সংবেদনশীল ডেটা ডাটাবেসে এনক্রিপ্ট করা হয়েছে তাও নিশ্চিত করুন। আপনি কখনো জানেন না ;)


-1

আপনি সচেতন যে কোনও হ্যাকার যদি আপনার ডাটাবেসে অ্যাক্সেস পান তবে অনেকগুলি ব্যক্তিগত তথ্য নিখরচায় দেওয়া যেতে পারে?

তার পরে আমি বলব যে এটি ধারণা হিসাবে খারাপ নয়। আমি MD5 বা SHA1 ব্যবহার করব না কারণ তারা হ্যাশিংয়ের জন্য খুব নিরাপদ নয়। এগুলি "ডিক্রিপ্ট করা" হতে পারে (আমি জানি এটি এনক্রিপশন নয়)।

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

নোট করুন যে এইচটিটিপিএস আপনার সাইট থেকে শেষ ব্যবহারকারীর কাছে প্রেরিত ডেটা সুরক্ষিত এবং ক্রিপ্ট করবে। আর কিছুই নয়, এটিকে সুরক্ষিত সুর হিসাবে গ্রহণ করুন। এর চেয়ে কম কিছুই নয়।


শব্দের কোনও অর্থে একটি সল্টেড এসএএ 1 হ্যাশটি কীভাবে ডিক্রিপ্ট হয়?
এলি

"আপনি জানেন যে কোনও হ্যাকার যদি আপনার ডাটাবেসে অ্যাক্সেস পান তবে প্রচুর ব্যক্তিগত তথ্য নিখরচায় দেওয়া যেতে পারে?" হ্যাঁ, তবে এটি কি সমস্ত ওয়েবসাইটের জন্য সমস্যা নয় ??
ফ্লাকৌ

@ ফ্ল্যাকউ হ্যাঁ তবে আপনি যদি পেপালের ডিবিতে অ্যাক্সেস অর্জন করেন তবে আপনি পরিষ্কারভাবে সংরক্ষিত ক্রেডিট কার্ডের তথ্য পাবেন না যা সবকিছু এনক্রিপ্ট করা আছে। @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
এরিক

-1

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

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


4
এসএসএন? আপনি গুরুতর? যাইহোক, আমি আপনাকে পরামর্শ দিচ্ছি যে সেখানে 40 টি চরিত্রের এলোমেলো স্ট্রিং রয়েছে তার উপর আপনি গণিত করুন। এটি কেবল "অত্যন্ত অসম্ভব" এর চেয়ে বেশি
এলি

আপনি ঠিক বলেছেন, আমাদের সম্ভবত ইমেলের মতো url এ অন্য একটি প্যারামিটার যুক্ত করা উচিত (এমনকি যদি a..z + A..Z + 0..9 = 62 টি অক্ষর, এবং 62 ^ 40 বেশ বড় সংখ্যা)।
ফ্লাকৌ

বলছি, 62 ^ 40 মহাবিশ্বে পরমাণুর সংখ্যার চেয়ে যথেষ্ট বেশি more এটি আক্ষরিক অর্থে অবর্ণনীয়।
এলি

4
আমি অবাক হয়েছি কত লোক এই সংখ্যার স্কেল বুঝতে পারে না। আপনি যদি এক মিলিয়ন টোকেনের সেকেন্ডটি অনুমান করেন, তবে আঘাত হানার আগে সূর্যটি জ্বলে উঠবে
এলি

4
রিচার্ড, মনে হচ্ছে আপনি বার্থডে প্যারাডক্স বলে যা চিহ্নিত করছেন ... এটি কেবল সম্ভাব্য সংমিশ্রণের সংখ্যা নয়, তবে এর মধ্যে কতগুলি ব্যবহৃত হয়। ভাল, এই ক্ষেত্রে, সুযোগটি উল্লেখযোগ্য হওয়ার আগে আপনাকে 62 you 40 সংমিশ্রণের প্রায় 2 ^ 119 ব্যবহার করতে হবে।
এরিকসন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.