কীভাবে প্রস্তুত বিবৃতি এসকিউএল ইঞ্জেকশন আক্রমণ থেকে রক্ষা করতে পারে?


172

কীভাবে প্রস্তুত বিবৃতিগুলি এসকিউএল ইঞ্জেকশন আক্রমণ প্রতিরোধ করতে আমাদের সহায়তা করে ?

উইকিপিডিয়া বলেছেন:

প্রস্তুত বিবৃতিগুলি এসকিউএল ইনজেকশনের বিরুদ্ধে স্থিতিস্থাপক, কারণ প্যারামিটার মানগুলি, যা পরে অন্য একটি প্রোটোকল ব্যবহার করে প্রেরণ করা হয়, সঠিকভাবে পালানোর প্রয়োজন হয় না। যদি মূল বিবৃতি টেম্পলেটটি বাহ্যিক ইনপুট থেকে প্রাপ্ত না হয় তবে এসকিউএল ইঞ্জেকশনটি ঘটতে পারে না।

আমি কারণটি খুব ভাল দেখতে পাচ্ছি না। সহজ ইংরেজী এবং কিছু উদাহরণের সহজ ব্যাখ্যা কী হবে?

উত্তর:


290

ধারণাটি খুব সহজ - কোয়েরি এবং ডেটা পৃথকভাবে ডাটাবেস সার্ভারে প্রেরণ করা হয় ।
এখানেই শেষ.

এসকিউএল ইঞ্জেকশন সমস্যার মূলটি কোড এবং ডেটা মেশানো।

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

$expected_data = 1;
$query = "SELECT * FROM users where id=$expected_data";

একটি নিয়মিত ক্যোয়ারী উত্পন্ন করবে

SELECT * FROM users where id=1

এই কোড যখন

$spoiled_data = "1; DROP TABLE users;"
$query        = "SELECT * FROM users where id=$spoiled_data";

একটি দূষিত ক্রম উত্পাদন করবে

SELECT * FROM users where id=1; DROP TABLE users;

এটি কাজ করে কারণ আমরা সরাসরি প্রোগ্রামের মূল অংশে ডেটা যুক্ত করছি এবং এটি প্রোগ্রামের একটি অংশে পরিণত হয়, সুতরাং ডেটা প্রোগ্রামটি পরিবর্তন করতে পারে এবং পাস করা ডেটার উপর নির্ভর করে আমাদের হয় নিয়মিত আউটপুট বা একটি টেবিল usersমোছা।

যদিও প্রস্তুত বিবৃতি ক্ষেত্রে আমরা আমাদের প্রোগ্রাম পরিবর্তন না, এটা অক্ষত থাকে
বিন্দু হয়।

আমরা প্রথমে একটি প্রোগ্রাম সার্ভারে প্রেরণ করছি

$db->prepare("SELECT * FROM users where id=?");

যেখানে ডেটাটি কিছু পরিবর্তনশীল দ্বারা পরামিতি বা স্থানধারক দ্বারা প্রতিস্থাপিত হয় ।

মনে রাখবেন ঠিক একই প্রশ্নটি কোনও ডেটা ছাড়াই সার্ভারে প্রেরণ করা হয়েছে! এবং তারপরে আমরা দ্বিতীয় অনুরোধের সাথে ডেটা প্রেরণ করছি , প্রয়োজনীয়ভাবে নিজেরাই ক্যোয়ারী থেকে পৃথক করা:

$db->execute($data);

সুতরাং এটি আমাদের প্রোগ্রাম পরিবর্তন করতে এবং কোনও ক্ষতি করতে পারে না।
বেশ সহজ - তাই না?

আমাকে কেবল যুক্ত করতে হবে যা প্রতিটি ম্যানুয়ালটিতে সর্বদা বাদ দেওয়া হয়:

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


2
"উদাহরণস্বরূপ, ডিফল্টরূপে পিডিও প্রস্তুত বিবৃতি ব্যবহার করবেন না" - এটি ঠিক সত্য নয়, কারণ পিডিও কেবল এমন ড্রাইভারের জন্য প্রস্তুত বিবৃতি অনুকরণ করে যা এই জাতীয় বৈশিষ্ট্য সমর্থন করে না।
পাইনপেইন

