मॉड्यूल 17 · सिक्योरिटी टेस्टिंग

इंजेक्शन टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 18 मिनट · मध्यम

Injection एक security defect है जहाँ untrusted input किसी ऐसी जगह पहुँच जाता है जो उसे interpret करती है — SQL query, operating-system command, LDAP filter, XPath expression या template — और input का एक हिस्सा data की तरह न मानकर code की तरह चल जाता है। क्लासिक उदाहरण: login field की value सीधे SQL query में चिपका दी जाए, तो ' OR '1'='1 जैसी value email पता रहना बंद करके query के logic का हिस्सा बन जाती है।

Injection testing यह जाँचना है कि interpreter तक पहुँचने वाले inputs अपने आसपास के code से अलग रखे गए हैं या नहीं — और यह सिर्फ़ उसी system पर जो आपका है या जिसे टेस्ट करने की written permission आपके पास है। आप सोच-समझकर चुने गए, non-destructive inputs भेजते हैं और देखते हैं कि system कैसे प्रतिक्रिया देता है। यह पाठ server-side interpreters को कवर करता है; browser में injection (cross-site scripting) अगला पाठ है।

यह क्यों ज़रूरी है

Injection सालों से OWASP Top 10 web application security risks में रहा है, क्योंकि यह ग़लती करना आसान है और नतीजे गंभीर: एक unparameterised query किसी table की हर row उजागर कर सकती है, login bypass करा सकती है, या data बिगाड़ सकती है। यह defect सामान्य उपयोग में अदृश्य रहता है — आम input पर feature बढ़िया चलता है — इसलिए तब तक टिका रहता है जब तक कोई ऐसा input न भेजे जिसकी developer ने उम्मीद नहीं की थी।

Tester के लिए injection ऊँची-value का काम है। Probes सस्ते हैं, interpreter तक पहुँचने वाले हर input पर एक दोहराने-योग्य pattern से चलते हैं, और पुष्टि हुई finding आम तौर पर जल्दी ठीक होती है क्योंकि इलाज अच्छी तरह समझा हुआ है। Release से पहले एक injection point पकड़ना production में हुई breach से कहीं सस्ता है।

Injection कहाँ होता है

हर injection का आकार एक जैसा है: user का data किसी interpreter के command के साथ जुड़ जाता है, और interpreter यह नहीं बता सकता कि कौन-सा हिस्सा data होना था। जहाँ भी application text से कोई command बनाती है, वहाँ एक candidate है — और interpreter का database होना ज़रूरी नहीं।

  • SQL injection: input किसी database query तक पहुँचता है। अकेली single quote ' एक metacharacter है — ऐसा character जिसका interpreter के लिए ख़ास मतलब होता है, यहाँ text value का अंत — और यह अक्सर database error उठाती है, जो पहला संकेत है कि input SQL की तरह parse हो रहा है।
  • OS command injection: input किसी shell command तक पहुँचता है, जैसे वह file name जिसे application अपने चलाए जाने वाले command में जोड़ देती है। Shell metacharacters जैसे ;, | और & बदल सकते हैं कि क्या चलेगा।
  • LDAP, XPath और NoSQL injection: input किसी directory filter, XML query या document-database query तक पहुँचता है, हर एक के अपने syntax और special characters के साथ।
  • Server-side template injection: input किसी template engine तक पहुँचता है जो expressions evaluate करता है, और एक profile name को चलने वाले code में बदल सकता है।
  • Field के नाम से ज़्यादा reach मायने रखती है: URL, header, cookie या uploaded file से आई value भी interpreter तक उतनी ही पहुँच सकती है जितनी एक form field।

आज़माएँ: टेस्ट सिनेरियो जनरेटर

Safely probe करना

सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की written permission आपके पास है, और वही सबसे हल्का input चुनें जो सवाल का जवाब दे। मक़सद यह जानना है कि input code की तरह parse होता है या नहीं, नुकसान पहुँचाना नहीं — इसलिए ऐसे payloads कभी इस्तेमाल न करें जो data delete, बदलें या पढ़ निकालें।

