सारांश: A Cross‑Site Request Forgery (CSRF) vulnerability (CVE‑2026‑4068) was disclosed in the “Add Custom Fields to Media” WordPress plugin, affecting versions up to 2.0.3 and fixed in 2.0.4. This article explains the technical details, real-world impact, detection and mitigation steps, incident response guidance, and general protective measures from a Hong Kong security practitioner’s perspective.

पृष्ठभूमि: क्या रिपोर्ट किया गया था

A CSRF vulnerability was reported in the “Add Custom Fields to Media” plugin (versions ≤ 2.0.3) that allowed a remote attacker to trigger the deletion of custom fields by exploiting an endpoint that accepted a हटाएँ प्लगइन विक्रेता ने एक पैच किया हुआ संस्करण (2.0.4) जारी किया है जो इस समस्या को संबोधित करता है।.

उच्च स्तर पर, समस्या CSRF सुरक्षा की कमी या अपर्याप्त सुरक्षा और उन क्रियाओं के चारों ओर अपर्याप्त क्षमता/अधिकार जांच से उत्पन्न होती है जो मीडिया आइटम के लिए संग्रहीत मेटाडेटा को संशोधित करती हैं। जिस तरह से प्लगइन को एक साइट पर कॉन्फ़िगर किया गया था, उसके आधार पर, एक हमलावर जो एक लॉगिन किए हुए प्रशासनिक उपयोगकर्ता को एक तैयार URL पर जाने के लिए धोखा दे सकता है, महत्वपूर्ण साइट डेटा के हटाने का कारण बन सकता है।.

CVE पहचानकर्ता: CVE‑2026‑4068
पैच किया गया: प्लगइन संस्करण 2.0.4
गंभीरता: कम (CVSS 4.3) — लेकिन संदर्भ महत्वपूर्ण है।.

यह वर्डप्रेस साइट के मालिकों के लिए क्यों महत्वपूर्ण है

CSRF सुरक्षा दोष गंभीर होते हैं क्योंकि वे हमलावरों को वैध, प्रमाणित उपयोगकर्ताओं (अक्सर प्रशासकों या संपादकों) को उन क्रियाओं को करने के लिए मजबूर करने की अनुमति देते हैं जिनका वे इरादा नहीं रखते। भले ही क्रिया छोटी प्रतीत होती हो — एक कस्टम फ़ील्ड को हटाना — इसके परिणाम महत्वपूर्ण हो सकते हैं:

• मीडिया आइटम के लिए खोई हुई मेटाडेटा और कॉन्फ़िगरेशन (टूटे हुए गैलरी, खोई हुई उत्पाद डेटा, टूटे हुए SEO मार्कअप)।.
• साइट की कार्यक्षमता में कमी (थीम या प्लगइन जो मेटाडेटा पर निर्भर करते हैं, टूट सकते हैं)।.
• खोए हुए डेटा को पुनर्प्राप्त करने और बहाल करने में समय और लागत।.
• अन्य सुरक्षा दोषों के साथ संभावित चेनिंग (एक बार डेटा बदलने के बाद, अन्य जांचों को बायपास किया जा सकता है)।.
• प्रभावित साइट चलाने वाले व्यवसायों या संगठनों के लिए विश्वास और प्रतिष्ठा को नुकसान।.

जबकि CVSS स्कोर इसे “कम” के रूप में वर्गीकृत करता है क्योंकि हमले के लिए उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है और प्रभाव केवल मेटाडेटा हेरफेर तक सीमित है न कि दूरस्थ कोड निष्पादन तक, CSRF अक्सर बड़े अभियानों में एक वेक्टर के रूप में उपयोग किया जाता है। इससे समय पर शमन करना समझदारी है।.

तकनीकी सारांश (क्या गलत हो सकता है)

• एक क्रिया हैंडलर को उजागर करता है जो एक पैरामीटर को स्वीकार करता है हटाएँ एक मीडिया आइटम के लिए कस्टम फ़ील्ड को हटाने के लिए।.
• हटाने के संचालन के लिए एक मान्य वर्डप्रेस नॉन्स को लागू नहीं करता है और/या सर्वर-साइड क्षमता जांच की कमी है।.
• संभवतः हटाएँ पैरामीटर को GET या एक असुरक्षित POST के माध्यम से स्वीकार करता है, जिससे एक URL तैयार करना सरल हो जाता है जो, यदि एक प्रमाणित उपयोगकर्ता द्वारा देखा जाता है, तो हटाने का कार्य करेगा।.

