यह लेख उन पोस्टों की श्रृंखला में पहला है जो मैं पिछले 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 हमला.
सर्वोत्तम प्रथाओं, उद्योग-स्वीकृत मानकों और शामिल चीट शीट के साथ, Git सीखने के लिए व्यावहारिक मार्गदर्शिका देखें। Googling Git कमांड को रोकें और वास्तव में सीखना यह!
इस विशेष मामले को संभालना काफी सरल था - क्रमिक वाइल्डकार्ड वर्ण हटाएँ:
block = block.replace(/*+/g, '*')
लेकिन यह अभी भी ऐप को अन्य प्रकार के ReDoS हमलों के लिए खुला छोड़ देता है। सौभाग्य से इन प्रकारों में हमारी सहायता के लिए कई पैकेज/पुस्तकालय भी मौजूद हैं:
उपरोक्त समाधानों और अन्य सुरक्षा उपायों के संयोजन का उपयोग करके, मैं इसे दोबारा होने से रोकने में सक्षम हूं। लेकिन यह एक अच्छा अनुस्मारक था कि आप कभी भी उपयोगकर्ता इनपुट पर भरोसा नहीं कर सकते हैं, और आपको इसे अपने एप्लिकेशन में उपयोग करने से पहले हमेशा साफ करना चाहिए। जब तक मेरे साथ ऐसा नहीं हुआ, मुझे पता भी नहीं था कि यह एक संभावित समस्या है, इसलिए उम्मीद है कि इससे किसी और को भी इसी समस्या से बचने में मदद मिलेगी।
क्या आपके पास कोई प्रश्न, टिप्पणी है या आप अपनी कोई कहानी साझा करना चाहते हैं? आगे बढ़ें ट्विटर!
- एसईओ संचालित सामग्री और पीआर वितरण। आज ही प्रवर्धित हो जाओ।
- प्लेटोडेटा.नेटवर्क वर्टिकल जेनरेटिव एआई। स्वयं को शक्तिवान बनाएं। यहां पहुंचें।
- प्लेटोआईस्ट्रीम। Web3 इंटेलिजेंस। ज्ञान प्रवर्धित। यहां पहुंचें।
- प्लेटोईएसजी. कार्बन, क्लीनटेक, ऊर्जा, पर्यावरण, सौर, कचरा प्रबंधन। यहां पहुंचें।
- प्लेटोहेल्थ। बायोटेक और क्लिनिकल परीक्षण इंटेलिजेंस। यहां पहुंचें।
- स्रोत: https://stackabuse.com/behind-the-scenes-never-trust-user-input/
- :हैस
- :है
- :नहीं
- $यूपी
- 1
- 20
- 2019
- 2020
- 24
- 8
- a
- योग्य
- About
- ऊपर
- लेखा
- वास्तव में
- जोड़ा
- इसके अलावा
- पता
- पतों
- फिर
- के खिलाफ
- सब
- अनुमति देना
- अकेला
- भी
- हमेशा
- के बीच में
- an
- और
- कोई
- अनुप्रयोग
- आवेदन
- हैं
- लेख
- AS
- पूछ
- ग्रहण
- At
- आक्रमण
- से बचने
- जागरूक
- बैकएण्ड
- BE
- Beanstalk
- हो जाता है
- किया गया
- से पहले
- पीछे
- परदे के पीछे
- जा रहा है
- बेहतर
- बिट
- खंड
- ब्लॉकिंग
- ब्लॉक
- सीमा
- टूटना
- बनाया गया
- लेकिन
- by
- कर सकते हैं
- पा सकते हैं
- कौन
- मामला
- के कारण होता
- के कारण
- कुछ
- चरित्र
- अक्षर
- जाँच
- कोड
- संयोजन
- टिप्पणियाँ
- कंपनी
- जटिल
- जटिल
- कम्प्यूटेशनल
- संबंध
- सही
- सका
- सका
- सी पी यू
- Crash
- दुर्घटनाग्रस्त
- दुर्घटनाग्रस्त
- बनाना
- ग्राहक
- ग्राहक
- तिथि
- का फैसला किया
- तैनात
- डेवलपर
- डीआईडी
- नहीं था
- do
- डोमेन
- डॉन
- नीचे
- दो
- से प्रत्येक
- आसान
- अन्य
- ईमेल
- ईमेल
- समाप्त
- समाप्त
- समाप्त होता है
- दर्ज
- संपूर्ण
- त्रुटियाँ
- विशेष रूप से
- और भी
- अंत में
- प्रत्येक
- हर कोई
- सब कुछ
- उदाहरण
- महंगा
- अनुभव
- अभिव्यक्ति
- विफलताओं
- काफी
- दूर
- Feature
- विशेषताएं
- कुछ
- आकृति
- लगा
- खोज
- अंत
- प्रथम
- फिक्स
- फोकस
- पीछा किया
- निम्नलिखित
- के लिए
- पूर्व
- से
- मिल
- मिल रहा
- gif
- जाना
- दी
- अच्छा
- गूगल
- महान
- गाइड
- था
- संभालना
- हैंडल
- हाथों पर
- हुआ
- हो रहा है
- है
- मदद
- मदद करता है
- उम्मीद है कि
- घंटे
- मंडराना
- कैसे
- HTTPS
- i
- ID
- if
- in
- शामिल
- निवेश
- बजाय
- में
- मुद्दा
- मुद्दों
- IT
- खुद
- काम
- केवल
- रखा
- जानना
- पिछली बार
- बाद में
- सीखा
- सीख रहा हूँ
- लंबाई
- पाठ
- चलो
- स्तर
- LG
- पुस्तकालय
- पसंद
- संभावित
- ll
- स्थानीय स्तर पर
- लॉगिंग
- लंबा
- लंबे समय तक
- देखा
- बहुत सारे
- किस्मत से
- मैक्रो
- बनाया गया
- मैन्युअल
- बहुत
- विपणन (मार्केटिंग)
- मैच
- मिलान
- शायद
- me
- याद
- मिनट
- गलतियां
- आधुनिक
- आधुनिक तकनीक
- अधिक
- अधिकांश
- बहुत
- विभिन्न
- चाहिए
- देशी
- जरूरत
- कभी नहीँ
- नया
- नई सुविधाएँ
- अगला
- नहीं
- नोड
- Node.js
- अधिसूचित
- संख्या
- अंतर
- of
- on
- ONE
- खुला
- or
- अन्य
- हमारी
- आउट
- अपना
- दर्द
- भाग
- विशेष
- पैटर्न
- स्टाफ़
- प्लेटो
- प्लेटो डेटा इंटेलिजेंस
- प्लेटोडाटा
- पोस्ट
- संभावित
- व्यावहारिक
- को रोकने के
- शायद
- मुसीबत
- प्रक्रिया
- उत्पादन
- उत्पाद
- प्रशन
- त्वरित
- जल्दी से
- बिल्कुल
- बिना सोचे समझे
- RE
- पहुंच
- एहसास हुआ
- कारण
- उचित
- प्राप्त
- फिर से कनेक्ट
- नियमित
- अनुस्मारक
- हटाना
- हटाने
- प्रतिनिधित्व
- सही
- अंगूठी
- नियम
- रन
- दौड़ना
- s
- सास
- सुरक्षा उपायों
- वही
- दृश्यों
- Search
- लग रहा था
- प्रेषक
- कई
- सर्वर
- सेवा
- छाया
- Share
- बांटने
- चादर
- चाहिए
- सरल
- के बाद से
- नींद
- So
- समाधान ढूंढे
- कुछ
- कोई
- कुछ
- अंतरिक्ष
- विशिष्ट
- कील
- स्टैकब्यूज
- मानकों
- शुरू
- फिर भी
- रुकें
- की दुकान
- कहानी
- प्रणाली
- T
- लेना
- बातचीत
- टेक्नोलॉजीज
- अस्थायी
- परीक्षण किया
- परीक्षण
- टेक्स्ट
- से
- कि
- RSI
- लेकिन हाल ही
- उन
- फिर
- वहाँ।
- इन
- वे
- बात
- चीज़ें
- सोचना
- इसका
- पहर
- बार
- सेवा मेरे
- भी
- संक्रमण
- कोशिश
- ट्रस्ट
- की कोशिश कर रहा
- मोड़
- मोड़
- टाइप
- प्रकार
- समझता है
- दुर्भाग्य से
- जब तक
- उन्नत
- us
- उपयोग
- प्रयुक्त
- उपयोगकर्ता
- उपयोगकर्ताओं
- का उपयोग
- विभिन्न
- Ve
- बहुत
- के माध्यम से
- देखें
- इंतज़ार कर रही
- करना चाहते हैं
- जरूरत है
- था
- नहीं था
- देख
- मार्ग..
- we
- वेबसाइटों
- सप्ताह
- कुंआ
- चला गया
- थे
- क्या
- कब
- कौन कौन से
- पूरा का पूरा
- क्यों
- विकिपीडिया
- साथ में
- काम
- कामगार
- काम कर रहे
- होगा
- लिख रहे हैं
- साल
- इसलिए आप
- आपका
- जेफिरनेट