सबसे सुरक्षित पहला probe अकेला एक metacharacter है। अगर ' से database error, stack trace या बदला हुआ result मिलता है जबकि सामान्य value से नहीं, तो input बिना सुरक्षा के interpreter तक पहुँच रहा है — defect उठाने के लिए इतना काफ़ी। फिर आप एक हानिरहित तुलना से पुष्टि करते हैं और इससे आगे नहीं जाते: दो quotes '' भेजने पर error ग़ायब हो जाना चाहिए, क्योंकि text value के अंदर SQL इन्हें एक literal quote की तरह पढ़ता है; या किसी सामान्य value में AND से जोड़ी गई हमेशा-सच शर्त सामान्य result लौटाए, जबकि उसी value के साथ हमेशा-झूठ शर्त कुछ न लौटाए।

  • Metacharacters को संकेत की तरह इस्तेमाल करें: SQL के लिए ', ", ;, --; shells के लिए ;, |, &; LDAP के लिए *, (, )।
  • Differential देखें: benign और crafted input के बीच database error, बदला हुआ response, लंबा delay या अलग row count ही सबूत है।
  • हर channel टेस्ट करें, उन inputs समेत जिन्हें UI छिपा देता है, क्योंकि screen पर validation server की रक्षा नहीं करता।
  • Destructive या data पढ़ने वाली exploit chains कभी न चलाएँ; input के interpret होने के सबूत पर रुक जाएँ।

आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

Worked example: parameterised queries ही fix हैं

ऐसे customer lookup पर सोचें जो users को email से ढूँढता है। Vulnerable version strings जोड़कर query बनाता है, इसलिए input SQL text के अंदर जा गिरता है। Fix है एक parameterised query (जिसे prepared statement भी कहते हैं): query text तय रहता है और input database को अलग से भेजा जाता है, एक ऐसी value के रूप में जो query की structure कभी नहीं बदल सकती।

Input validation और escaping मदद करते हैं, पर वे injection का fix नहीं हैं: fix पिछले पाठ की output contexts वाली table की SQL row है, यानी parameterised query। Valid data में भी metacharacters हो सकते हैं: surname O'Brien में apostrophe है, इसलिए validation उन्हें reject नहीं कर सकता। इस पाठ के server-side interpreters के लिए इन characters की escaping सिर्फ़ आख़िरी उपाय है: हर interpreter के अपने special characters होते हैं, और एक भी छूटा character छेद फिर खोल देता है। Parameterisation से data और code अलग रखना ही असल में छेद बंद करता है। Query का जो हिस्सा bind नहीं हो सकता, जैसे sorting के लिए चुना गया column name, उसे names की एक तय allow-list से जाँचना ज़रूरी है, और least-privilege database accounts नुकसान सीमित करते हैं अगर कोई injection point छूट जाए।

String-built query input को SQL में code की तरह चिपकाता है, इसलिए एक single quote उसे तोड़ देता है; parameterised query input को अलग value के रूप में भेजता है, इसलिए वही quote सिर्फ़ data रहता है।

String-built queryVulnerable

Input को query text में जोड़ा जाता है

sql = "... WHERE email = '" + input + "'"

Input कैसे इस्तेमाल होता है:
Query text में चिपकाया जाता है, इसलिए code बन सकता है
Input में single quote ':
SQL टूटता है — database error या बदले हुए resultsफ़ेल
Test क्या दिखाता है:
रिपोर्ट करने योग्य defect: input SQL की तरह parse होता है

Parameterised querySafe

Query text तय; input bound किया जाता है

sql = "... WHERE email = ?"; params = [ input ]

Input कैसे इस्तेमाल होता है:
Database को अलग value के रूप में भेजा जाता है, कभी code नहीं
Input में single quote ':
आम character की तरह compare; कोई error नहींपास
Test क्या दिखाता है:
Input data माना गया; injection बंद
पाठ संस्करण
-- Vulnerable: input is pasted into the SQL text, so it can act as code
sql = "SELECT * FROM users WHERE email = '" + input + "'"

  input = ben@shop.test   ->  ... WHERE email = 'ben@shop.test'
  input = ' OR '1'='1     ->  ... WHERE email = '' OR '1'='1'   (logic changed)

-- Safe: the query text is fixed; input is bound as a separate value
sql    = "SELECT * FROM users WHERE email = ?"
params = [ input ]

  input = ' OR '1'='1     ->  compared as text; matches no row

आज़माएँ: SQL क्वेरी वैलिडेटर

क्या रिपोर्ट करें