1. मुख्य तकनीकी विफलताएँ हैं:

• 2. कोई नॉनस सत्यापन नहीं (या गलत सत्यापन)।.
• 3. कोई या अपर्याप्त क्षमता जांच नहीं (जैसे, उपयुक्त मीडिया क्षमता की जांच नहीं करना)। current_user_can() 4. स्थिति-परिवर्तन ऑपरेशन के लिए GET का उपयोग करना (नॉनस और क्षमता जांच के साथ POST का उपयोग करना चाहिए)।.
• 5. शोषण मॉडल - एक हमलावर इसको कैसे दुरुपयोग कर सकता है।.

6. सामान्य CSRF शोषण प्रवाह:

7. हमलावर एक दुर्भावनापूर्ण URL तैयार करता है जिसमें कमजोर पैरामीटर शामिल होता है और प्लगइन द्वारा उपयोग किए जाने वाले विशिष्ट एंडपॉइंट को लक्षित करता है (उदाहरण के लिए एक प्लगइन प्रशासन पृष्ठ या एक AJAX क्रिया)।

1. 8. हमलावर URL को एक पृष्ठ पर होस्ट करता है जिसे वह नियंत्रित करता है या इसे ईमेल/सोशल चैनलों के माध्यम से भेजता है (फिशिंग)। हटाएँ 9. एक लॉगिन किया हुआ प्रशासक/संपादक दुर्भावनापूर्ण पृष्ठ पर जाता है (अक्सर एक लिंक पर क्लिक करके या एक छवि लोड करके)।.
2. 10. पीड़ित का ब्राउज़र स्वचालित रूप से अनुरोध के साथ उनके प्रमाणीकरण कुकीज़ भेजता है, प्लगइन हैंडलर को निष्पादित करता है, और कस्टम फ़ील्ड हटा दिए जाते हैं।.
3. 11. नोट: हमले के लिए पीड़ित का लॉगिन होना और उस क्रिया के लिए आवश्यक क्षमता होना आवश्यक है। यदि प्लगइन में अतिरिक्त क्षमता जांच की कमी थी, तो हमला बिना विशेषाधिकार प्राप्त उपयोगकर्ता के किया जा सकता था - जो कि बहुत अधिक गंभीर होगा।.
4. 12. "मीडिया में कस्टम फ़ील्ड जोड़ें" को संस्करण 2.0.4 या बाद में अपडेट करें। यह सबसे सरल और सबसे प्रभावी कदम है।.

13. संभव हो तो wp-admin तक पहुँच को विश्वसनीय IPs तक सीमित करें।.

यदि आप प्लगइन का उपयोग करते हैं तो तात्कालिक कदम

1. तुरंत अपडेट करें
   • Update “Add Custom Fields to Media” to version 2.0.4 or later. This is the single simplest and most effective step.
2. यदि आप तुरंत अपडेट नहीं कर सकते
   • जब तक आप अपडेट नहीं कर सकते, प्लगइन को निष्क्रिय करें।.
   • 15. प्रशासनिक सत्रों को सीमित करें और उच्च विशेषाधिकार वाले उपयोगकर्ताओं की संख्या को कम करें।.
   • 16. एक वेब एप्लिकेशन फ़ायरवॉल (WAF) का उपयोग करें।.
   • 17. शोषण के पैटर्न से मेल खाने वाले अनुरोधों को अवरुद्ध करने के लिए WAF नियम लागू करें (बाद में उदाहरण देखें)।.
3. 18. यदि आपके पास आभासी पैचिंग क्षमता है (एक WAF जो कमजोर अनुरोध पैटर्न को अवरुद्ध कर सकता है), तो इसे सक्षम करें जब तक आप प्लगइन को अपडेट नहीं कर लेते।
   • एक WAF नियम लागू करें जो उन अनुरोधों को ब्लॉक करे जो शोषण के पैटर्न से मेल खाते हैं (बाद में उदाहरण देखें)।.
   • यदि आपके पास वर्चुअल पैचिंग क्षमता है (एक WAF जो कमजोर अनुरोध पैटर्न को ब्लॉक कर सकता है), तो इसे सक्षम करें जब तक आप प्लगइन को अपडेट नहीं कर लेते।.
