अवलोकन

PPWP — वर्डप्रेस पासवर्ड प्रोटेक्ट पेज प्लगइन में एक भेद्यता (संस्करण 1.9.11 में ठीक की गई) ने सब्सक्राइबर-स्तरीय विशेषाधिकार वाले प्रमाणित उपयोगकर्ताओं को पासवर्ड सुरक्षा को बायपास करने और वर्डप्रेस REST API (CVE-2025-5998) के माध्यम से संरक्षित सामग्री को पुनः प्राप्त करने की अनुमति दी। यह समस्या एक प्रमाणीकरण/अधिकार विफलता है जो संवेदनशील डेटा के उजागर होने का कारण बन सकती है (OWASP A07 — पहचान और प्रमाणीकरण विफलताएँ)।.

यह सलाह एक संक्षिप्त, व्यावहारिक योजना प्रदान करती है: कमजोरी कैसे काम करती है, उजागर होने की पुष्टि कैसे करें, तत्काल शमन जो आप अभी लागू कर सकते हैं, और दीर्घकालिक सख्ती की सलाह। मार्गदर्शन एक हांगकांग सुरक्षा प्रैक्टिशनर के दृष्टिकोण से लिखा गया है जो उत्पादन वातावरण के लिए व्यावहारिक, कम-व्यवधान नियंत्रणों पर केंद्रित है।.

क्या हुआ (उच्च स्तर)

PPWP प्रति-पृष्ठ पासवर्ड सुरक्षा प्रदान करता है। 1.9.11 में सुधार से पहले, प्लगइन सभी मामलों में REST API अनुरोधों को सही ढंग से मान्य नहीं करता था, जिससे निम्न-विशेषाधिकार वाले खाते (सब्सक्राइबर और समान) REST एंडपॉइंट्स के माध्यम से पासवर्ड-सुरक्षित पृष्ठों को पढ़ने की अनुमति मिलती थी।.

• सब्सक्राइबर REST कॉल का उपयोग करके संरक्षित पृष्ठ/पोस्ट सामग्री प्राप्त कर सकते थे जो छिपी होनी चाहिए थी।.
• बायपास अपेक्षित प्रमाणीकरण/अधिकार गारंटी को तोड़ता है और इसलिए इसे संवेदनशील डेटा के उजागर होने के रूप में गिना जाता है।.

विक्रेता ने 1.9.11 में एक पैच जारी किया, लेकिन कई साइटें विलंबित अपडेट, कस्टम निर्माण, या लॉक किए गए परिवर्तन विंडो के कारण संवेदनशील बनी हुई हैं।.

जोखिम क्यों महत्वपूर्ण है

हालांकि प्रकाशित गंभीरता “कम” है (CVSS-जैसी सार्वजनिक वर्गीकरण 4.3), वास्तविक प्रभाव इस पर निर्भर करता है कि आप PPWP के साथ क्या सुरक्षित करते हैं। व्यावहारिक परिणामों में शामिल हैं:

• आंतरिक घोषणाओं, ग्राहक जानकारी, या अन्य संवेदनशील पृष्ठों का उजागर होना।.
• संरक्षित सामग्री में एम्बेडेड कॉन्फ़िगरेशन, क्रेडेंशियल्स, या API कुंजियों का खुलासा जो आगे के समझौते को सक्षम कर सकता है।.
• यदि व्यक्तिगत डेटा उजागर होता है तो प्रतिष्ठा को नुकसान या नियामक रिपोर्टिंग की बाध्यताएँ।.

व्यवसाय-क्रिटिकल या गोपनीय सामग्री की सुरक्षा के लिए PPWP का उपयोग करने वाली साइटों के लिए, इसे उच्च प्राथमिकता वाले सुधार आइटम के रूप में मानें।.

किस पर प्रभाव पड़ता है

