এসকিউএল ইঞ্জেকশন কেন একটি সঞ্চিত পদ্ধতির ভিতরে এই ক্যোয়ারিতে ঘটে না?

Question

আমি নিম্নলিখিত সঞ্চিত পদ্ধতি তৈরি করেছি:

ALTER PROCEDURE usp_actorBirthdays (@nameString nvarchar(100), @actorgender nvarchar(100))
AS
SELECT ActorDOB, ActorName FROM tblActor
WHERE ActorName LIKE '%' + @nameString + '%'
AND ActorGender = @actorgender

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

EXEC usp_actorBirthdays 'Tom', 'Male; DROP TABLE tblActor'

নীচের চিত্রটি এসএসএমএসে উপরের এসকিউএলকে কার্যকর করা হচ্ছে এবং ফলাফল ত্রুটির পরিবর্তে সঠিকভাবে প্রদর্শিত হচ্ছে:

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

Comments

আপনি কি চেষ্টা করেছেনEXEC usp_actorBirthdays 'Tom', 'Male''; DROP TABLE tblActor'

— মার্মিক

Answer 1

এই কোডটি সঠিকভাবে কাজ করে কারণ এটি হ'ল:

1. প্যারামিটারাইজড, এবং
2. কোনও ডায়নামিক এসকিউএল করছে না

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

একটি "আপোসড" মানটি পাস করার প্রয়াসে, 'Male; DROP TABLE tblActor'স্ট্রিংটি ঠিক এটি, একটি সরল-ওল 'স্ট্রিং।

এখন, আপনি যদি লাইন ধরে কিছু করছেন:

DECLARE @SQL NVARCHAR(MAX);

SET @SQL = N'SELECT fields FROM table WHERE field23 = '
          + @InputParam;

EXEC(@SQL);

তাহলে এটি এসকিউএল ইনজেকশনের পক্ষে সংবেদনশীল হবে কারণ সেই ক্যোয়ারী বর্তমান, প্রাক-পার্সড প্রসঙ্গে নয়; এই ক্যোয়ারী এই মুহুর্তে অন্য একটি স্ট্রিং। সুতরাং এর মান @InputParamহতে পারে '2015-10-31'; SELECT * FROM PlainTextCreditCardInfo;এবং এটি একটি সমস্যা উপস্থাপন করতে পারে কারণ এই ক্যোয়ারীটি রেন্ডার করা হবে এবং কার্যকর করা হবে:

SELECT fields FROM table WHERE field23 = '2015-10-31'; SELECT * FROM PlainTextCreditCardInfo;

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

DECLARE @SQL NVARCHAR(MAX);

SET @SQL = N'SELECT fields FROM table WHERE field23 = @SomeDate_tmp';

EXEC sp_executesql
  @SQL,
  N'SomeDate_tmp DATETIME',
  @SomeDate_tmp = @InputParam;

এই পদ্ধতির ব্যবহার করে, কেউ যদি ইনপুট প্যারামিটারের '2015-10-31'; SELECT * FROM PlainTextCreditCardInfo;জন্য প্রবেশ করার চেষ্টা DATETIMEকরে তবে সঞ্চিত পদ্ধতি কার্যকর করার সময় কেউ ত্রুটি পেতে পারে get অথবা এমনকি যদি সঞ্চিত পদ্ধতি গৃহীত @InputParameterহিসাবে NVARCHAR(100), বলা যায় এর রূপান্তরের একটি থেকে করতে হবে DATETIME, যাতে যে মধ্যে পাস করার জন্য sp_executesqlকল। এমনকি ডায়নামিক এসকিউএল-এর পরামিতি যদি স্ট্রিং টাইপ হয় তবে প্রথমে স্টোরড পদ্ধতিতে এসে যে কোনও একক অ্যাড্রোস্ফ স্বয়ংক্রিয়ভাবে ডাবল অ্যাডাস্ট্রোফের কাছে পালিয়ে যায়।