4. बैकअप की पुष्टि करें
   • सुनिश्चित करें कि आपके पास एक हालिया बैकअप है और कि बैकअप को पुनर्स्थापित किया जा सकता है। यदि कस्टम फ़ील्ड अप्रत्याशित रूप से गायब हैं, तो एक साफ बैकअप से पुनर्स्थापित करें।.

यह कैसे पता करें कि आपकी साइट को लक्षित किया गया था या प्रभावित हुई थी

पहचान लॉग, साइट पर जांच और डेटाबेस क्वेरी में विभाजित है।.

1. एक्सेस लॉग

अपने वेब सर्वर एक्सेस लॉग में प्लगइन प्रशासन पृष्ठों या प्रशासन-ajax एंडपॉइंट्स के लिए अनुरोधों की खोज करें जिसमें एक हटाएँ पैरामीटर या संदिग्ध क्वेरी स्ट्रिंग्स शामिल हैं जो सलाह जारी होने की तारीख के आसपास हैं।.

grep -i "delete=" /var/log/nginx/access.log | grep -i "add-custom-fields-to-media"

2. वर्डप्रेस गतिविधि लॉग

यदि आपके पास एक गतिविधि लॉग प्लगइन है, तो उन घटनाओं की जांच करें जो पोस्ट मेटा/अटैचमेंट मेटा या प्लगइन से जुड़े विशिष्ट मेटा कुंजियों को हटा देती हैं।.

3. डेटाबेस जांच

SQL का उपयोग करके गायब या हाल ही में हटाए गए रिकॉर्ड की खोज करें wp_postmeta:

SELECT post_id, meta_key, meta_value;

बाइनरी लॉग या डेटाबेस लेनदेन इतिहास को क्वेरी करके हटाने की खोज करें यदि समर्थित हो।.

4. File system & configuration

नए फ़ाइलों, संशोधित फ़ाइलों, या अप्रत्याशित अनुसूचित कार्यों (wp-cron प्रविष्टियाँ) की जांच करें। हमलावर कभी-कभी कम गंभीर दोष का शोषण करने के बाद बैकडोर या स्थिरता जोड़ते हैं।.

5. अखंडता स्कैनिंग

यह सुनिश्चित करने के लिए एक मैलवेयर स्कैन और फ़ाइल अखंडता जांच चलाएँ कि कोई दुर्भावनापूर्ण फ़ाइलें या संशोधन मौजूद नहीं हैं।.

पुनर्प्राप्ति और घटना प्रतिक्रिया कदम (यदि आप प्रभावित हुए थे)

1. सीमित करें
   • असुरक्षित प्लगइन को अस्थायी रूप से निष्क्रिय करें।.
   • वर्डप्रेस प्रशासन क्षेत्र तक पहुँच को प्रतिबंधित करें (IP अनुमति सूची, नए लॉगिन को निष्क्रिय करें)।.
   • यदि आवश्यक हो तो साइट को रखरखाव मोड में डालें।.
2. साक्ष्य को संरक्षित करें
   • वर्तमान स्थिति (फाइलें + डेटाबेस) का पूरा बैकअप लें। यह फोरेंसिक विश्लेषण के लिए महत्वपूर्ण है।.
3. दायरा पहचानें
   • उपरोक्त पहचान चरणों का उपयोग करें यह निर्धारित करने के लिए कि कौन से आइटम ने मेटाडेटा खो दिया और क्या कोई अन्य परिवर्तन हुआ।.
4. डेटा पुनर्स्थापित करें
   • यदि आपके पास हाल का बैकअप है, तो प्रभावित तालिका (जैसे, wp_postmeta) को पुनर्स्थापित करने पर विचार करें ताकि हाल के डेटा को ओवरराइट करने से बचा जा सके। यदि आपको सहायता की आवश्यकता हो तो अपने होस्ट के साथ काम करें।.
   • यदि पूरे साइट को पुनर्स्थापित कर रहे हैं, तो सत्यापित करें कि पुनर्स्थापित स्थिति साफ है।.
5. सुधार करें
   • प्लगइन को 2.0.4 या बाद के संस्करण में अपडेट करें।.
   • प्रमाणीकरण को मजबूत करें: व्यवस्थापक पासवर्ड रीसेट करें और मजबूत पासवर्ड लागू करें, 2FA सक्षम करें, और यदि कोई हो तो API कुंजी को घुमाएं।.
   • उपयोगकर्ताओं का ऑडिट करें और किसी भी अप्रयुक्त प्रशासनिक खातों को हटा दें।.
6. स्कैन और सत्यापित करें
   • सुनिश्चित करने के लिए सुधार के बाद पूर्ण मैलवेयर और अखंडता स्कैन करें कि कोई अतिरिक्त समझौता नहीं हुआ।.
7. निगरानी करें
   • साइट की निगरानी करें कि बार-बार पहुंच के प्रयास, असामान्य लॉगिन, या नए संदिग्ध फ़ाइलें हैं।.

WAF / वर्चुअल पैचिंग उदाहरण

यदि आप तुरंत हर प्रभावित साइट को अपडेट नहीं कर सकते हैं, तो WAF एक त्वरित वर्चुअल पैच प्रदान कर सकता है। नीचे आपके वेब एप्लिकेशन फ़ायरवॉल या सर्वर में लागू करने के लिए उदाहरण हस्ताक्षर और नियम दिए गए हैं। ये सामान्य उदाहरण हैं; इन्हें आपकी साइट पर सटीक अनुरोध पैटर्न और प्लगइन पथ के अनुसार अनुकूलित करें।.

उदाहरण 1 — संदिग्ध प्लगइन एंडपॉइंट्स पर हटाने वाले पैरामीटर वाले GET अनुरोधों को ब्लॉक करें (Nginx के साथ ModSecurity या कस्टम नियम)

ModSecurity नियम (संकल्पना):

SecRule REQUEST_METHOD "GET" "chain,deny,status:403,msg:'GET के माध्यम से प्लगइन हटाने वाले पैरामीटर को ब्लॉक करें'"

Nginx स्थान ब्लॉक (संदिग्ध क्वेरी को अस्वीकार करें):