कोई भी वर्डप्रेस साइट जो PPWP — पासवर्ड प्रोटेक्ट पेज प्लगइन का उपयोग कर रही है जिसका संस्करण 1.9.11 से पहले है। एक हमलावर को बायपास का शोषण करने के लिए केवल सब्सक्राइबर-स्तरीय विशेषाधिकार (या समान क्षमताओं के लिए मैप की गई कोई भी भूमिका) के साथ एक खाता चाहिए।.

आपकी उजागर होने की पुष्टि: पहचानने के चरण

दूसरों की साइटों का परीक्षण न करें।. निम्नलिखित चरण साइट के मालिकों और प्रशासकों के लिए हैं जो अपनी स्वयं की इंस्टॉलेशन की जांच कर रहे हैं।.

1. प्लगइन और संस्करण की पुष्टि करें
   • WP admin → Plugins → “PPWP – Password Protect Page” की तलाश करें।.
   • या wp-content/plugins/password-protect-page/readme.txt या प्लगइन के मुख्य फ़ाइल का निरीक्षण करें और संस्करण हेडर की जांच करें। यदि < 1.9.11 है, तो आप संभावित रूप से कमजोर हैं।.
2. एक परीक्षण सब्सक्राइबर खाता बनाएं
   • व्यवस्थापक → उपयोगकर्ता → नया जोड़ें → भूमिका: ग्राहक।.
   • प्रशासन से लॉग आउट करें, फिर एक निजी ब्राउज़र या अलग सत्र में सब्सक्राइबर के रूप में लॉग इन करें।.
3. एक सुरक्षित पृष्ठ के लिए REST API पहुंच का परीक्षण करें

   PPWP द्वारा सुरक्षित एक पृष्ठ की पहचान करें और इसके पोस्ट ID (उदाहरण: 123) को नोट करें। सब्सक्राइबर सत्र सक्रिय होने पर, पृष्ठ के लिए WP REST API एंडपॉइंट का अनुरोध करें:

   curl -i -b cookies.txt -c cookies.txt "https://example.com/wp-json/wp/v2/pages/123"

   यदि JSON प्रतिक्रिया में शामिल है सामग्री.प्रदर्शित। सुरक्षित सामग्री के साथ जब आप सब्सक्राइबर के रूप में लॉग इन हैं, तो पृष्ठ REST API के माध्यम से उजागर है।.

4. प्लगइन-विशिष्ट REST मार्गों की जांच करें

   निरीक्षण करें https://example.com/wp-json/ और PPWP या “password” से संबंधित नामस्थान या मार्गों की तलाश करें। यदि एक PPWP मार्ग बिना क्षमता जांच के सामग्री लौटाता है, तो यह एक लाल झंडा है।.

5. सर्वर लॉग

   सब्सक्राइबर खातों से या जब आपने परीक्षण खाता का उपयोग किया था, तब के लिए अनुरोधों के लिए एक्सेस लॉग की खोज करें /wp-json/ जो पृष्ठ ID या प्लगइन मार्गों को शामिल करते हैं।.

यदि परीक्षणों से सुरक्षित सामग्री लौटती है, तो साइट को कमजोर मानें और तुरंत सुधार लागू करें।.

तात्कालिक सुधार (अब क्या करें)

तात्कालिकता और प्रभाव के अनुसार प्राथमिकता वाले अल्पकालिक कार्य।.

1. प्लगइन को 1.9.11 या बाद के संस्करण में अपडेट करें (अधिकृत समाधान)

   विक्रेता पैच को WP प्रशासन → प्लगइन्स → अभी अपडेट करें के माध्यम से लागू करें। यह अंतिम समाधान है।.

2. प्लगइन को अस्थायी रूप से निष्क्रिय करें

   यदि संरक्षित सामग्री महत्वपूर्ण है और आप तुरंत पैच नहीं कर सकते, तो समाधान लागू करने तक प्लगइन को निष्क्रिय करने पर विचार करें। ध्यान दें कि निष्क्रियता सुरक्षा तर्क को हटा देती है और पृष्ठों को उजागर कर सकती है - पहले व्यापार-बंद का आकलन करें।.