আক্রমণটির একটি কম পরিচিত প্রকার রয়েছে যার মধ্যে আক্রমণকারী এস্ট্রোফেসের সাহায্যে ইনপুট ক্ষেত্রটি পূরণ করার চেষ্টা করে যে স্টোরড পদ্ধতির অভ্যন্তরে একটি স্ট্রিং যা ডায়নামিক এসকিউএল তৈরি করতে ব্যবহৃত হবে তবে যা খুব ছোট হিসাবে ঘোষণা করা হয়েছে তা সবই ফিট করে না এবং শেষের অ্যাস্ট্রোফিকে পুশ করে এবং কোনওভাবেই অ্যাডাস্ট্রোফের সঠিক সংখ্যার সাথে শেষ হয় যাতে স্ট্রিংয়ের মধ্যে আর "পলায়ন" না হয়। এটিকে এসকিউএল ট্রানকেশন বলা হয় এবং এটি বাল নেরুমাল্লার "নিউ এসকিউএল ট্রানকেশন অ্যাটাকস এবং কীভাবে তাদের এড়ানো যায়" শীর্ষক একটি এমএসডিএন ম্যাগাজিনের প্রবন্ধে কথা হয়েছিল, তবে নিবন্ধটি আর অনলাইনে নেই। এই নিবন্ধটি সম্বলিত সমস্যা - এমএসডিএন ম্যাগাজিনের নভেম্বর, ২০০ edition সংস্করণ - কেবল উইন্ডোজ সহায়তা ফাইল হিসাবে পাওয়া যায় ( .chm এবিন্যাস)। আপনি যদি এটি ডাউনলোড করেন তবে এটি ডিফল্ট সুরক্ষা সেটিংসের কারণে না খুলতে পারে। যদি এটি ঘটে থাকে তবে MSDNMagazineNovember2006en-us.chm ফাইলটিতে ডান ক্লিক করুন এবং "সম্পত্তি" নির্বাচন করুন। এই ট্যাবগুলির মধ্যে একটিতে "এই ধরণের ফাইলকে বিশ্বাস করুন" (বা এর মতো কোনও কিছু) জন্য একটি বিকল্প থাকবে যা পরীক্ষা / সক্ষম করতে হবে। "ঠিক আছে" বোতামটি ক্লিক করুন এবং তারপরে আবার .chm ফাইলটি খোলার চেষ্টা করুন ।

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

-- Parameters:
DECLARE @UserID      INT = 37,
        @NewPassword NVARCHAR(15) = N'Any Value ....''',
        @OldPassword NVARCHAR(15) = N';Injected SQL--';

