এসএমএল ইনজেকশন থেকে রক্ষা করার একমাত্র উপায় কি প্যারামিট্রাইজড কোয়েরিতে নির্ভরতা?


13

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

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

  1. কোনও ক্লায়েন্ট / অ্যাপ্লিকেশনটির ডেটাবেস টেবিলগুলিতে সরাসরি অ্যাক্সেস ছিল না।
  2. সমস্ত টেবিলের সমস্ত অ্যাক্সেস ভিউয়ের মাধ্যমে হয়েছিল (এবং বেস টেবিলগুলিতে সমস্ত আপডেট ট্রিগারগুলির মাধ্যমে সম্পন্ন হয়েছিল)।
  3. সমস্ত ডেটা আইটেম একটি ডোমেন নির্দিষ্ট ছিল।
  4. কোনও ডেটা আইটেমকে নলাবদ্ধ হওয়ার অনুমতি দেওয়া হয়নি - এর মধ্যে এমন প্রভাব রয়েছে যা ডিবিএগুলি উপলক্ষে দাঁত পিষেছিল; কিন্তু প্রয়োগ করা হয়েছিল।
  5. ভূমিকা এবং অনুমতিগুলি যথাযথভাবে সেট আপ করা হয়েছিল - উদাহরণস্বরূপ, কেবলমাত্র দর্শনগুলি ডেটা পরিবর্তন করার অধিকার দেওয়ার ক্ষেত্রে একটি সীমাবদ্ধ ভূমিকা role

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

সম্পাদনা

প্রাথমিক জবাব প্রাপ্তির আলোকে প্রশ্নের জোর সামান্য পরিবর্তন হয়েছে। বেস প্রশ্ন অপরিবর্তিত।

EDIT2

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

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

http://database-programmer.blogspot.com

http://thehelsinkideclaration.blogspot.com

আমি এই উত্সগুলি থেকে নেওয়া মূল নীতিগুলি হ'ল:

  1. একটি বিস্তৃত ডেটা অভিধান, একটি বিস্তৃত সুরক্ষা ডেটা অভিধানের সাথে মিলিত
  2. ডেটা অভিধান থেকে ট্রিগার, কোয়েরি এবং সীমাবদ্ধতার উত্স
  3. কোডটি ছোট করুন এবং ডেটা সর্বাধিক করুন

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


আমি সঞ্চিত পদ্ধতির বিরুদ্ধে যুক্তিগুলি কিনছি না। এগুলি কেবল সত্য নয়।
কনরাড রুডলফ

নো-নালসের প্রয়োজনীয়তা কী?
মার্ক ক্যানলাস

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

@ ম্যাথু দুহ আমি পড়ার সময় এবং এটি সম্পর্কে মন্তব্য করার সময় আমি আসলে "প্যারাম্যাট্রিস্টেড ক্যোয়ারী" ভাবছিলাম। সঞ্চিত পদ্ধতি = পুরো 'nother গল্প।
কনরাড রুডল্ফ

উত্তর:


25

সঞ্চিত প্রকল্পগুলি ইঞ্জেকশন থেকে স্বয়ংক্রিয়ভাবে সুরক্ষা দেয় না। এই সম্পর্কে কি

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

প্যারামিটারাইজড কোয়েরিগুলি ব্যবহার করা আপনাকে ইঞ্জেকশন থেকে রক্ষা করবে, সেগুলি প্রকাক্সে রয়েছে কিনা whether


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

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

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

@ জন - আমি ক্রেগের সংশোধনের আলোকে প্রশ্নের শিরোনাম পরিবর্তন করেছি এবং প্রশ্নের কিছু সম্পাদনা করেছি। আমি উত্তর পেতে শুরু না হওয়া পর্যন্ত আমি প্রশ্নে যে ধারণা নিয়েছিলাম সে সম্পর্কে আমি অবগত ছিলাম না।
ক্রিস ওয়ালটন

2
কি ক্রেইগ উপরে লিখেছেন শক্তিশালী করা দেখুন databasesecurity.com/dbsec/lateral-sql-injection.pdf : "Oracle এ দুর্বলতার একটি নতুন ক্লাস পাশ্বর্ীয় এসকিউএল ইনজেকশন"
ব্রুস Ediger

11

সুতরাং এসকিউএল ইনজেকশন আক্রমণ রোধে সঞ্চিত প্রক্রিয়াগুলির জন্য এটি (প্রয়োগ করা) নিয়মের একটি সেট কি উপযুক্ত বিকল্প? তা না হলে কেন?

না, কারণ তারা বিকাশকারীদের পরিবর্তে একটি ভারী জরিমানা জারি করে। প্রতি আইটেম ভাঙ্গন:

১. কোনও ক্লায়েন্ট / অ্যাপ্লিকেশনের ডাটাবেস টেবিলগুলিতে সরাসরি প্রবেশাধিকার ছিল না।

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

২. সমস্ত টেবিলের সমস্ত অ্যাক্সেস ভিউয়ের মাধ্যমে।

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

৩. সমস্ত ডেটা আইটেমের একটি ডোমেন নির্দিষ্ট ছিল।

বজায় রাখার জন্য প্রচুর কাজ হতে পারে এবং সম্ভবত একটি পৃথক টেবিলের মধ্যে স্বাভাবিক করা উচিত।

৪. কোনও ডেটা আইটেমকে নলাবদ্ধ হওয়ার অনুমতি দেওয়া হয়নি - এর মধ্যে এমন প্রভাব রয়েছে যা ডিবিএগুলি উপলক্ষে দাঁত পিষেছিল; কিন্তু প্রয়োগ করা হয়েছিল।

এটা ঠিক সাধারণ ভুল। বিকাশকারীরা যদি পরিচালনা করতে অক্ষম হন তবে NULLআপনার বড় সমস্যা রয়েছে।

ডেটাবেস (কেবলমাত্র) নির্দিষ্ট পদক্ষেপের মাধ্যমে এই জাতীয় আক্রমণগুলির বিরুদ্ধে সুরক্ষা দেওয়া যেতে পারে?

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



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

6

আমি নিশ্চিত না যে আপনার বিধিগুলি আপনাকে পুরোপুরি সুরক্ষা দেয়।

প্রথম সমস্যাটি হ'ল আপনি বলছেন যে এগুলি কার্যকর করা হয়েছে তবে পাশাপাশি কোনও উল্লেখযোগ্য ওভারহেড নিয়ে আসছেন, আমি কখনই নিখুঁত বাস্তবায়ন দেখিনি।

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

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

(ট্রিগারগুলির মাধ্যমে করা সমস্ত আপডেটের ক্ষেত্রে আমি দুটি কথা বলতে যাচ্ছি: (1) আমি যখন এটি পড়ি তখন আমি আমার মুখে কিছুটা অসুস্থ হয়ে পড়েছিলাম এবং (খ) আপনি সঞ্চিত পদ্ধতি পছন্দ করেন না কারণ তারা ' "" কম রক্ষণাবেক্ষণযোগ্য; কম পরীক্ষামূলক; অত্যন্ত যুগল; এবং একটি বিক্রেতার মধ্যে একটি সিস্টেমকে লক করা হয়েছে "তবে আপনি ট্রিগারগুলি ব্যবহার করেন যা সম্পর্কে একই জিনিসগুলি মূলত বলা যেতে পারে))

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

এখানে অন্য জিনিসটি হ'ল আপনি জটিলতাও যুক্ত করছেন এবং (পাশাপাশি ওভারহেড যা তৈরি করে) জটিলতা হ'ল ছিদ্রগুলির দিকে নিয়ে যায় যা শোষণ করা যায়।

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


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