अच्छी injection report से developer बिना अंदाज़ा लगाए defect reproduce और fix कर पाता है। सही endpoint और parameter, जो input आपने भेजा, वह response जो साबित करे कि input interpret हुआ, और एक benign input का response control के रूप में — सब नाम लेकर लिखें। Impact यह बताकर लिखें कि interpreter किस चीज़ पर नियंत्रण रखता है, और fix की सिफ़ारिश करें।

  • Location: URL या screen, HTTP method, और सही parameter, field, header या cookie।
  • Input और सबूत: जो characters आपने भेजे वे ठीक-ठीक और देखा गया नतीजा — error text, differential behaviour या status code — साथ में तुलना के लिए एक benign input।
  • Impact और severity: प्रभावित interpreter किस चीज़ पर नियंत्रण रखता है (authentication, कोई data table, एक shell), team की severity scale पर आँका गया।
  • Fix: parameterised queries या interpreter का safe API, और defence in depth के रूप में validation व least privilege।
  • Scope: लिखें कि आपने सिर्फ़ authorised system टेस्ट किया और सबूत पर रुक गए, ताकि पढ़ने वाला जान ले कि किसी data को छुआ नहीं गया।

आज़माएँ: API रिक्वेस्ट बिल्डर

आम गलतियाँ

  • सिर्फ़ UI के दिखाए fields टेस्ट करना, या पहले vulnerable field पर रुक जाना, बजाय interpreter तक पहुँचने वाले हर input को जाँचने के — headers, cookies, URL parameters और API-only inputs समेत।
  • Input validation या escaping को fix मानना; ये मदद करते हैं, पर SQL injection रोकता है parameterisation, और escaping सिर्फ़ आख़िरी उपाय है।
  • Destructive payloads चलाना। Injection साबित करने के लिए tester को कभी data delete या पढ़ने की ज़रूरत नहीं; सबसे हल्का probe काफ़ी है।
  • ऐसा system टेस्ट करना जो आपका नहीं और जिसे टेस्ट करने की written permission आपके पास नहीं।
  • "SQL injection found" रिपोर्ट करना बिना endpoint, बिना input और बिना सबूत के, जिससे developer उसे reproduce नहीं कर सकता।
  • यह मान लेना कि सिर्फ़ SQL मायने रखता है और OS command, LDAP, XPath व template injection चूक जाना।

QA का नज़रिया

Team में injection testing requirements और design review से ही शुरू होती है: जहाँ-जहाँ application input से query या command बनाती है, वह लिखे जाने से पहले flag करने लायक risk है, और "क्या यह parameterised है?" सवाल code review में आता है। Testing के दौरान आप interpreters तक पहुँचने वाले inputs की एक checklist से काम करते हैं, हर एक पर वही safe probes चलाते हैं, और हर crafted input के लिए एक benign control रखते हैं ताकि आपका सबूत साफ़ रहे।

आप developers के साथ, और बड़े systems में security team के साथ coordinate करते हैं: लिखित में तय करें कि आप क्या और कब टेस्ट कर सकते हैं, least-privilege accounts वाले non-production environment का इस्तेमाल करें, और पुष्टि हुई finding reproduction steps व fix सिफ़ारिश के साथ सौंपें। जो टेस्ट किया और जो जानबूझकर नहीं किया, दोनों दर्ज करें, ताकि अगला tester और auditor scope देख सकें।

अभ्यास

एक vulnerable search को safe बनाएँ और रिपोर्ट करें

आपका काम

एक product-search endpoint GET /api/products?q=<term> अपनी query application code में strings जोड़कर ऐसे बनाता है: "SELECT * FROM products WHERE name LIKE '%" + q + "%'"। अपने एक test system पर आप q को single quote के साथ भेजते हैं और database error मिलता है; सामान्य term results लौटाता है। Injection point पहचानें, एक safe confirming probe चुनें, fix से पहले और बाद के अपेक्षित behaviour का वर्णन करें, और defect report का draft लिखें।

चरण
  1. Interpreter और सही input channel का नाम लें।
  2. सबसे हल्का probe लिखें जो पुष्टि करे कि input SQL की तरह parse होता है, और एक benign control।
  3. Query का parameterised version लिखें, और fix के बाद अपेक्षित behaviour।
  4. Report का draft: location, input, सबूत, impact, severity और fix।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Interpreter: SQL database। Channel: GET /api/products का q query-string parameter।

Probe: q की value के रूप में एक single quote ' database error देता है; control: pen जैसा सामान्य term सामान्य list लौटाता है। Confirming probe: दो quotes '', जिन्हें SQL text value के अंदर एक literal quote पढ़ता है, error ग़ायब कर देते हैं। Quotes की गिनती के साथ आता-जाता error सबूत है कि q SQL की तरह parse होता है; किसी destructive या data पढ़ने वाले payload की ज़रूरत नहीं।