3. गैर-विश्वसनीय उपयोगकर्ताओं के लिए REST API पहुंच को प्रतिबंधित करें

   गुमनाम या निम्न-विशिष्ट खातों के लिए REST API अंत बिंदुओं को ब्लॉक या प्रतिबंधित करें। आप अपडेट करते समय REST मार्गों को सीमित करने के लिए एक छोटा कोड स्निपेट या साइट पहुंच नियंत्रण का उपयोग कर सकते हैं।.

4. अपने WAF के माध्यम से आभासी पैच लागू करें

   यदि आप एक वेब एप्लिकेशन फ़ायरवॉल संचालित करते हैं, तो नियम लागू करें जो प्लगइन के REST नामस्थान के लिए संदिग्ध पहुंच पैटर्न को ब्लॉक करते हैं या पासवर्ड-संरक्षित पोस्ट के लिए लौटाई गई सामग्री को हटा देते हैं। नीचे WAF मार्गदर्शन देखें।.

5. उपयोगकर्ता खातों का ऑडिट करें

   अनावश्यक सब्सक्राइबर खातों को हटा दें, यदि आवश्यक न हो तो स्व-रजिस्ट्रेशन को निष्क्रिय करें, और हाल ही में बनाए गए खातों की समीक्षा करें।.

6. बैकअप और स्नैपशॉट

   परिवर्तनों से पहले एक बैकअप और फ़ाइल प्रणाली/डेटाबेस स्नैपशॉट बनाएं ताकि यदि आवश्यक हो तो आप वापस रोल कर सकें।.

तात्कालिक कोड शमन का उदाहरण: पासवर्ड-संरक्षित पोस्ट के लिए REST प्रतिक्रियाओं को प्रतिबंधित करें

साइट-विशिष्ट प्लगइन या चाइल्ड थीम functions.php में जोड़ें। पहले स्टेजिंग में परीक्षण करें। यह उदाहरण REST API को पासवर्ड-संरक्षित पोस्ट के लिए पूर्ण सामग्री लौटाने से रोकता है पोस्ट_पासवर्ड सेट, जब तक उपयोगकर्ता के पास संपादित_पोस्ट क्षमता है।.