3
@ zaq178miami: "পিডিও কেবল এমন ড্রাইভারের জন্য প্রস্তুত বিবৃতিগুলি এমুলেট করে যা বৈশিষ্ট্যটি সমর্থন করে না" - ঠিক সত্য নয়। মাইএসকিউএল বেশ কিছু সময়ের জন্য প্রস্তুত বিবৃতিগুলিকে সমর্থন করেছে। পিডিও ড্রাইভারও আছে। তবে তবুও, মাইএসকিউএল অনুসন্ধানগুলি পিডিও দ্বারা ডিফল্টরূপে এখনও প্রস্তুত ছিল, শেষবার আমি যাচাই করেছিলাম।
সিএওও

9
কি মধ্যে পার্থক্য কী $spoiled_data = "1; DROP TABLE users;"-> $query = "SELECT * FROM users where id=$spoiled_data";, এর তুলনা করেছেন: $db->prepare("SELECT * FROM users where id=?");-> $data = "1; DROP TABLE users;"-> $db->execute($data);। তারা কি একই কাজ করবে না?
জুহা আনটিনেন

14
@ জুহা আনটিনেন ডেটা যে কোনও কিছু হতে পারে। এটি ডেটা বিশ্লেষণ করবে না। এটি হ'ল ডেটা কমান্ড নয়। সুতরাং এমনকি যদি $ ডেটাতে এসকিএল কমান্ড থাকে তবে এটি কার্যকর করা হবে না। এছাড়াও, আইডিটি যদি একটি নম্বর হয় তবে স্ট্রিং সামগ্রীটি একটি প্রতিবেদন বা মান শূন্য উত্পন্ন করবে।
Soley

21

উদাহরণ স্থাপনের জন্য এখানে এসকিউএল রয়েছে:

CREATE TABLE employee(name varchar, paymentType varchar, amount bigint);

INSERT INTO employee VALUES('Aaron', 'salary', 100);
INSERT INTO employee VALUES('Aaron', 'bonus', 50);
INSERT INTO employee VALUES('Bob', 'salary', 50);
INSERT INTO employee VALUES('Bob', 'bonus', 0);

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

import java.sql.*;

public class Inject {

    public static void main(String[] args) throws SQLException {

        String url = "jdbc:postgresql://localhost/postgres?user=user&password=pwd";
        Connection conn = DriverManager.getConnection(url);

        Statement stmt = conn.createStatement();
        String sql = "SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='" + args[0] + "'";
        System.out.println(sql);
        ResultSet rs = stmt.executeQuery(sql);

        while (rs.next()) {
            System.out.println(rs.getString("paymentType") + " " + rs.getLong("amount"));
        }
    }
}

এটি চলমান, প্রথম কেসটি সাধারণ ব্যবহারের সাথে এবং দ্বিতীয়টি দূষিত ইনজেকশন সহ:

c:\temp>java Inject salary
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='salary'
salary 50

c:\temp>java Inject "salary' OR 'a'!='b"
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='salary' OR 'a'!='b'
salary 100
bonus 50
salary 50
bonus 0

ব্যবহারকারীর ইনপুটটির স্ট্রিং কনটেন্টেশন দিয়ে আপনার এসকিউএল স্টেটমেন্টগুলি তৈরি করা উচিত নয়। এটি কেবল ইনজেকশনের জন্যই ঝুঁকিপূর্ণ নয়, তবে এটি সার্ভারেও ক্যাচিং ইম্পটিকেশনগুলি রয়েছে (বিবৃতি পরিবর্তন হয়, তাই এসকিউএল স্টেটমেন্ট ক্যাশে হিট হওয়ার সম্ভাবনা কম থাকে তবে বাইন্ড উদাহরণটি সর্বদা একই বিবৃতি চালায়)।

এই ধরণের ইনজেকশন এড়ানোর জন্য এখানে বাইন্ডিংয়ের উদাহরণ রয়েছে:

import java.sql.*;

public class Bind {

    public static void main(String[] args) throws SQLException {

        String url = "jdbc:postgresql://localhost/postgres?user=postgres&password=postgres";
        Connection conn = DriverManager.getConnection(url);

        String sql = "SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?";
        System.out.println(sql);

        PreparedStatement stmt = conn.prepareStatement(sql);
        stmt.setString(1, args[0]);

        ResultSet rs = stmt.executeQuery();

        while (rs.next()) {
            System.out.println(rs.getString("paymentType") + " " + rs.getLong("amount"));
        }
    }
}

পূর্ববর্তী উদাহরণের মতো একই ইনপুট দিয়ে এটি চালানো দেখায় যে দূষিত কোডটি কাজ করে না কারণ এই স্ট্রিংয়ের সাথে কোনও পেমেন্টটাইপ মেলে না:

c:\temp>java Bind salary
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?
salary 50

c:\temp>java Bind "salary' OR 'a'!='b"
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?

ডাটাবেসের সাথে সংযোগকারী প্রোগ্রাম থেকে প্রস্তুত বিবৃতি ব্যবহার করা কি ডিবি অংশ হিসাবে প্রস্তুত বিবৃতি ব্যবহারের মতো একই প্রভাব ফেলতে পারে? উদাহরণস্বরূপ পোস্টগ্রিসের নিজস্ব প্রস্তুত বিবৃতি রয়েছে এবং এটি ব্যবহার করে এসকিউএল ইঞ্জেকশনটি প্রতিরোধ করবে? postgresql.org/docs/9.2/static/sql-prepare.html
সেলিব্রেটিস

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

@ চেরিরিটাস আমি x86_64 এর উপরে পোস্টগ্রেএসকিউএল ১১.১ ব্যবহার করে উপরে বর্ণিত এসকিউএলআই উদাহরণ ব্যবহার করেছি।
কৃষ্ণ পান্ডে

15

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

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

আরও দুর্দান্ত তথ্য এখানে:

প্রস্তুত বিবৃতি এবং এসকিউএল ইঞ্জেকশন


6

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

নিষ্পাপ দৃষ্টিভঙ্গি

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

String SQLString = "SELECT * FROM CUSTOMERS WHERE NAME='"+userInput+"'"

উদাহরণস্বরূপ, দূষিত ব্যবহারকারী ইনপুট SQLStringসমান হতে পারে"SELECT * FROM CUSTOMERS WHERE NAME='James';DROP TABLE CUSTOMERS;'

দূষিত ব্যবহারকারীর কারণে, SQLStringএতে 2 টি স্টেটমেন্ট রয়েছে, যেখানে 2 য় একটি ( "DROP TABLE CUSTOMERS") ক্ষতি করে।

বিবৃতি প্রস্তুত

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

সংক্ষেপে, প্রস্তুত বিবৃতি সহ ব্যবহারকারী ইনপুট মাধ্যমে চালু দূষিত কোড কার্যকর করা হবে না!


সত্যি? গৃহীত উত্তর ঠিক তা বলে না?
আপনার সাধারণ অনুভূতি

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

এবং আপনার উত্তরগুলিতে কোন "প্রয়োগের বিশদ" সরবরাহ করা হয়েছে যা সেখানে উপস্থিত নেই?
আপনার সাধারণ জ্ঞান

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

এটিকে এমন একটি সমৃদ্ধি বিবেচনা করুন যা ক্রুক্সকে ব্যাখ্যা করে, এবং একটি অন্তর্নিহিত সমালোচনা হিসাবে নয় (গ্রহণযোগ্য প্রতিক্রিয়াটির রচয়িতা কে ছিলেন তা পুনরায় উপলব্ধি করা হয়েছিল)।
এন ভিজেটা

5

আপনি যখন DBMS এ একটি প্রস্তুত বিবৃতি তৈরি এবং প্রেরণ করেন, এটি কার্যকর করার জন্য এসকিউএল কোয়েরি হিসাবে সঞ্চিত থাকে।

পরে আপনি আপনার ডেটাটিকে ক্যোয়ারিতে এমনভাবে আবদ্ধ করুন যে DBMS সেই ডেটা প্রয়োগের জন্য ক্যোয়ারী প্যারামিটার হিসাবে ব্যবহার করে (প্যারামিটারাইজেশন)। DBMS ইতিমধ্যে সংকলিত এসকিউএল কোয়েরির পরিপূরক হিসাবে আপনি যে ডেটা বেঁধেছেন তা ব্যবহার করে না; এটি কেবল ডেটা।

এর অর্থ প্রস্তুত বিবৃতি ব্যবহার করে এসকিউএল ইঞ্জেকশন করা মৌলিকভাবে অসম্ভব। প্রস্তুত বিবৃতিগুলির খুব প্রকৃতি এবং ডিবিএমএসের সাথে তাদের সম্পর্ক এটি প্রতিরোধ করে।


