SaaS OS command injection रोकथाम guide
Language APIs से shell calls बदलें, structured process arguments दें, allowed inputs validate करें और जरूरी external tools को isolate करें—इस तरह SaaS में command और argument injection रोकें।
इस मार्गदर्शिका में
SaaS app में OS command injection कैसे रोकें?
सबसे सुरक्षित सामान्य उपाय है कि request data से operating-system command न बनाएँ और न चलाएँ। जहाँ भाषा की library file, archive, image या network काम कर सकती है, उसका उपयोग करें। अलग process जरूरी हो तो structured process API से fixed executable और argument array दें, हर value को उसके business purpose के अनुसार validate करें और process को सीमित privilege व संसाधनों के साथ चलाएँ। केवल escaping पर्याप्त नहीं हो सकती क्योंकि argument injection का जोखिम रहता है।
Shell command की जगह language library या service API अपनाएँ
Directory बनाने, archive संभालने या image metadata पढ़ने जैसे सामान्य काम built-in functions से करें। Export, report, media conversion, backup, git और diagnostic features में `exec`, `system`, shell scripts या command-line tools खोजें, जिन्हें user-controlled filename, URL या option मिलता हो। Shell boundary कम होंगे तो parsing नियमों की गलती की संभावना घटेगी।
Executable तय रखें और shell के बिना structured arguments दें
Process जरूरी हो तो runtime API से command string जोड़ने के बजाय executable और अलग arguments दें। Executable path तथा security-sensitive flags server के नियंत्रण में हों। अलग argument भी tool का व्यवहार बदल सकता है; जहाँ supported हो option terminator `--` लगाएँ और value को उसी identifier या path तक सीमित करें जिसकी feature को जरूरत है।
Values validate करें और process environment सीमित करें
Business rules से input जाँचें, path canonicalize करें और file access को intended working directory में रखें। Input validation को safe process invocation का विकल्प न मानें। Child process को कम privilege वाला account दें, filesystem और network पहुँच सीमित करें, समय व output पर सीमा रखें और अनावश्यक secrets inherit न होने दें।
| Feature और call site | Process तक पहुँचने वाला input | Library या structured API | Privilege, path और resource limits | Authorized regression test और owner |
|---|---|---|---|---|
| Image या document conversion | ||||
| Archive या export job | ||||
| Support या diagnostic workflow |
यदि product को OS tool चलाना जरूरी हो तो क्या करें?
Command structure और options स्थिर रखें
Executable और supported operation server पर allowlist करें। User को मनमाना command, shell fragment या command-line switch चुनने न दें। Paths को application-controlled root के भीतर validate करें और fixed working directory रखें; जहाँ tool समर्थन करे, user value को option parsing से अलग रखें ताकि filename नया flag न बन जाए।
Platform-specific escaping को केवल fallback सुरक्षा-परत रखें
Shell invocation हटाना संभव न हो तो उस operating system और shell के लिए बनी maintained escaping function उपयोग करें, साथ में input validation और least privilege रखें। Quoting shell metacharacter से दूसरा command चलने रोक सकती है, पर value को उसी program का argument बनने से नहीं रोकती। Custom escaping से बचें और Unix तथा Windows parsing समान न मानें।
Async jobs और उनके output को isolate करें
जोखिमपूर्ण conversion या analysis को सीमित credentials और संसाधन वाले worker में queue करें। Timeout, file-size limit, सुरक्षित temporary directory और output limit रखें; stdout, stderr और generated files को untrusted data मानें। Raw command output customer को न दिखाएँ और संवेदनशील arguments logs में न रखें।
Process execution की समीक्षा और testing कैसे करें?
API, files और jobs से हर process boundary तक data trace करें
Codebase और deployment scripts में shell APIs, process creation, generated scripts और wrappers खोजें। Filename, archive entry, imported record, URL और support value को उसके source से executable path, arguments, environment variables और working directory तक trace करें। Background jobs व scheduled tasks भी शामिल करें जिनमें web controller वाली validation न हो।
Isolated environment में सुरक्षित boundary cases जाँचें
Authorized test values में spaces, Unicode, शुरुआती dash और shell-significant punctuation शामिल करें। पुष्टि करें कि वे data बने रहें और executable, options या paths न बदलें। Rejected input से side effect न हो और worker file, network, time तथा output limits में रहे। विनाशकारी या production testing से बचें।
Tool और runtime upgrades में regression review जोड़ें
External utility versions pin और review करें, गैरज़रूरी tools हटाएँ तथा runtime, framework, container या operating system बदलने के बाद process-boundary tests चलाएँ। हर executable का owner और documented business purpose रखें ताकि नया feature बिना समीक्षा shell path न जोड़े।
OS command-injection के सवाल
क्या shell metacharacters escape करने से command injection पूरी तरह रुकता है?
नहीं। इससे shell command separator रुक सकता है, लेकिन value चुने गए program का unintended argument बन सकती है। Shell से बचें, structured arguments दें और हर value validate करें।
क्या argument array देना हमेशा पर्याप्त है?
Shell के बिना process API उपयोग करने पर shell parsing रुकती है, लेकिन option injection या unsafe file access नहीं। Executable और options नियंत्रित रखें, values validate करें और least privilege अपनाएँ।
क्या file processing worker को सुविधा के लिए root चलाना चाहिए?
नहीं। काम के लिए न्यूनतम privilege दें और files, network, समय तथा संसाधन सीमित करें। Worker के पास व्यापक अधिकार हों तो process flaw का नुकसान बढ़ता है।
क्या uploaded filename converter को सुरक्षित रूप से दे सकते हैं?
केवल सोच-समझकर: server-side generated filename रखें, file को सीमित directory में रखें, fixed tool को structured arguments से चलाएँ और type तथा size validate करें। Filename से command या unrestricted path तय न हो।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .