AI দিয়ে কোডের নিরাপত্তা পরীক্ষা: SQL injection ধরা

AI কোড পড়ে নিরাপত্তার ভুল খুঁজতে বেশ ভালো, বিশেষ করে পরিচিত ভুলগুলো। কিন্তু AI বলেছে বলেই কিছু সত্যি নয়। এই লেখায় একটা দুর্বল লগইন কোড ChatGPT-কে রিভিউ করাব, তারপর নিজের মেশিনে আক্রমণ চালিয়ে মিলিয়ে দেখব। শেষে দেখব AI অ্যাপের নিজের ঝুঁকিগুলো।

ধাপ ১: কোড আর পরিষ্কার নির্দেশ দিন

নিচের Flask কোডে ফোন নম্বর আর পিন দিয়ে লগইন হয়। ChatGPT-কে বলুন কী চান: প্রতিটি সমস্যা, তার গুরুত্ব, কেন বিপজ্জনক, আর ঠিক করা কোড।

এই Flask কোডে নিরাপত্তার কী কী সমস্যা আছে দেখুন। প্রতিটি সমস্যার গুরুত্ব (high, medium বা low), কেন বিপজ্জনক, আর ঠিক করা কোড দিন। parameterized query ব্যবহার করবেন।

@app.route("/login", methods=["POST"])
def login():
    phone = request.form["phone"]
    pin = request.form["pin"]
    row = db.execute(
        f"SELECT id FROM users WHERE phone = '{phone}' AND pin = '{pin}'"
    ).fetchone()
    if row:
        session["user_id"] = row[0]
        return redirect("/dashboard")
    return "Wrong phone or PIN", 401

১২

বড় করে দেখতে ছবিতে চাপ দিন

1. ১কোডসহ অনুরোধ
2. ২পাঠানোর বোতাম

ধাপ ২: AI-এর তালিকা পড়ুন

১

বড় করে দেখতে ছবিতে চাপ দিন

1. ১প্রথম সমস্যা: SQL injection, গুরুত্ব high

ChatGPT সবার উপরে রেখেছে SQL injection, গুরুত্ব high: ফোন আর পিন সরাসরি SQL লেখার ভেতরে বসছে, তাই বিশেষ ইনপুট দিয়ে query-এর মানে বদলানো যায়। তারপর আরও কয়েকটা: ডেটাবেসে পিন খোলা অবস্থায় (plaintext) রাখার ঝুঁকি, session, CSRF সুরক্ষার অভাব, আর বারবার ভুল পিন দিয়ে চেষ্টা আটকানোর (rate limiting) ব্যবস্থা নেই।

আমরা চেয়েছিলাম একটা সমস্যা, পেয়েছি পাঁচটা। এটাই AI রিভিউয়ের সুবিধা: একটা চেকলিস্ট ধরে সব দিক দেখে। তবে তালিকার প্রতিটা দাবি সত্যি কিনা, সেটা আপনাকেই দেখতে হবে।

ধাপ ৩: ঠিক করা কোড দেখুন

১

বড় করে দেখতে ছবিতে চাপ দিন

1. ১ঠিক করা কোড: SQL-এ শুধু ?, মান আলাদা করে পাঠানো

মূল বদলটা ছোট। আগে ফোন আর পিন সরাসরি SQL লেখার ভেতরে বসছিল। এখন SQL-এ শুধু ? থাকে, আর মানগুলো আলাদা করে যায়। ডেটাবেস তখন ইনপুটকে লেখা হিসেবেই নেয়, SQL-এর অংশ হিসেবে নয়। OWASP-এর SQL injection প্রতিরোধের নির্দেশিকায় এটাই প্রথম উপায়।

ধাপ ৪: নিজের মেশিনে আক্রমণ চালিয়ে যাচাই করুন

AI-এর কথা মেনে নেওয়ার আগে নিজে দেখুন। নিচের ফাইলটা sqli_demo.py নামে রাখুন। এতে একটা মেমরি-ডেটাবেসে একজন ব্যবহারকারী আছে, যার পিন 4821। দুইটা লগইন ফাংশন: পুরোনো (অনিরাপদ) আর ঠিক করা।

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE users (id INTEGER, phone TEXT, pin TEXT)")
db.execute("INSERT INTO users VALUES (1, '01711000000', '4821')")

def login_unsafe(phone, pin):
    return db.execute(f"SELECT id FROM users WHERE phone = '{phone}' AND pin = '{pin}'").fetchone()

def login_safe(phone, pin):
    return db.execute("SELECT id FROM users WHERE phone = ? AND pin = ?", (phone, pin)).fetchone()

attack = ("01711000000", "' OR '1'='1")
print("unsafe, right PIN:", login_unsafe("01711000000", "4821"))
print("unsafe, attack   :", login_unsafe(*attack))
print("safe,   right PIN:", login_safe("01711000000", "4821"))
print("safe,   attack   :", login_safe(*attack))