if ($query_string ~* "delete=") {

उदाहरण 2 — POST + nonce-जैसे हेडर की आवश्यकता (Cloudflare Workers / कस्टम WAF छद्मकोड)

किसी भी अनुरोध को अस्वीकार करें जो एक कस्टम फ़ील्ड को हटाने का प्रयास करता है जब तक कि यह एक वैध nonce हेडर के साथ POST न हो या व्यवस्थापक मूल से न आए।.

उदाहरण 3 — admin‑ajax में सामान्य शोषण पैटर्न को ब्लॉक करें

SecRule REQUEST_URI "@contains admin-ajax.php" "chain,deny,status:403"

नोट्स:

• वैध प्रशासन कार्यप्रवाह को अनजाने में ब्लॉक न करें; पहले “detect” मोड में नियमों का परीक्षण करें।.
• आदर्श रूप से WAF एक मान्य WP nonce की उपस्थिति की जांच करता है (यदि आपके WAF में इसे सत्यापित करने की क्षमता है) या उन GET अनुरोधों को ब्लॉक करता है जो स्थिति परिवर्तन को ट्रिगर करते हैं।.

हार्डनिंग सिफारिशें (तत्काल पैच के परे)

कमजोरियों को संबोधित करना एक बात है; समान समस्याओं को रोकना दूसरी बात है। यहां कठोर प्रथाएं हैं जिन्हें हर WordPress साइट के मालिक को अपनाना चाहिए।.

1. सब कुछ अद्यतित रखें
   • WordPress कोर, थीम, और प्लगइन्स — जैसे ही संभव हो अपडेट करें, विशेष रूप से सुरक्षा रिलीज़।.
2. न्यूनतम विशेषाधिकार का सिद्धांत
   • प्रशासनिक पहुंच को सीमित करें। कार्य के लिए आवश्यक न्यूनतम विशेषाधिकारों के साथ खाते बनाएं।.
3. मजबूत प्रमाणीकरण लागू करें
   • मजबूत पासवर्ड का उपयोग करें, पासवर्ड प्रबंधकों का उपयोग करें, यदि आवश्यक हो तो पासवर्ड समाप्ति को मजबूर करें, और 2FA सक्षम करें।.
4. wp-admin को प्रतिबंधित करें
   • IP अनुमति सूची, प्रशासन के लिए VPN पहुंच, या wp-admin के लिए वेब सर्वर सुरक्षा का उपयोग करें।.
5. मॉनिटर और लॉग करें
   • उपयोगकर्ता क्रियाओं के लिए ऑडिट लॉग बनाए रखें। लॉग संरक्षण घटनाओं को पुनर्निर्माण में मदद करता है।.
6. कस्टम कोड में nonces और उचित क्षमता जांच का उपयोग करें
   • यदि आप प्लगइन्स या थीम विकसित करते हैं, तो हमेशा nonces और current_user_can() स्थिति-परिवर्तन करने वाली क्रियाओं को करने से पहले सत्यापित करें।.
7. प्लगइन कार्यक्षमता के प्रदर्शन को सीमित करें
   • अनधिकृत उपयोगकर्ताओं के लिए प्लगइन प्रशासन अंत बिंदुओं को उजागर करने से बचें और सुनिश्चित करें कि क्रियाएं जहां संभव हो POST-केवल हैं।.
8. बैकअप रणनीति
   • ऑफ-साइट संरक्षण के साथ दैनिक बैकअप बनाए रखें और समय-समय पर पुनर्स्थापनों का परीक्षण करें।.
9. एक स्तरित रक्षा दृष्टिकोण का उपयोग करें
   • एप्लिकेशन स्तर पर हार्डनिंग (nonces, क्षमता जांच) को परिधि सुरक्षा (WAF), होस्ट सुरक्षा, और निगरानी के साथ मिलाएं।.

परतदार रक्षा साइटों को इस तरह की कमजोरियों से बचाने में कैसे मदद करती है

संचालन सुरक्षा के दृष्टिकोण से, एकल विफलता के बिंदु के बजाय कई नियंत्रणों पर भरोसा करें। प्रभावी तत्वों में शामिल हैं:

• प्रबंधित वेब एप्लिकेशन फ़ायरवॉल जो ज्ञात शोषण पैटर्न को जल्दी से अवरुद्ध करने के लिए आभासी पैच लागू कर सकते हैं।.
• शोषण के संकेतों का पता लगाने के लिए स्वचालित मैलवेयर स्कैनिंग और फ़ाइल अखंडता निगरानी।.
• असामान्य प्रशासनिक क्रियाओं के लिए ऑडिट लॉगिंग और अलर्टिंग (उदाहरण के लिए, पोस्टमेटा का सामूहिक हटाना)।.
• स्पष्ट घटना प्रतिक्रिया प्रक्रियाएँ और रनबुक ताकि टीमें जल्दी से कार्रवाई कर सकें यदि कोई साइट प्रभावित होती है।.

घटना चेकलिस्ट (त्वरित संदर्भ)

• प्लगइन को 2.0.4 में अपडेट करें (या यदि अपडेट संभव नहीं है तो तुरंत प्लगइन को निष्क्रिय करें)।.
• संदिग्ध अनुरोधों के लिए एक्सेस लॉग की समीक्षा करें जिसमें हटाएँ= और प्लगइन पथ शामिल हैं।.
• बैकअप से प्रभावित कस्टम फ़ील्ड का ऑडिट और पुनर्स्थापना करें।.
• व्यवस्थापक क्रेडेंशियल्स को रीसेट करें और 2FA लागू करें।.
• अपडेट लागू होने तक शोषण पैटर्न को अवरुद्ध करने के लिए एक WAF नियम लागू करें।.
• मैलवेयर/बैकडोर के लिए स्कैन करें और फ़ाइल अखंडता जांच करें।.
• पुनरावृत्ति या संदिग्ध घटनाओं की निगरानी करें।.

प्रशासकों के लिए नमूना SQL और जांच

1. अटैचमेंट से संबंधित पोस्टमेटा प्रविष्टियाँ खोजें:

   SELECT pm.meta_id, pm.post_id, pm.meta_key, pm.meta_value, p.post_title;

2. समय द्वारा संदिग्ध अचानक हटाने की जांच करें (तुलना के लिए पहले का बैकअप आवश्यक है):

   SELECT p.ID, p.post_title, pm.meta_key, pm.meta_value;

3. यदि आप प्रशासनिक क्रियाओं के लिए एक ऑडिट लॉग तालिका बनाए रखते हैं, तो हटाने की क्रियाओं के लिए खोजें:

   SELECT *
   FROM wp_admin_activity
   WHERE action LIKE '%delete_meta%' OR details LIKE '%meta_key%';

प्लगइन डेवलपर्स के लिए मार्गदर्शन (WordPress में CSRF को रोकना)

यदि आप WordPress प्लगइन्स के लेखक हैं, तो CSRF कमजोरियों को पेश करने से बचने के लिए इन सर्वोत्तम प्रथाओं का पालन करें:

• नॉनसेस का उपयोग करें: नॉनसेस बनाएं और सत्यापित करें wp_create_nonce() 8. और check_admin_referer() या wp_verify_nonce().
• क्षमताओं की जांच करें: हमेशा कॉल करें current_user_can() डेटा को संशोधित करने वाली क्रियाओं को करने से पहले।.
• स्थिति परिवर्तनों के लिए POST का उपयोग करें: GET के माध्यम से स्थिति-परिवर्तन करने वाली क्रियाओं से बचें।.
• इनपुट को साफ और मान्य करें: आने वाले डेटा को साफ करें और यह सुनिश्चित करें कि लक्षित संसाधन मौजूद है और वर्तमान उपयोगकर्ता/संदर्भ का है।.
• एंडपॉइंट्स को सीमित करें: प्रशासनिक-केवल एंडपॉइंट्स को केवल उचित भूमिका वाले प्रमाणित उपयोगकर्ताओं से सुलभ रखें।.
• CSRF प्रयासों का अनुकरण करने के लिए यूनिट/इंटीग्रेशन परीक्षण जोड़ें।.

व्यावहारिक उदाहरण: एक मजबूत हटाने वाले हैंडलर को क्या करना चाहिए (छद्मकोड)

संवेदनशील क्रियाओं को GET के लिए उजागर न करें। एक सुरक्षित हैंडलर में शामिल हैं:

• POST की आवश्यकता है।.
• नॉनसेस की पुष्टि करें।.
• क्षमताओं की जांच करें।.
• लक्ष्य और स्वामित्व को मान्य करें।.
• क्रिया लॉग करें।.

if ( $_SERVER['REQUEST_METHOD'] !== 'POST' ) {

Long‑term monitoring & prevention

• महत्वपूर्ण डेटाबेस तालिकाओं (postmeta, options) के लिए परिवर्तन पहचान लागू करें।.
• स्थापित प्लगइन्स के लिए नियमित अखंडता स्कैन और कमजोरियों की जांच का कार्यक्रम बनाएं (संभवतः स्वचालित तरीके से)।.
• प्रशासनिक पहुंच के लिए एक अनुमति सूची का उपयोग करें और आंतरिक वेबसाइटों के लिए SSO या VPN पहुंच पर विचार करें।.
• उन प्लगइन डेवलपर्स के लिए एक जिम्मेदार कमजोरियों का खुलासा प्रक्रिया बनाए रखें जिन पर आप निर्भर हैं - रखरखाव करने वालों को सुरक्षित कोडिंग प्रथाओं को अपनाने के लिए प्रोत्साहित करें।.

अंतिम विचार

एक हांगकांग सुरक्षा प्रैक्टिशनर के दृष्टिकोण से: यह CSRF मुद्दा यह उजागर करता है कि कैसे यहां तक कि छोटे से छोटे कार्य - एक कस्टम फ़ील्ड को हटाना - जब बड़े पैमाने पर दुरुपयोग किया जाता है तो इसका बड़ा परिचालन प्रभाव हो सकता है। कमजोरियों का पैच किया गया है; सुधार सीधा है: प्लगइन को अपडेट करें और मानक हार्डनिंग प्रथाओं को लागू करें।.

यदि आप कई वर्डप्रेस साइटों का प्रबंधन करते हैं, तो जहां उपयुक्त हो, अपडेट को स्वचालित करें, उसे परिधीय सुरक्षा और निगरानी के साथ मिलाएं, और स्पष्ट घटना प्रतिक्रिया प्रक्रियाओं को बनाए रखें ताकि आप जब एक कमजोरी का खुलासा किया जाए तो जल्दी कार्रवाई कर सकें। सतर्क रहें: समय पर पैचिंग, न्यूनतम विशेषाधिकार, मजबूत प्रमाणीकरण, और लॉगिंग व्यावहारिक साइट सुरक्षा के आधार हैं।.

— हांगकांग सुरक्षा विशेषज्ञ