SQL Injection என்றால் என்ன மற்றும் அதை எப்படி தடுக்கலாம்?

SQL injection 1990களின் பிற்பகுதியிலிருந்து இருந்து வருகிறது மற்றும் web applications சமரசம் செய்யப்படும் மிகவும் பொதுவான வழிகளில் இன்னும் ஒன்றாக உள்ளது. கோபு எளிது: ஒரு attacker input அனுப்புகிறார் அது SQL code ஆக interpreted ஆகிறது plain data க்கு பதிலாக, மற்றும் database ஒன்றைச் செய்கிறது அது ஒருபோதும் செய்ய வேண்டியதில்லை.

தாக்குதல் உண்மையில் எப்படி செயல்படுகிறது

துவக்க படிவம் query ஐ இவ்வாறு உருவாக்குவதை கற்பனை செய்யுங்கள் PHP-இல்:

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

ஆப்ப்ஸ் input sanitize செய்யவில்லையென்றால், ஒரு attacker admin' -- username field-ஐ type செய்கிறார். query இது ஆகிறது:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

-- வரியின் மீதிப்பகுதியை comment செய்கிறது, எனவே password check ஒருபோதும் நடக்கவில்லை. அது ஒரு classic auth bypass. Attackers UNION SELECT ஐ பயன்படுத்தி மற்ற tables-இலிருந்து data pull செய்கிறார்கள், அல்லது query stack செய்கிறார்கள் semicolon ஆல் DROP TABLE users; போன்ற destructive எதையாவது run செய்ய driver multiple statements allow என்றால்.

Blind SQL injection உம் உள்ளது, இங்கு app query results directly காட்டாது. Attackers information infer செய்கிறார்கள் timing மூலம் (SLEEP(5) MySQL-இல்) அல்லது boolean responses மூலம் (page மாறுபடுகிறதா true vs. false condition க்கு). Tools like sqlmap vulnerability parameter found என்றவுடன் இந்த extraction type automate செய்கிறது.

ஏன் string concatenation root problem ஆ

இந்த தாக்குதலின் ஒவ்வொரு variant வந்து நின்றுவிடுகிறது ஒன்றுக்கு: code மற்றும் data கலந்து same string-இல். Database distinguish செய்ய முடியாது legitimate value மற்றும் injected syntax க்கு இடையில் ஏனெனில் அவை arrive செய்கிறார்கள் same channel-இல். Escaping quotes சாதகம் சில cases-இல் ஆனால் அது fragile — different encodings, second-order injection (data stored ஒருமுறை, பிறகு reused unsafely பின்னர்), மற்றும் driver-specific quirks அனைத்து create செய்கிறது bypass paths. Escaping ஒரு patch, ஒரு fix அல்ல.

Parameterized queries உண்மையான fix ஆ

Fix separate செய்வது SQL code user data-இலிருந்து driver level-இல், parameterized queries பயன்படுத்தி (also called prepared statements). Database receives செய்கிறது query structure முதல், பிறகு binds values பின்னர், எனவே user input முடியாது change query-ன் meaning.

Python-இல் psycopg2:

cur.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

Node.js-இல் mysql2:

connection.execute('SELECT * FROM users WHERE username = ? AND password = ?', [username, password]);

Java-இல் JDBC:

PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
stmt.setString(1, username);
stmt.setString(2, password);

pattern கவனிக்கவும்: placeholders (%s, ?) hold செய்கிறது spot data க்கு, மற்றும் actual values pass ஆகிறது separately. String concatenation எல்லை, manual escaping தேவை இல்லை. இது வேலை செய்கிறது huge majority queries க்கு நீ write செய்வாய் normal application-இல்.

Dynamic table அல்லது column names பற்றி என்ன?

Parameterization handles செய்கிறது values ஆனால் identifiers இல்லை — நீ bind முடியாது table name ஒரு parameter ஆக. உன் app need செய்தால் dynamically table select செய்ய (rare, மற்றும் often ஒரு design smell), whitelist செய் allowed values against ஒரு hardcoded list க்கு பதிலாக trust user input-ஐ directly:

allowed_tables = {'orders', 'invoices', 'customers'}
if table_name not in allowed_tables:
    raise ValueError("Invalid table")

Never build செய் identifier names string formatting மூலம் user input-இலிருந்து, even with escaping.

Layered defenses query க்கு beyond

Parameterized queries primary control ஆ, ஆனால் சில மற்ற விஷயங்கள் matter செய்கிறது:

• Least privilege database account-இல். App-ன் DB user தேவை இல்லை DROP, ALTER, அல்லது access unrelated schemas க்கு. Injection slip through செய்யும் என்றால், limited privileges cap செய்கிறது damage.
• ORMs help செய்கிறது default ஆக. Django-ன் ORM, SQLAlchemy, மற்றும் Hibernate அனைத்து parameterize செய்கிறது queries automatically நீ use செய்யும் போது அவற்றின் standard query-building methods. Risk reappear செய்கிறது developers drop செய்கிறார்கள் போது raw SQL க்கு அல்லது use செய்கிறார்கள் .extra()/text() calls string interpolation ஆல் — எனவே audit செய் அந்த spots specifically.
• Input validation secondary layer, replacement அல்ல. Checking email field looks like ஒரு email good practice ஆ, ஆனால் அது stop செய்யாது injection on its own — attackers find செய்கிறார்கள் creative payloads அவை still pass loose validation.
• WAF catch செய்ய முடியும் known attack patterns, ஆனால் அது detection layer ஆ, fix underlying code க்கு அல்ல.

உன்னைத் தாமே testing செய்வது இந்த bug க்கு

Run செய் உன்னைத் தாமே queries through static analysis tool (Bandit Python க்கு, Semgrep with SQL injection rulesets) CI-ன் part ஆக. Manual testing க்கு, try செய் inject செய்வது ஒரு single quote (') ஒவ்வொரு input field-க்கு மற்றும் watch SQL error messages leak ஆகிறதா response-இல் — அது often first sign query parameterized இல்லை.

நீ deeper go செய்ய விரும்பினால் இதனை, Korra Studio-ன் Web Security track covers செய்கிறது injection alongside XSS மற்றும் auth bypass, மற்றும் Databases segments walk through செய்கிறது query design patterns avoid செய்கிறது bug class entirely-ஐ.