4

ইন SQL সার্ভার , একটি প্রস্তুত স্টেটমেন্ট ব্যবহার স্পষ্টভাবে ইনজেকশন রোধক কারণ ইনপুট প্যারামিটার কোয়েরি গঠন না। এর অর্থ হল মৃত্যুদন্ডপ্রাপ্ত ক্যোয়ারী ডায়নামিক ক্যোয়ারী নয়। একটি এসকিউএল ইঞ্জেকশন দুর্বল বিবৃতি উদাহরণ।

string sqlquery = "select * from table where username='" + inputusername +"' and password='" + pass + "'";

এখন যদি ইন-আউটউজারনেম ভেরিয়েবলের মান 'বা 1 = 1 - এর মতো কিছু হয় তবে এই ক্যোয়ারী এখন পরিণত হয়:

select * from table where username='a' or 1=1 -- and password=asda

এবং বাকীটি পরে মন্তব্য করা হয়েছে --, সুতরাং এটি কখনই কার্যকর হয় না এবং নীচের মতো প্রস্তুত বিবৃতি উদাহরণ ব্যবহার করে বাইপাস করা হয় না।

Sqlcommand command = new sqlcommand("select * from table where username = @userinput and password=@pass");
command.Parameters.Add(new SqlParameter("@userinput", 100));
command.Parameters.Add(new SqlParameter("@pass", 100));
command.prepare();

সুতরাং বাস্তবে আপনি আর কোনও প্যারামিটার পাঠাতে পারবেন না, এভাবে এসকিউএল ইঞ্জেকশনটি এড়ানো ...


3

মূল বাক্যাংশটি হ'ল need not be correctly escaped। এর অর্থ হ'ল যে লোকেরা ড্যাশ, অ্যাস্টোস্ট্রোফস, কোটস ইত্যাদি ছোঁড়ার চেষ্টা করছে তাদের সম্পর্কে আপনি চিন্তা করবেন না ...

এটি সব আপনার জন্য পরিচালিত হয়।


2
ResultSet rs = statement.executeQuery("select * from foo where value = " + httpRequest.getParameter("filter");

আসুন ধরে নেওয়া যাক আপনার কোনও সার্লেলে আপনার অধিকার আছে। যদি কোনও খারাপ লোক 'ফিল্টার' এর জন্য খারাপ মান পাস করে তবে আপনি আপনার ডাটাবেস হ্যাক করতে পারেন।


0

মূল কারণ # 1 - ডিলিমিটার সমস্যা

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

মূল কারণ # 2 - মানব প্রকৃতি, মানুষ কৃপণতা এবং কিছু ধূর্ত লোকেরা দূষিত এবং সমস্ত লোক ভুল করে

স্কয়ার ইঞ্জেকশনের অন্যান্য মূল কারণ হ'ল মানব প্রকৃতি। প্রোগ্রামার সহ লোকেরা ভুল করে। আপনি যখন কোনও কাঠামোগত ক্যোয়ারিতে ভুল করেন, এটি আপনার সিস্টেমকে স্কুয়েল ইঞ্জেকশনের জন্য দুর্বল করে না। আপনি যদি কাঠামোগত ক্যোয়ারী ব্যবহার না করে থাকেন তবে ভুলগুলি স্কিল ইনজেকশন দুর্বলতা তৈরি করতে পারে।

কীভাবে কাঠামোগত প্রশ্নগুলি এসকিউএল ইঞ্জেকশনের মূল কারণগুলি সমাধান করে

স্ট্রাকচার্ড ক্যোয়ারীগুলি একটি বিবৃতিতে এসকিএল কমান্ড রেখে এবং ডেটাটিকে একটি পৃথক প্রোগ্রামিং স্টেটমেন্টে রেখে, ডেলিমিটার সমস্যা সমাধান করে। প্রোগ্রামিং বিবৃতি পৃথকীকরণ প্রয়োজন তৈরি।

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

সুতরাং, সেখানে এটি আপনার রয়েছে, বর্গক্ষেত্রের ইনজেকশনের কারণ এবং প্রকৃতি কাঠামোগত অনুসন্ধানগুলি যখন ব্যবহার করা হয় তখন এগুলি অসম্ভব করে তোলে।

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