Parameterised: SELECT * FROM products WHERE name LIKE ? bound value %pen% के साथ (% signs application value में जोड़ती है, SQL text में नहीं), ताकि term एक value रहे, query text का हिस्सा नहीं। Fix के बाद q=pen अब भी pens लौटाता है, और ' बिना database error के एक सामान्य result लौटाता है (वे products जिनके नाम में apostrophe है, आम तौर पर कोई नहीं)।

Report: Location GET /api/products, parameter q। Input: एक ', '' से पुष्टि की गई। सबूत: ' पर database error (message quote करें), '' पर कोई error नहीं, और q=pen पर सामान्य list। Impact: search query injectable है, इसलिए products का और संभवतः उन दूसरी tables का data उजागर है जिन्हें database account पढ़ सकता है; team की severity scale पर आँकें (आम तौर पर critical या blocker)। Fix: parameterised query इस्तेमाल करें; least-privilege database accounts जोड़ें और input validation को defence in depth के रूप में रखें। Scope: सिर्फ़ अपने test system पर टेस्ट किया और सबूत पर रुक गए; किसी data को बदला या निकाला नहीं गया।

अक्सर पूछे जाने वाले सवाल

क्या injection testing और penetration testing एक ही हैं?

नहीं। Penetration testing किसी विशेषज्ञ द्वारा पूरे system पर एक व्यापक, आम तौर पर time-boxed authorised हमला है। Injection testing एक केंद्रित security जाँच है जिसे कोई भी tester विशिष्ट inputs पर चला सकता है। दोनों को permission चाहिए; injection testing सामान्य test design में स्वाभाविक रूप से फ़िट होती है।

क्या SQL injection टेस्ट करने के लिए SQL आना ज़रूरी है?

थोड़ा-सा queries पढ़ने और यह समझने में मदद करता है कि probe क्यों काम करता है, पर कई injection points सिर्फ़ behaviour से पुष्टि हो जाते हैं: एक metacharacter जो error उठाए या result बदले जहाँ सामान्य value नहीं बदलती। ‘टेस्टर्स के लिए SQL’ guide इसमें गहराई से जाती है।

Injection रोकने के लिए validation काफ़ी क्यों नहीं?

Validation तय करता है कि कौन-सा input स्वीकार हो, पर valid data में भी metacharacters हो सकते हैं — O'Brien नाम में apostrophe है — और नियम bypass या भुलाए जा सकते हैं। इन characters की escaping सिर्फ़ आख़िरी उपाय है; parameterised queries से data को code से अलग रखना vulnerability को उसके स्रोत पर हटा देता है।

Injection defect को कौन-सी severity दें?

यह इस पर निर्भर है कि interpreter किस चीज़ पर नियंत्रण रखता है और authentication या sensitive data पहुँच में है या नहीं, पर production-bound query में पुष्टि हुआ injection आम तौर पर critical या blocker होता है। अंदाज़ा लगाने के बजाय अपनी team की severity scale पर तर्क दर्ज करें।

संदर्भ

  • OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
  • OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
  • OWASP Cheat Sheet Series: SQL Injection PreventionOWASP Foundationपैरामीटराइज़्ड क्वेरी, सुरक्षित रूप से इस्तेमाल stored procedure, allow-list वैलिडेशन और least privilege — वे बचाव जिन्हें डेटाबेस टेस्ट को पुष्ट करना चाहिए।
  • OWASP Cheat Sheet Series: Injection PreventionOWASP Foundationपैरामीटराइज़ेशन, वैलिडेशन और एस्केपिंग से SQL, OS-कमांड और अन्य इंजेक्शन की रोकथाम।
टूल्स

Mutqan tools से अभ्यास करें

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

टेस्ट डिज़ाइन

SQL क्वेरी वैलिडेटर

SQL स्टेटमेंट में सिंटैक्स की समस्याएँ, असंतुलित कोष्ठक, बिना बंद की स्ट्रिंग और जोखिम भरे पैटर्न जाँचें।

डेटाबेस

टेस्ट सिनेरियो जनरेटर

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

API रिक्वेस्ट बिल्डर

HTTP रिक्वेस्ट (method, URL, हेडर, auth, बॉडी) बनाएँ और भेजें, फिर रिस्पॉन्स जाँचें — आपके ब्राउज़र में हल्का-फुल्का Postman।

API टेस्टिंग

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा