यह लेख उन पोस्टों की श्रृंखला में पहला है जो मैं पिछले 8 वर्षों से विभिन्न SaaS उत्पादों और वेबसाइटों को चलाने के बारे में लिख रहा हूँ। मैं उन कुछ मुद्दों को साझा करूंगा जिनसे मैंने निपटा है, जो सबक मैंने सीखे हैं, जो गलतियां की हैं, और शायद कुछ चीजें जो सही हुईं। मुझे पता है आपको क्या लगता है!

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

कुछ सप्ताह बाद, मुझे एक ग्राहक द्वारा सूचित किया गया (जो अपने आप में शर्मनाक है) कि सेवा काम नहीं कर रही थी और उन्हें अपने इनबॉक्स में बहुत सारे ब्लॉक किए जाने योग्य ईमेल मिल रहे थे, इसलिए मैंने जांच की। कई बार यह समस्या Google द्वारा हमारी सेवा से उपयोगकर्ता के खाते से कनेक्शन हटाने के कारण होती है, जिसे सिस्टम उपयोगकर्ता को ईमेल के माध्यम से सूचित करके और उन्हें फिर से कनेक्ट करने के लिए कहकर संभालता है, लेकिन इस बार मामला कुछ और था।

ऐसा लग रहा था कि बैकएंड कार्यकर्ता जो उपयोगकर्ता ब्लॉकों के विरुद्ध ईमेल की जाँच करता है वह हर 5-10 मिनट में क्रैश होता रहता है। सबसे अजीब हिस्सा - लॉग में कोई त्रुटि नहीं थी, मेमोरी ठीक थी, लेकिन सीपीयू कभी-कभी यादृच्छिक समय पर बढ़ जाता था। इसलिए अगले 24 घंटों के लिए (सोने के लिए 3 घंटे के ब्रेक के साथ - क्षमा करें ग्राहकों 😬), मुझे हर बार क्रैश होने पर कर्मचारी को मैन्युअल रूप से पुनरारंभ करना पड़ा। किसी कारण से, इलास्टिक बीनस्टॉक सेवा पुनरारंभ होने के लिए बहुत लंबे समय से प्रतीक्षा कर रही थी, यही कारण है कि मुझे इसे मैन्युअल रूप से करना पड़ा।

उत्पादन में मुद्दों को डीबग करना हमेशा एक पीड़ादायक होता है, खासकर जब से मैं इस मुद्दे को स्थानीय स्तर पर पुन: पेश नहीं कर सका, इसका कारण क्या था इसका पता लगाना तो दूर की बात है। तो किसी भी "अच्छे" डेवलपर की तरह, मैंने अभी लॉगिंग शुरू की है सब कुछ और सर्वर के दोबारा क्रैश होने का इंतजार किया। चूंकि सीपीयू समय-समय पर गति कर रहा था, मुझे लगा कि यह कोई मैक्रो समस्या नहीं थी (जैसे कि जब आपकी मेमोरी खत्म हो जाती है) और संभवतः यह किसी विशिष्ट ईमेल या उपयोगकर्ता के कारण हो रहा था। इसलिए मैंने इसे सीमित करने का प्रयास किया:

• क्या यह किसी निश्चित ईमेल आईडी या प्रकार पर क्रैश हो रहा था?
• क्या यह किसी दिए गए ग्राहक के लिए क्रैश हो रहा था?
• क्या यह कुछ नियमित अंतराल पर दुर्घटनाग्रस्त हो रहा था?

इसके घंटों के बाद, और मेरी अपेक्षा से अधिक समय तक लॉग को देखने के बाद, अंततः, मैंने इसे एक विशिष्ट ग्राहक तक सीमित कर दिया। वहां से, खोज स्थान काफी कम हो गया - यह संभवतः एक अवरोधन नियम या एक विशिष्ट ईमेल था जिस पर हमारा सर्वर पुनः प्रयास करता रहा। सौभाग्य से मेरे लिए, यह पहला था, जिसे डिबग करना कहीं अधिक आसान समस्या है, यह देखते हुए कि हम एक बहुत ही गोपनीयता-केंद्रित कंपनी हैं और किसी भी ईमेल डेटा को संग्रहीत या देखते नहीं हैं।

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

एक बात जिसके बारे में मैंने नहीं सोचा वह यह है कि हर कोई यह नहीं समझता कि वाइल्डकार्ड कैसे काम करते हैं। मैंने मान लिया कि अधिकांश लोग उनका उपयोग उसी तरह करेंगे जैसे मैं एक डेवलपर के रूप में करता हूँ * किसी भी संख्या में वर्णों का प्रतिनिधित्व करने के लिए। दुर्भाग्य से, इस विशेष उपयोगकर्ता ने मान लिया था कि आपको इसका उपयोग करने की आवश्यकता है प्रत्येक पात्र के लिए एक वाइल्डकार्ड जिसका आप मिलान करना चाहते हैं. उनके मामले में, वे सभी ईमेल को एक निश्चित डोमेन से ब्लॉक करना चाहते थे (जो ब्लॉक सेंडर के पास एक मूल सुविधा है, लेकिन उन्हें इसका एहसास नहीं हुआ होगा, जो अपने आप में एक पूरी समस्या है)। तो उपयोग करने के बजाय *@example.com, उन्होंने उपयोग किया **********@example.com.

पीओवी: अपने उपयोगकर्ताओं को आपके ऐप का उपयोग करते हुए देखना...

अपने वर्कर सर्वर पर वाइल्डकार्ड को संभालने के लिए, हम Node.js लाइब्रेरी का उपयोग कर रहे हैं मिलान, जो ग्लोब मिलान को नियमित अभिव्यक्ति में बदलकर मदद करता है। यह पुस्तकालय तब बदल जाएगा **********@example.com निम्नलिखित रेगेक्स की तरह कुछ में:

/[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*@example.com/i

यदि आपके पास रेगेक्स के साथ कोई अनुभव है, तो आप जानते हैं कि वे बहुत जल्दी बहुत जटिल हो सकते हैं, खासकर कम्प्यूटेशनल स्तर पर। उपरोक्त अभिव्यक्ति को पाठ की किसी भी उचित लंबाई से मिलान करना कम्प्यूटेशनल रूप से बहुत महंगा हो जाता है, जिससे हमारे वर्कर सर्वर पर सीपीयू बाधित हो जाता है। यही कारण है कि सर्वर हर कुछ मिनटों में क्रैश हो जाएगा; यह किसी जटिल रेगुलर एक्सप्रेशन को किसी ईमेल पते से मिलाने की कोशिश में अटक जाएगा. इसलिए जब भी इस उपयोगकर्ता को एक ईमेल प्राप्त होता है, तो अस्थायी विफलताओं को संभालने के लिए हमारे द्वारा किए गए सभी पुनर्प्रयासों के अलावा, यह हमारे सर्वर को क्रैश कर देगा।

तो मैंने इसे कैसे ठीक किया? जाहिर है, त्वरित समाधान एक से अधिक वाइल्डकार्ड वाले सभी ब्लॉकों को ढूंढना और उन्हें ठीक करना था। लेकिन मुझे उपयोगकर्ता इनपुट को सैनिटाइज़ करने का बेहतर काम करने की भी ज़रूरत थी। कोई भी उपयोगकर्ता रेगेक्स दर्ज कर सकता है और पूरे सिस्टम को हटा सकता है ReDoS हमला.

इस विशेष मामले को संभालना काफी सरल था - क्रमिक वाइल्डकार्ड वर्ण हटाएँ:

block = block.replace(/*+/g, '*')

लेकिन यह अभी भी ऐप को अन्य प्रकार के ReDoS हमलों के लिए खुला छोड़ देता है। सौभाग्य से इन प्रकारों में हमारी सहायता के लिए कई पैकेज/पुस्तकालय भी मौजूद हैं:

उपरोक्त समाधानों और अन्य सुरक्षा उपायों के संयोजन का उपयोग करके, मैं इसे दोबारा होने से रोकने में सक्षम हूं। लेकिन यह एक अच्छा अनुस्मारक था कि आप कभी भी उपयोगकर्ता इनपुट पर भरोसा नहीं कर सकते हैं, और आपको इसे अपने एप्लिकेशन में उपयोग करने से पहले हमेशा साफ करना चाहिए। जब तक मेरे साथ ऐसा नहीं हुआ, मुझे पता भी नहीं था कि यह एक संभावित समस्या है, इसलिए उम्मीद है कि इससे किसी और को भी इसी समस्या से बचने में मदद मिलेगी।

क्या आपके पास कोई प्रश्न, टिप्पणी है या आप अपनी कोई कहानी साझा करना चाहते हैं? आगे बढ़ें ट्विटर!

• एसईओ संचालित सामग्री और पीआर वितरण। आज ही प्रवर्धित हो जाओ।
• प्लेटोडेटा.नेटवर्क वर्टिकल जेनरेटिव एआई। स्वयं को शक्तिवान बनाएं। यहां पहुंचें।
• प्लेटोआईस्ट्रीम। Web3 इंटेलिजेंस। ज्ञान प्रवर्धित। यहां पहुंचें।
• प्लेटोईएसजी. कार्बन, क्लीनटेक, ऊर्जा, पर्यावरण, सौर, कचरा प्रबंधन। यहां पहुंचें।
• प्लेटोहेल्थ। बायोटेक और क्लिनिकल परीक्षण इंटेलिजेंस। यहां पहुंचें।
• स्रोत: https://stackabuse.com/behind-the-scenes-never-trust-user-input/