চালান python3 sqli_demo.py। আমাদের মেশিনে আসল ফল:

unsafe, right PIN: (1,)
unsafe, attack   : (1,)
safe,   right PIN: (1,)
safe,   attack   : None

দ্বিতীয় লাইনটা দেখুন: পিন না জেনেও ' OR '1'='1 লিখে অনিরাপদ ফাংশনে লগইন হয়ে গেছে। ঠিক করা ফাংশনে একই আক্রমণে ফল None, মানে লগইন হয়নি, অথচ সঠিক পিনে ঠিকই হচ্ছে। এবার AI-এর দাবিটা প্রমাণিত।

ধাপ ৫: AI-এর সমাধানও পরীক্ষা করুন

ইংরেজিতে একই রিভিউ চালালে ChatGPT rate limiting-এর উদাহরণে Flask-Limiter এভাবে লিখেছে (উত্তর থেকে হুবহু):

@limiter.limit("5 per minute")
@app.route("/login", methods=["POST"])
def login():
    ...

দেখতে ঠিক, কিন্তু আমরা নিজের মেশিনে Flask 3.1.3 আর Flask-Limiter 4.1.1 দিয়ে সাতবার লগইনের চেষ্টা চালালাম:

limit-above-route : [200, 200, 200, 200, 200, 200, 200]
route-above-limit : [200, 200, 200, 200, 200, 429, 429]

AI-এর ক্রমে (@limiter.limit উপরে) সাতবারই লগইন চেষ্টা ঢুকে গেছে, মানে কোনো সীমা কাজ করেনি। @app.route সবার উপরে রাখলে ষষ্ঠবার থেকে 429 (অনেক বেশি অনুরোধ) আসে। মজার ব্যাপার, একই উত্তরের শেষের পুরো কোডে ক্রমটা ঠিক ছিল। বাংলা উত্তরে ক্রম শুরু থেকেই ঠিক ছিল।

শিক্ষা: নিরাপত্তার সমাধান “দেখতে ঠিক” হলেই হবে না, চালিয়ে দেখতে হবে যে আক্রমণ সত্যিই আটকাচ্ছে।

ধাপ ৬: AI যা দেখে না

AI শুধু যতটুকু কোড দেখায়, ততটুকু পড়ে। ডেটাবেসে পিন কীভাবে রাখা আছে, সার্ভারে HTTPS আছে কিনা, লগে কী লেখা হয়, এসব সে দেখে না। তাই AI-এর রিভিউ প্রথম ছাঁকনি, শেষ কথা নয়। নিয়মিত টুল (যেমন Python-এর জন্য Bandit) আর মানুষের রিভিউ লাগবেই।

আর রিভিউয়ের জন্য কোড দেওয়ার আগে তার ভেতর থেকে পাসওয়ার্ড, API key আর আসল গ্রাহকের তথ্য সরিয়ে নিন।

AI অ্যাপের নিজের ঝুঁকি

আপনি যদি নিজে AI দিয়ে অ্যাপ বানান (যেমন কাস্টমারের প্রশ্নের উত্তর দেওয়া chatbot), তখন নতুন ধরনের ঝুঁকি আসে। OWASP-এর ২০২৬ সালের LLM তালিকার প্রথম তিনটা:

1. Prompt injection: ব্যবহারকারীর লেখা বা কোনো ওয়েবসাইট আর ফাইলের ভেতরে লুকানো নির্দেশ AI-এর আচরণ বদলে দেয়। OWASP বলছে, এই নির্দেশ মানুষের চোখে না পড়লেও কাজ করতে পারে, আর RAG বা fine-tuning দিয়েও এটা পুরোপুরি ঠেকানো যায় না।
2. Sensitive information disclosure: AI উত্তরে এমন তথ্য বলে ফেলে যা বলার কথা না, যেমন অন্য গ্রাহকের তথ্য।
3. Excessive agency: AI-কে বেশি ক্ষমতা দেওয়া, যেমন নিজে থেকে টাকা ফেরত দেওয়া বা ইমেইল পাঠানো। ভুল নির্দেশে সে সত্যিই সেই কাজ করে ফেলতে পারে।

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

মূল উৎস

• OWASP, SQL Injection Prevention Cheat Sheet: parameterized query প্রথম প্রতিরোধ।
• OWASP GenAI Security Project, Top 10 for LLM Applications 2026 (আগস্ট ২০২৬) আর LLM01 Prompt Injection: AI অ্যাপের ঝুঁকির তালিকা।
• Flask-Limiter, Documentation: ডকুমেন্টেশনের উদাহরণে @app.route উপরে, @limiter.limit তার নিচে।
• GitHub Docs, Best practices for using GitHub Copilot: AI-এর কোড সবসময় যাচাই করা, টেস্ট আর code scanning দিয়ে।