add_filter( 'rest_prepare_post', 'hksec_restrict_protected_rest_content', 10, 3 );'
if ( isset( $post->post_password ) && ! empty( $post->post_password ) ) {.
'if ( ! current_user_can( 'edit_posts' ) ) {

नोट्स:

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

WAF / आभासी पैचिंग मार्गदर्शन

आभासी पैचिंग एक प्रभावी अस्थायी उपाय है जब समय पर प्लगइन अपडेट संभव नहीं होते। निम्नलिखित रणनीतियाँ व्यावहारिक हैं और संचालन टीमों द्वारा सामान्यतः लागू की जाती हैं:

1. प्लगइन-विशिष्ट REST नामस्थान को ब्लॉक करें

   प्लगइन द्वारा उपयोग किए जाने वाले REST नामस्थान की पहचान करें (जैसे, /wp-json/ppwp/ या /wp-json/password-protect-page/) और गैर-प्रशासक सत्रों के लिए उन नामस्थान के लिए बाहरी अनुरोधों को अस्वीकार करें।.

2. प्रतिक्रियाओं को इंटरसेप्ट और साफ करें

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

3. REST API व्यवहार पर दर-सीमा लगाना

   प्रमाणित निम्न-विशेषाधिकार खातों से उत्पन्न स्वचालित सामूहिक-निकासी प्रयासों को धीमा करने के लिए REST अंत बिंदुओं पर उच्च अनुरोध दरों को थ्रॉटल करें।.

4. संदिग्ध अनुरोध/प्रतिक्रिया पैटर्न के लिए हस्ताक्षर नियम

   उन अनुरोधों को ब्लॉक करें जिनमें एक प्रमाणित कुकी जो एक सब्सक्राइबर भूमिका से जुड़ी है, पोस्ट-सामग्री अंत बिंदुओं का अनुरोध करती है और कोई मान्य नॉनसेस या क्षमता जांच मौजूद नहीं है।.

5. संदिग्ध पंजीकरण और लॉगिन की निगरानी करें

   स्वचालित उपयोगकर्ता-निर्माण पैटर्न को ब्लॉक या चुनौती दें ताकि हमलावर के सब्सक्राइबर खाते को प्राप्त करने की संभावना कम हो सके।.

उदाहरणात्मक वैचारिक ModSecurity नियम:

# संदिग्ध PPWP नामस्थान के लिए REST अनुरोधों को अस्वीकार करें जब तक प्लगइन पैच न हो जाए"

ब्लॉक करने से पहले निगरानी मोड में WAF नियमों का परीक्षण करें ताकि गलत सकारात्मकता से बचा जा सके। प्रतिक्रिया-शरीर फ़िल्टरिंग के प्रदर्शन की लागत होती है; इसे चयनात्मक रूप से लागू करें।.

हार्डनिंग और दीर्घकालिक सर्वोत्तम प्रथाएँ

एक प्लगइन को ठीक करना तत्काल जोखिम को कम करता है, लेकिन अपने संपत्ति में जोखिम को कम करने के लिए इन दीर्घकालिक नियंत्रणों को अपनाएं:

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

सुधार के बाद परीक्षण कैसे करें

1. सब्सक्राइबर REST API परीक्षण (ऊपर curl उदाहरण) को दोहराएं और पुष्टि करें कि संरक्षित सामग्री वापस नहीं आई है।.
2. उपयोगकर्ता UX को मान्य करें: वैध उपयोगकर्ताओं को अभी भी इच्छित पासवर्ड फ़ॉर्म या UI के माध्यम से संरक्षित सामग्री तक पहुंच प्राप्त करनी चाहिए।.
3. REST एंडपॉइंट्स और प्लगइन कार्यक्षमता का परीक्षण करने के लिए एकीकरण परीक्षण चलाएं ताकि कोई पुनःप्रवर्तन न हो।.
4. प्रॉब्स और अवरुद्ध REST प्रयासों के लिए एक्सेस लॉग की निगरानी करें जो चल रहे स्कैनिंग/शोषण प्रयासों को इंगित करते हैं।.

घटना प्रतिक्रिया चेकलिस्ट (यदि आप मानते हैं कि आपको शोषित किया गया था)

1. अलग करें और स्नैपशॉट लें: सर्वर और डेटाबेस का स्नैपशॉट लें; फोरेंसिक्स के लिए वर्तमान लॉग को संरक्षित करें।.
2. सबूत को संरक्षित करें: लॉग को अधिलेखित या नष्ट न करें; REST अनुरोध ट्रेस और एक्सेस लॉग एकत्र करें।.
3. क्रेडेंशियल्स को घुमाएं: प्रशासनिक और API क्रेडेंशियल्स को बदलें जो संभवतः लीक की गई सामग्री के माध्यम से उजागर हुए हैं; उच्च-विशेषाधिकार खातों के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
4. सामग्री के उजागर होने का मूल्यांकन करें: एक्सेस की गई पृष्ठों की सूची बनाएं और आंतरिक समीक्षा और किसी भी आवश्यक सूचनाओं के लिए संवेदनशीलता का आकलन करें।.
5. पैच और शमन करें: PPWP को 1.9.11+ पर अपडेट करें, WAF वर्चुअल पैच लागू करें, या आवश्यक होने पर प्लगइन को निष्क्रिय करें।.
6. सत्र रद्द करें: समझौता किए गए खातों के लिए सक्रिय सत्र समाप्त करें।.
7. आगे के समझौते के लिए स्कैन करें: नए प्रशासनिक उपयोगकर्ताओं, अनुसूचित कार्यों, संशोधित फ़ाइलों, या इंजेक्टेड कोड की तलाश करें।.
8. हितधारकों को सूचित करें: प्रभावित पक्षों और होस्टिंग प्रदाता को उचित स्थान पर सूचित करें।.
9. घटना के बाद की समीक्षा: दस्तावेज़ मूल कारण और पैचिंग और निगरानी प्रक्रियाओं में सुधार करें।.

डेवलपर्स और इंटीग्रेटर्स के लिए सिफारिशें

• संवेदनशील API प्रतिक्रियाओं के लिए WordPress क्षमता जांचें (जैसे, current_user_can()) क्लाइंट-प्रदत्त ध्वजों के लिए नहीं।.
• उन REST एंडपॉइंट्स के लिए नॉनसेस या प्रमाणीकरण की आवश्यकता करें और मान्य करें जो प्रस्तुत या संवेदनशील सामग्री लौटाते हैं।.
• जब तक अनुरोधकर्ता स्पष्ट रूप से अधिकृत न हो, तब तक REST के माध्यम से प्रस्तुत संरक्षित सामग्री को उजागर करने से बचें।.
• सुरक्षा सुधारों के लिए स्पष्ट अपग्रेड पथ और चेंजलॉग प्रदान करें ताकि प्रशासक तेजी से प्रतिक्रिया कर सकें।.

उदाहरण पहचान स्वचालन जिसे आप कई साइटों पर चला सकते हैं

कई साइटों का प्रबंधन करने वाली टीमों के लिए, एक सरल स्क्रिप्ट यह परीक्षण कर सकती है कि क्या एक पृष्ठ उजागर है। केवल उन साइटों के खिलाफ चलाएं जिनका आप स्वामित्व/प्रबंधन करते हैं।.

#!/usr/bin/env bash

दर सीमाओं का सम्मान करें और आकस्मिक दुरुपयोग से बचने के लिए नियंत्रित तरीके से जांचें।.

सर्वोत्तम प्रथा WAF नियम उदाहरण (सैद्धांतिक)

इन सैद्धांतिक नियमों का उपयोग इंजीनियरिंग और संचालन टीमों के लिए प्रारंभिक बिंदु के रूप में करें। ट्यून और पूरी तरह से परीक्षण करें।.

1. प्लगइन नामस्थान अवरुद्ध करें: REQUEST_URI से मेल खाएं जिसमें /wp-json/ppwp या /wp-json/password-protect-page और निम्न-विशिष्ट सत्रों के लिए अवरुद्ध या चुनौती दें।.
2. पासवर्ड-संरक्षित पोस्ट के लिए REST प्रतिक्रियाओं में सामग्री को स्ट्रिप करें: यदि प्रतिक्रिया में शामिल है "सामग्री":{"प्रदर्शित": और पोस्ट को चिह्नित किया गया है पोस्ट_पासवर्ड, गैर-प्रशासक अनुरोधों के लिए प्रदर्शित सामग्री को बदलें।.
3. दर-सीमा: अत्यधिक अनुरोधों को सीमित करें /wp-json/wp/v2/posts या /wp-json/wp/v2/pages उसी उपयोगकर्ता/IP से।.

साइट मालिकों के लिए संचार मार्गदर्शन

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

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

क्या इस बग के साथ गुमनाम (गैर-प्रमाणित) पहुंच संभव है?

रिपोर्ट की गई समस्या के लिए कम से कम सब्सक्राइबर-स्तरीय विशेषाधिकार की आवश्यकता थी। हालांकि, हमलावर आमतौर पर पंजीकरण या खरीदने के द्वारा कम-विशेषाधिकार वाले खाते प्राप्त करते हैं, इसलिए इसे प्रमाणित-लेकिन-निम्न-विशेषाधिकार जोखिम के रूप में मानें।.

क्या प्लगइन को निष्क्रिय करने से संरक्षित पृष्ठ छिप जाएंगे?

PPWP को निष्क्रिय करने से प्लगइन की सुरक्षा लॉजिक हटा दी जाती है; पृष्ठ डिफ़ॉल्ट दृश्यता पर लौट सकते हैं। यदि सामग्री को निजी रखना आवश्यक है तो वैकल्पिक पहुंच नियंत्रण की योजना बनाने के बाद ही निष्क्रिय करें।.

क्या मैं होस्टिंग प्रदाता की सुरक्षा पर भरोसा कर सकता हूँ?

होस्टिंग प्रदाता की सुरक्षा जैसे WAFs सहायक नियंत्रण के रूप में उपयोगी हैं, लेकिन वे विक्रेता के फिक्स लागू करने के स्थान पर नहीं आते। अपडेट करते समय एक पुल के रूप में आभासी पैच का उपयोग करें।.

व्यावहारिक चेकलिस्ट — अगले 24–72 घंटे

• पुष्टि करें कि क्या PPWP स्थापित है और प्लगइन संस्करण की जांच करें।.
• यदि संस्करण < 1.9.11 है, तो 1.9.11 या बाद के लिए तत्काल अपग्रेड का कार्यक्रम बनाएं।.
• यदि अपडेट 24 घंटे के भीतर लागू नहीं किया जा सकता है, तो अस्थायी उपाय लागू करें: REST API पहुंच को सीमित करें, ऊपर दिए गए प्रतिक्रिया फ़िल्टर को जोड़ें, या प्लगइन को निष्क्रिय करें।.
• संदिग्ध PPWP REST पहुंच को ब्लॉक या मॉनिटर करने के लिए WAF नियम लागू करें।.
• पिछले 90 दिनों में बनाए गए खातों का ऑडिट करें और संदिग्ध सब्सक्राइबर खातों को हटा दें।.
• परिवर्तन करने से पहले बैकअप/स्नैपशॉट लें; फोरेंसिक समीक्षा के लिए लॉग बनाए रखें।.
• सब्सक्राइबर के रूप में सामग्री-प्रवेश परीक्षण चलाएं ताकि शमन की प्रभावशीलता की पुष्टि हो सके।.
• यदि एक्सपोज़र का सबूत मिलता है, तो घटना प्रतिक्रिया चेकलिस्ट का पालन करें।.

अंतिम विचार

प्राधिकरण बग जो प्रमाणित लेकिन निम्न-विशेषाधिकार वाले उपयोगकर्ताओं को संरक्षित सामग्री पढ़ने की अनुमति देते हैं, खतरनाक होते हैं क्योंकि वे पहुंच नियंत्रण लॉजिक में धारणाओं का लाभ उठाते हैं। व्यावहारिक रक्षा तीन गुना है: विक्रेता के फिक्स को तुरंत लागू करें, मुआवजे के नियंत्रण (अस्थायी कोड फ़िल्टर और WAF नियम) लागू करें, और उन निम्न-विशेषाधिकार खातों की संख्या को कम करें जिनका दुरुपयोग किया जा सकता है।.

यदि आपको परीक्षण, वर्चुअल पैच या प्रतिक्रिया योजना के साथ हाथों-हाथ सहायता की आवश्यकता है, तो एक सक्षम सुरक्षा प्रैक्टिशनर से संपर्क करें और पहले स्टेजिंग में परिवर्तन करें। हांगकांग के तेज़ी से बदलते व्यापार वातावरण में, समय पर पैचिंग और हल्के मुआवजे अक्सर एक नियंत्रित घटना और एक सार्वजनिक उल्लंघन के बीच का अंतर बनाते हैं।.

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