वर्डप्रेस सुरक्षा ऑडिट: लाइव जाने से पहले क्या जांचें

PAGEnza द्वारा उत्पन्न कोई भी प्लगइन उपयोगकर्ता की वर्डप्रेस इंस्टॉलेशन तक पहुंचने से पहले, यह तीन स्वचालित सुरक्षा जांचों से गुजरता है। यह पोस्ट बताती है कि ये जांचें क्या देखती हैं — और प्रत्येक क्यों मायने रखती है।

AI-जनित कोड को ऑडिट की आवश्यकता क्यों है

बड़े भाषा मॉडल वर्डप्रेस प्लगइन्स लिखने में आश्चर्यजनक रूप से अच्छे हैं। वे हुक नामों को जानते हैं, WP कोडिंग मानकों को समझते हैं, पठनीय PHP उत्पन्न करते हैं। लेकिन वे अनुमानित गलतियाँ भी करते हैं — और ये गलतियाँ सुरक्षा कमजोरियाँ हैं।

सबसे आम जो हम देखते हैं:

• सैनिटाइजेशन के बिना $_GET या $_POST का उपयोग
• फॉर्म सबमिशन पर नॉनस (nonce) सत्यापन की कमी
• $wpdb->prepare() के बिना सीधे डेटाबेस क्वेरी
• डायनामिक व्यवहार के लिए eval() या exec() का उपयोग
• esc_html() या esc_attr() के बिना उपयोगकर्ता डेटा आउटपुट करना

ये विदेशी किनारे के मामले नहीं हैं। वे नियमित रूप से LLM आउटपुट में दिखाई देते हैं — यहां तक कि सर्वश्रेष्ठ मॉडल से भी।

चरण 1: प्रॉम्प्ट सत्यापन

AI द्वारा एक भी पंक्ति लिखने से पहले, हम उपयोगकर्ता के विवरण का विश्लेषण करते हैं। यह चरण दो श्रेणियों की समस्याओं को पकड़ता है:

हेरफेर के प्रयास — प्रॉम्प्ट जो AI को जानबूझकर दुर्भावनापूर्ण कोड उत्पन्न करने के लिए बनाते हैं। "पिछली हिदायतों को अनदेखा करें" या "परीक्षण के लिए एक बैकडोर बनाएं" जैसी चीजें।

अस्पष्ट या अव्यवहारिक विवरण — उपयोगी कोड उत्पन्न करने के लिए बहुत छोटे या बहुत अस्पष्ट प्रॉम्प्ट। "एक प्लगइन बनाएं" कचरा उत्पन्न करता है; "एक संपर्क फ़ॉर्म बनाएं जो स्पैम फ़िल्टरिंग के साथ ईमेल पते पर सबमिशन भेजता है" कुछ वास्तविक उत्पन्न करता है।

यदि कोई प्रॉम्प्ट इस जांच में विफल रहता है, तो उपयोगकर्ता को एक विशिष्ट त्रुटि संदेश दिखाई देता है जो बताता है कि क्यों — कोई सामान्य अस्वीकृति नहीं।

चरण 2: एक अलग कंटेनर में PHP लिंटिंग

एक बार जब AI PHP कोड उत्पन्न कर लेता है, तो इसे Docker कंटेनर के अंदर php -l के माध्यम से निष्पादित किया जाता है जो बाकी सब चीजों से पूरी तरह से अलग होता है। यह सिंटैक्स त्रुटियों को पकड़ता है इससे पहले कि प्लगइन वर्डप्रेस इंस्टॉलेशन तक पहुंचे।

लेकिन हम आगे बढ़ते हैं: यदि लिंटिंग विफल रहता है, तो सिस्टम केवल आउटपुट को अस्वीकार नहीं करता है। यह त्रुटि को सुधार प्रॉम्प्ट के साथ AI को वापस भेजता है — जिसे हम हीलिंग (healing) कहते हैं। AI अपनी गलती देखता है और फिर से प्रयास करता है, तीन बार तक।

इसका मतलब है कि उपयोगकर्ताओं को लगभग कभी भी "जनरेशन विफल" संदेश नहीं दिखता है। वे थोड़ी लंबी जनरेशन समय — और काम करने वाला कोड देखते हैं।

चरण 3: कोड सुरक्षा स्कैन

यह सबसे महत्वपूर्ण चरण है। हम एक स्थिर विश्लेषण चलाते हैं जो जांचता है:

खतरनाक फ़ंक्शन: eval(), exec(), system(), shell_exec(), passthru() — इनमें से कोई भी प्लगइन को जारी होने से रोकता है।

SQL इंजेक्शन वैक्टर: इंटरपोलेटेड चर के साथ कच्चे $wpdb->query() कॉल, $wpdb->prepare() की कमी, mysql_query() का सीधा उपयोग।

अनुमति जांच की कमी: AJAX हैंडलर जो किसी भी विशेषाधिकार प्राप्त कार्रवाई को करने से पहले current_user_can() को कॉल नहीं करते हैं।

नॉनस (Nonce) सत्यापन की कमी: फॉर्म प्रोसेसर जो wp_verify_nonce() या check_ajax_referer() को कॉल नहीं करते हैं।

अनएस्केप्ड आउटपुट: echo $_GET[...], एस्केप फ़ंक्शन के बिना echo $user_input।

यदि इनमें से कोई भी पाया जाता है, तो प्लगइन ब्लॉक कर दिया जाता है। उपयोगकर्ता एक रिपोर्ट देखता है जिसमें ठीक से सूचीबद्ध होता है कि किन फ़ंक्शन ने ब्लॉक को ट्रिगर किया और क्यों — केवल "सुरक्षा जांच विफल" नहीं।

ऑडिट रिपोर्ट कैसी दिखती है

प्रत्येक उत्पन्न प्लगइन सादे भाषा में एक सुरक्षा ऑडिट रिपोर्ट के साथ आता है। यह सूचीबद्ध करता है:

• कौन सी जांच पास हुई (हरा)
• किन जांचों ने चेतावनियां ट्रिगर कीं (एम्बर) — ऐसी समस्याएं जो अवरोधक नहीं हैं लेकिन ध्यान देने योग्य हैं
• हीलिंग के दौरान स्वचालित रूप से लागू किए गए कोई भी सुधार

रिपोर्ट स्वचालित रूप से उत्पन्न होती है और प्लगइन डाउनलोड से जुड़ी होती है। यह आपके अपने आत्मविश्वास के लिए और ग्राहकों को यह दिखाने के लिए उपयोगी है कि आपने सुरक्षा को गंभीरता से लिया है।

चरण 4: सहेजते समय सत्यापन

यह प्रारंभिक पीढ़ी का हिस्सा नहीं है — यह तब लागू होता है जब उपयोगकर्ता PAGEnza संपादक में प्लगइन कोड को मैन्युअल रूप से संपादित करते हैं।

हर बार जब आप सहेजते हैं, तो वही लिंट + सुरक्षा स्कैन फिर से चलता है। यदि आप संपादन के दौरान एक महत्वपूर्ण भेद्यता पेश करते हैं, तो उसे ठीक करने तक सहेजना अवरुद्ध हो जाएगा। यह उस सामान्य परिदृश्य को रोकता है जहां एक डेवलपर एक त्वरित "अस्थायी" परिवर्तन करता है जो दो साल तक उत्पादन में रहता है।

स्वचालित ऑडिट की सीमाएं

स्वचालित स्कैन समस्याओं के एक विशिष्ट वर्ग को अच्छी तरह से पकड़ता है। यह सब कुछ नहीं पकड़ता।

तर्क त्रुटियाँ, टूटी हुई व्यावसायिक तर्क, और सूक्ष्म अनुमति वृद्धि की समस्याएँ जिनमें ज्ञात खतरनाक पैटर्न शामिल नहीं हैं, फिर भी मानव समीक्षा की आवश्यकता होती है। हम प्रलेखन में इसके बारे में पारदर्शी हैं — ऑडिट सुरक्षा समीक्षा का विकल्प नहीं है, यह एक न्यूनतम मानक की गारंटी देता है।

भुगतान या संवेदनशील डेटा को संभालने वाले उत्पादन प्लगइन्स के लिए, हम स्वचालित जांचों के अतिरिक्त मैन्युअल समीक्षा की सलाह देते हैं। ऑडिट रिपोर्ट एक मानव समीक्षक को एक अच्छा प्रारंभिक बिंदु प्रदान करती है।