-- Stored Proc:
DECLARE @SQL NVARCHAR(MAX),
        @NewPassword_fixed NVARCHAR(15) = REPLACE(@NewPassword, N'''', N''''''),
        @OldPassword_fixed NVARCHAR(15) = REPLACE(@OldPassword, N'''', N'''''');

SELECT @NewPassword AS [@NewPassword],
       REPLACE(@NewPassword, N'''', N'''''') AS [REPLACE output],
       @NewPassword_fixed AS [@NewPassword_fixed];
/*
@NewPassword          REPLACE output          @NewPassword_fixed
Any Value ....'       Any Value ....''        Any Value ....'
*/

SELECT @OldPassword AS [@OldPassword],
       REPLACE(@OldPassword, N'''', N'''''') AS [REPLACE output],
       @OldPassword_fixed AS [@OldPassword_fixed];
/*
@OldPassword          REPLACE output          @OldPassword_fixed
;Injected SQL--       ;Injected SQL--         ;Injected SQL--
*/

SET @SQL = N'UPDATE dbo.TableName SET [Password] = N'''
           + @NewPassword_fixed + N''' WHERE [TableNameID] = '
           + CONVERT(NVARCHAR(10), @UserID) + N' AND [Password] = N'''
           + @OldPassword_fixed + N''';';

SELECT @SQL AS [Injected];

এখানে কার্যকর করা ডায়নামিক এসকিউএল এখন:

UPDATE dbo.TableName SET [Password] = N'Any Value ....'' WHERE [TableNameID] = 37 AND [Password] = N';Injected SQL--';

সেই একই গতিশীল এসকিউএল, আরও পঠনযোগ্য ফর্ম্যাটে, হ'ল:

UPDATE dbo.TableName SET [Password] = N'Any Value ....'' WHERE [TableNameID] = 37 AND [Password] = N';

Injected SQL--';

এটি ঠিক করা সহজ is কেবল নিম্নলিখিতগুলির মধ্যে একটি করুন:

1. না ব্যবহার গতিশীল এসকিউএল যদি না কোনোরকম প্রয়োজনীয়! (আমি এটি প্রথমে তালিকাবদ্ধ করছি কারণ এটি বিবেচনার জন্য প্রথম বিষয় হওয়া উচিত)।
2. স্থানীয় ভেরিয়েবলের যথাযথ আকার দিন (যেমন ইনপুট প্যারামিটার হিসাবে আকারের দ্বিগুণ হওয়া উচিত, কেবলমাত্র যদি সমস্ত অক্ষর উত্তীর্ণ হয় তবে একক-কোট হয়।

3. "নির্দিষ্ট" মান সঞ্চয় করতে স্থানীয় ভেরিয়েবল ব্যবহার করবেন না; শুধু করা REPLACE()ডায়নামিক এসকিউএল সৃষ্টির মধ্যে সরাসরি:

   SET @SQL = N'UPDATE dbo.TableName SET [Password] = N'''
              + REPLACE(@NewPassword, N'''', N'''''') + N''' WHERE [TableNameID] = '
              + CONVERT(NVARCHAR(10), @UserID) + N' AND [Password] = N'''
              + REPLACE(@OldPassword, N'''', N'''''') + N''';';
   
   SELECT @SQL AS [No SQL Injection here];

   ডায়নামিক এসকিউএল আর আপোস করা হয় না:

   UPDATE dbo.TableName SET [Password] = N'Any Value ....''' WHERE [TableNameID] = 37 AND [Password] = N';Injected SQL--';

উপরের ট্রানকশন উদাহরণ সম্পর্কে নোট:

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

---

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

এসকিউএল ইনজেকশন এবং এসকিউএল কেটে সম্পর্কিত স্ট্যাক ওভারফ্লো উত্তর:
আপনি 'এস্কেপ চরিত্রটি প্রতিস্থাপন করার পরে টি-এসকিউএল কতটা নিরাপদ?

Comments

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

— রবি

@ রাভী আমি লিঙ্কটি পেয়েছি কিন্তু এখন সেগুলি সংরক্ষণাগার হিসাবে নিবন্ধটি পাবে না। তবে আমি কিছু তথ্য এবং দরকারী লিঙ্ক যুক্ত করেছি এবং আমি এখনও সেই সংরক্ষণাগারগুলির মধ্যে নিবন্ধটি সন্ধান করার চেষ্টা করছি।

— সলোমন রুটজকি

আপনাকে শ্রুতজস্কি ধন্যবাদ, আমি OWASP নিবন্ধ এবং ইনজেকশনের জন্য পরীক্ষাগুলি পড়ব। যদি আমি সঠিকভাবে মনে রাখি, 'মুটিলিডি', সুরক্ষা পরীক্ষার জন্য অরক্ষিত ওয়েব অ্যাপ্লিকেশনটিতে এসকিউএল ইঞ্জেকশন রয়েছে যা আমি 'OR 1 = 1' স্ট্রিংয়ের মাধ্যমে কলেজে সম্পাদন করেছিলাম যার ফলে মুটিলিডে আমাকে অ্যাডমিন হিসাবে ওয়েব অ্যাপে লগ ইন করেছিল in মনে করি। এসকিউএল ইঞ্জেকশনের সাথে আমার প্রথম পরিচয় হয়েছিল That's

— রবি

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

— রবি

Answer 2

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

আমি এটি সম্পর্কে এখানে ব্লগ করেছি: http://blogs.lobsterpot.com.au/2015/02/10/sql-inication-the-golden-rule/

Comments

আপনাকে ধন্যবাদ রব, দিনের পর দিন পড়ার জন্য আমার এই একটি বুকমার্ক রয়েছে।

— রবি