क्या JavaScript RegExp में ReDoS जोखिम है?

CWE-1333: Inefficient Regular Expression Complexityसंदर्भ पृष्ठ

संक्षिप्त उत्तर

कल्पना करें कि अंतिम निशान न मिलने पर कोई कर्मचारी कागज़ों के ढेर को बाँटने के हर तरीके को आज़माता है: अस्पष्ट pattern regex engine को उन्हीं अक्षरों को बार-बार जाँचने पर मजबूर कर सकता है। V8 का सामान्य RegExp path ऐसा backtrack कर सकता है; input सीमित करने और अनुमानित लागत वाला pattern चुनने से काम सीमित रहता है। Node में synchronous match event-loop thread पर चलता है और उसी process के अन्य callbacks को रोकता है। V8 दस्तावेज़ flags से चालू होने वाले experimental non-backtracking engine का वर्णन करते हैं, जिसकी patterns पर सीमाएँ हैं; production Node में इसके चालू होने की धारणा न रखें।

जोखिमपूर्ण

// Request data पर अस्पष्ट nested repetition
const re = /^(\w+\s?)*$/;

app.post('/search', (req, res) => {
  const q = req.body.q;
  if (!re.test(q)) return res.sendStatus(400);
  res.sendStatus(200);
});

सुधारा गया

// Input सीमित करें और केवल field grammar स्वीकारें
app.post('/search', (req, res) => {
  const q = req.body.q;
  if (typeof q !== 'string' || q.length > 128)
    return res.sendStatus(400);

  // उदाहरण grammar: केवल ASCII word chars और spaces
  if (!/^[\w ]{1,128}$/.test(q))
    return res.sendStatus(400);

  res.sendStatus(200);
});

Node.js में ReDoS का असर क्यों बढ़ता है

Synchronous regex match Node.js process के callbacks संभालने वाले JavaScript thread पर चलता है। यदि pattern लगभग मिलते या विफल input पर देर करे, तो match लौटने तक event loop अन्य callbacks नहीं चला सकता और requests आगे नहीं बढ़तीं। Workers, कई processes या replicas कुछ क्षमता बनाए रख सकते हैं, लेकिन प्रभावित process फिर भी रुक सकता है।

असर reachability, pattern complexity, input limits और deployment topology पर निर्भर करता है। हमलावर को महँगा path सक्रिय करने वाला input vulnerable match तक पहुँचाना होगा। इसे प्रभावित process की availability risk मानें; पूरी service पर असर workers, replicas, routing और health checks पर निर्भर करता है।

npm का वास्तविक मामला: xmldom में CVE-2026-83606

@xmldom/xmldom के reviewed advisory में processing-instruction parsing के लिए CWE-1333 दर्ज है: vulnerable grammar में greedy whitespace group और lazy data group एक ही whitespace खा सकते हैं। Closing ?> न होने पर parser कई partitions आज़माता है और समय quadratic बढ़ता है। 0.9.0-beta.9 से 0.9.10 प्रभावित हैं; 0.9.11 separator को whitespace data group में लौटाने से रोककर इसे ठीक करता है। Advisory समस्या को scoped package के 0.9.x path तक सीमित बताता है; 0.8.x और unscoped package को प्रभावित नहीं बताता।

Dependency scan मदद करता है, पर regex सुरक्षा का प्रमाण नहीं

npm audit project dependency tree से मेल खाने वाले ज्ञात advisories दिखाता है; यह source की हर regex जाँचता या अप्रकाशित ReDoS खोजता नहीं है। Direct और transitive dependencies अपडेट रखें, प्रभावित call paths देखें और user-controlled text संसाधित करने वाले patterns की अलग समीक्षा करें।

npm audit --omit=dev

Audit ज्ञात advisories को कवर करता है, हर regex risk को नहीं। Deployment के संदर्भ में report देखें और अलग से जाँचें कि untrusted input costly match तक पहुँचता है या नहीं तथा उसकी लंबाई सीमित है या नहीं।

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

क्या JavaScript regex पर timeout लगा सकते हैं?

RegExp API में हर match का timeout विकल्प नहीं है। सरल pattern चुनें और match से पहले input सीमित करें। जटिल matching आवश्यक हो तो enforceable termination deadline वाले worker या child process में अलग रखें; इससे असर सीमित होगा, pattern efficient नहीं बनेगा।

क्या browser JavaScript भी प्रभावित होता है?

हाँ। खराब synchronous match लौटने तक page के main thread को freeze करके UI रोक सकता है। Input सीमित करें, pattern सरल रखें और हर keystroke पर महँगा match न चलाएँ।

क्या search में new RegExp(userInput) सुरक्षित है?

User-provided patterns को संभावित महँगे matcher के लिए executable input मानें। Strict limits और isolation के बिना server पर arbitrary patterns स्वीकार न करें। केवल literal search चाहिए तो input को regex literal की तरह escape करें या string-search APIs इस्तेमाल करें; escaping size limit का विकल्प नहीं है।

संदर्भ और सुधार

यह भी देखें ReDoS (catastrophic backtracking) क्या है?