ডাটাবেস আইডি প্রকাশ করা - সুরক্ষা ঝুঁকি?

Question

আমি শুনেছি ডাটাবেস আইডি প্রকাশ করা (উদাহরণস্বরূপ ইউআরএলগুলিতে) সুরক্ষা ঝুঁকি, তবে কেন তা বুঝতে আমার সমস্যা হচ্ছে।

এটি কেন ঝুঁকিপূর্ণ, বা কেন তা নয় সে সম্পর্কে কোনও মতামত বা লিঙ্কগুলি?

সম্পাদনা: অবশ্যই অ্যাক্সেসটি স্কোপড রয়েছে, উদাহরণস্বরূপ যদি আপনি উত্স দেখতে না পান তবে আপনি foo?id=123একটি ত্রুটি পৃষ্ঠা পেয়ে যাবেন। অন্যথায় URL টি নিজেই গোপনীয় হওয়া উচিত।

সম্পাদনা: যদি URL টি গোপন থাকে তবে এতে সম্ভবত একটি উত্পন্ন টোকেন থাকবে যার আয়ু সীমিত থাকবে, যেমন 1 ঘন্টা বৈধ এবং কেবল একবার ব্যবহার করা যেতে পারে।

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

Answer 1

যথাযথ শর্তাদি দেওয়া, শনাক্তকারীদের প্রকাশ করা কোনও সুরক্ষা ঝুঁকি নয়। এবং, বাস্তবে, সনাক্তকারী সনাক্ত না করেই কোনও ওয়েব অ্যাপ্লিকেশন ডিজাইন করা অত্যন্ত ভারী হবে।

এখানে কিছু ভাল নিয়ম অনুসরণ করতে হবে:

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

Comments

আইএমও, অপ্রত্যাশিত আইডি যুক্ত করা একটি "অস্পষ্টতার মাধ্যমে সুরক্ষা" পদ্ধতির এবং এটি সুরক্ষার একটি মিথ্যা ধারণা তৈরি করতে পারে। (1) এবং (2) এ দৃষ্টি নিবদ্ধ করা এবং আপনার অ্যাক্সেস নিয়ন্ত্রণ শক্ত কিনা তা নিশ্চিত করা ভাল।

— স্টক্যাম্পবেল

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

— ইরিকসন

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

— ব্যবহারকারী 247702

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

— ওয়েইন ব্লস

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

— চকোমোনকি

Answer 2

যদিও কোনও ডেটা সুরক্ষা ঝুঁকি নয় এটি একেবারে একটি ব্যবসায়িক বুদ্ধিমত্তার সুরক্ষা ঝুঁকি কারণ এটি ডেটার আকার এবং গতি উভয়ই প্রকাশ করে। আমি দেখেছি ব্যবসাগুলি এতে ক্ষতিগ্রস্থ হয় এবং গভীরভাবে এই অ্যান্টি-প্যাটার্ন সম্পর্কে লিখেছি। আপনি যদি কেবল একটি পরীক্ষা তৈরি না করেন এবং ব্যবসা না করেন তবে আমি আপনার ব্যক্তিগত আইডিকে জনগণের চোখের সামনে রাখার পরামর্শ দেব। https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Comments

পরিশেষে, বুদ্ধিমান উত্তর সুরক্ষা ঝুঁকি ছাড়া অন্য দিক আনছে।

— পিক্সেস করুন

এটি গ্রহণযোগ্য উত্তর হওয়া উচিত। যদি আপনি ধরে নেন যে আক্রমণকারী আপনার সুরক্ষাটিকে বাইপাস করতে পারে (যা আপনার সর্বদা করা উচিত), আপনি কেবল এই ধরণের তথ্য হস্তান্তর করতে চান না।

— ক্রিল

@ ক্রিল তাদের আপনার সুরক্ষা বাইপাস করার প্রয়োজন নেই। তাদের কেবল একটি অ্যাকাউন্ট তৈরি করা দরকার!

— পিটার

Answer 3

এটি আইডি কীসের জন্য দাঁড়ায় তার উপর নির্ভর করে।

এমন একটি সাইট বিবেচনা করুন যা প্রতিযোগিতামূলক কারণে তারা কতজন সদস্য পাবলিক করতে চান না তবে অনুক্রমিক আইডি ব্যবহার করে এটি ইউআরএলে যাইহোক প্রকাশ করে: http://some.domain.name/user?id=3933

অন্যদিকে, যদি তারা পরিবর্তে ব্যবহারকারীর লগইন নাম ব্যবহার করে: http://some.domain.name/user?id=some তারা ইতিমধ্যে কিছু জানেন না যা ব্যবহারকারী ইতিমধ্যে জানেনি।

Comments

আপনি অনুক্রমিক ID- র তুমি ডান ব্যবহার করছেন, কিন্তু যদি তাহলে কিছু এক্সপোজ এই নয় যে

— orip

@ ইউরিপ: যেমনটি আমি বলেছিলাম, এটি বিভিন্ন আইডির পরীক্ষা করে কেউ কী আবিষ্কার করতে পারে তার উপর নির্ভর করে। একটি প্যাটার্ন আছে? তারা কি সেই তথ্যটি তথ্য অর্জন করতে ব্যবহার করতে পারে যা তাদের উদ্দেশ্য নয়?

— কিছু

@ জন: সম্পাদনা করার জন্য ধন্যবাদ। ইংরাজী আমার মাতৃভাষা নয় :)

— কিছু

আমি ঠিক এটি করেছি: প্রতিযোগীর ব্যবহারকারীর ব্যবহারকারীর আকার নির্ধারণের জন্য ক্রমিক আইডি নম্বর ব্যবহার করেছি।

— মিকাহ

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

— কিছু

Answer 4

সাধারণ চিন্তা এই রেখাগুলি বজায় রাখে: "আপনার অ্যাপ্লিকেশনটির অভ্যন্তরীণ কাজ সম্পর্কে কারও কাছে অল্প তথ্য হিসাবে প্রকাশ করুন" "

ডাটাবেস আইডি এক্সপোজ করা কিছু তথ্য প্রকাশ হিসাবে গণনা করে।

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

Comments

সংস্থাগুলিতে অ্যাক্সেস করা তাদের দেখার কথা নয় - কেবল যদি আমি অনুমতিগুলি পরীক্ষা না করি (যা আমি করি, অন্যথায় আমার একটি আলাদা সুরক্ষা সমস্যা আছে)। "অন্তর্নিহিত কাজগুলি" সম্পর্কে তথ্য প্রকাশ করা - এটাই আমার প্রশ্ন। কেন এটি একটি সমস্যা?

— orip

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

— অ্যাডাম বেলায়ার 17

@ অ্যাডাম: স্তরের নিরাপত্তা কোনও সুরক্ষার চেয়ে খারাপ হতে পারে। কোনও সুরক্ষা না দিয়ে আপনি সুস্পষ্ট, পর্যাপ্ত সুরক্ষা সহ আপনি ভাবতে পারেন যে এটি অ-অবহেলিত কিছু যুক্ত করেছে।

— orip

Answer 5

আমরা ডাটাবেস আইডির জন্য জিইউইডি ব্যবহার করি। এগুলি ফাঁস করা অনেক কম বিপজ্জনক।

Comments

এটিই আমি পরামর্শ দেব। আপনার ডাটাবেসে জিইউইডিগুলি অনুমান করার খুব কম সম্ভাবনা রয়েছে।

— জন এরিকসন

এটি একটি পারফরম্যান্স দন্ডে আসে। এখানে

— যিশুরুন

গাইডগুলি ব্যবহার সম্পর্কে 1 মজার বিষয় হ'ল আপনি ক্লায়েন্টগুলিকে ডেটাবেস আইডি তৈরি করতে দিতে পারেন। মজাদার বিষয় 2 হ'ল অটো ইনক্রিমেন্টিং আইডির ভাবে শার্ল্ড ডাটাবেসের সাথে তাদের কোনও সমস্যা নেই।

— ব্রায়ান হোয়াইট

ব্যবহারকারী, মন্তব্য, পোস্টগুলি সনাক্ত করার জন্য আপনি এইচডিএমএল কোডে এইচডিএমএল আইডি বৈশিষ্ট্য হিসাবেও ব্যবহার করেন? কোন লিঙ্কটি ক্লিক করেছে বা কোন পোস্টে তিনি মন্তব্য করতে চান তা বোঝাতে?

— trzczy

Answer 6

আপনি যদি আপনার ডিবিতে পূর্ণসংখ্যার আইডি ব্যবহার করে থাকেন তবে ব্যবহারকারীরা কিউএস ভেরিয়েবল পরিবর্তন করে তাদের ডেটা দেখতে সহজেই পারবেন।

যেমন কোনও ব্যবহারকারী সহজেই এই কিউসে আইডি প্যারামিটারটি পরিবর্তন করতে এবং ডেটা দেখতে / সংশোধন করতে পারে তাদের http: // someurl? Id = 1

Comments

আমি যদি অনুমতিগুলি পরীক্ষা না করি তবে আমার একটি আলাদা সুরক্ষা সমস্যা আছে।

— orip

তবে উত্তরটি সঠিক: "হতে পারে"

— Seon Osewa

আপনি অনুমতি চেক করবেন কিনা তা প্রশ্ন নয়। আপনি যদি জানেন না এমন নতুন ভাড়া অনুমতি চেক করবে।

— ব্রায়ান হোয়াইট

@ ব্রায়ানহাইট - এ কারণেই আপনি স্থিতিতে একটি কোড পর্যালোচনা প্রক্রিয়া চান, যাতে এটির উত্পাদন হিট হওয়ার আগে আপনি তাদের শিক্ষিত করতে পারেন।

— ক্যান্ডু

আমরা যা করি তা হ'ল ইউআরএল বা ফর্ম ভেরিয়েবলগুলি ব্যবহার করার সময় পূর্ণসংখ্যার আইডিগুলি এনক্রিপ্ট করা।

— ব্রায়ান হোয়াইট

Answer 7

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

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

সুতরাং আমরা সিন্থেটিক সেশন লোকাল আইডি ব্যবহার করি কারণ এটি যতটা দূরে পারা যায় তা লুকায়।

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

Comments

আকর্ষণীয়, যদিও আমি মনে করি যে প্রতিটি অনুরোধের জন্য সমস্ত ইনপুট (ইউআরএল প্যারামিটার সহ) চেক করা ওয়েবে উপযুক্ত।

— orip