RamenHire जॉब बोर्डमधील एका 'स्टोर्ड HTML इंजेक्शन' (stored HTML injection) बगमुळे कोणीही सार्वजनिक फॉर्म भरून टीमच्या नोटिफिकेशन ईमेलला फिशिंग प्लॅटफॉर्ममध्ये रूपांतरित करू शकत होते.
हा बग कसा शिरला
RamenHire हे Next.js आणि Supabase वर चालते आणि स्टार्टअप्सना लॉग इन न करता जॉब पोस्ट करण्याची सुविधा देते. प्रत्येक सबमिशनमुळे अंतर्गत हायरिंग टीमला एक ईमेल जातो. ईमेलचा मजकूर (body) तयार करण्यासाठी कंपनीचे नाव, जॉब डिस्क्रिप्शन, संपर्क नाव यांसारखी फॉर्ममधील माहिती थेट HTML स्ट्रिंगमध्ये जोडली जाते. ही स्ट्रिंग मेल सर्व्हिसपर्यंत पोहोचण्यापूर्वी तिचे 'एस्केपिंग' (escaping) किंवा 'सॅनिटायझेशन' (sanitisation) केले जात नाही.
टेम्पलेट वापरकर्त्याच्या इनपुटला सुरक्षित HTML मानत असल्यामुळे, एखादा दुर्भावनापूर्ण अर्जदार (malicious applicant) "click here to verify" असा बनावट लिंक इंजेक्ट करू शकतो. हा 'पेलोड' (payload) सर्व्हरवर जॉब लिस्टिंगचा भाग म्हणून स्टोअर होतो, त्यामुळे त्यानंतर येणाऱ्या प्रत्येक नोटिफिकेशन ईमेलमध्ये तो घातक कोड असतो. अटॅकर तो लिंक खऱ्या "View Dashboard" बटणाच्या शेजारी लपवू शकतो, ज्यामुळे टीममधील सदस्य चुकून आपली माहिती (credentials) उघड करतील किंवा फिशिंग साइटला भेट देतील.
हे महत्त्वाचे का होते
हे ईमेल मुख्य हायरिंग टीमला जातात, जे उमेदवारांची प्रक्रिया पुढे नेण्यासाठी सतत लिंक्सवर क्लिक करत असतात.
तांत्रिक त्रुटी
HTML एस्केपिंग ही केवळ एक पायरी नाही. दोन संदर्भांचे (contexts) संरक्षण करणे आवश्यक आहे:
- Text nodes – टॅग्समधील मजकूर.
<चे<मध्ये आणि>चे>मध्ये रूपांतर केल्यामुळे टॅग्स थांबवता येतात, परंतु अटॅकरला 'ॲट्रिब्युट व्हॅल्यू'मधून (attribute value) बाहेर पडण्यापासून रोखता येत नाही. - Attribute values –
href="…"सारख्या टॅग्समधील स्ट्रिंग्स. एखादे कोटेशन मार्क ("किंवा') इंजेक्ट केल्यामुळे अटॅकर ॲट्रिब्युट लवकर बंद करून स्वतःचे मार्कअप टाकू शकतो.
मूळ कोडमध्ये फक्त प्लेन टेक्स्ट हाताळले जात होते, ज्यामुळे ॲट्रिब्युट इंजेक्शनसाठी मोठी संधी उपलब्ध होती.
समस्येचे निराकरण
डेव्हलपरने एक लहान escapeHtml हेल्पर जोडला आणि तो प्रत्येक वापरकर्त्याने दिलेल्या व्हॅल्यूवर (interpolation करण्यापूर्वी) लागू केला, मग ती व्हॅल्यू टेक्स्ट नोडमध्ये असो किंवा ॲट्रिब्युटमध्ये.
पडताळणीच्या पायऱ्या
- Local testing – टेम्पलेट फंक्शन्समध्ये विविध इंजेक्शन स्ट्रिंग्स वापरून तपासले गेले. प्रत्येक चाचणीत केवळ एस्केप केलेले कॅरेक्टर्स दिसले, कोणतेही एक्झिक्युटेबल टॅग्स दिसले नाहीत.
- Production testing – पॅच तैनात (deploy) केल्यानंतर, लाइव्ह साइटद्वारे एक पेलोड सबमिट करण्यात आला, ज्याने Cloudflare Turnstile बॉट चेक यशस्वीरित्या पार केला. त्यानंतर आलेला ईमेल डेव्हलपरच्या इनबॉक्समध्ये पोहोचला; त्यातील घातक लिंक आणि कोणतेही स्क्रिप्ट टॅग्स केवळ विस्कळीत मजकूर (garbled text) म्हणून दिसले, क्लिक करण्यायोग्य घटक म्हणून नाही.
Gmail बद्दल एक टीप: ही सेवा अजूनही URL ला निळा रंग देऊन ती क्लिक करण्यायोग्य बनवू शकते, परंतु ती क्लायंट-साइडची सोय आहे आणि याचा अर्थ असा नाही की HTML इंजेक्शन यशस्वी झाले आहे. हे फिक्स इंजेक्शनद्वारे खरोखरची बटणे तयार करणे किंवा स्क्रिप्ट्स चालवणे थांबवते.
डेव्हलपर्सनी काय काळजी घ्यावी
- सार्वजनिक फॉर्ममधील डेटावर कधीही विश्वास ठेवू नका – निष्पाप वाटणारे फॉर्म देखील अशा प्रकारे स्टोर्ड आउटपुट तयार करू शकतात जे इतरत्र वापरले जाते.
- वापरण्याच्या वेळी एस्केप करा – रेंडरिंगच्या अगदी आधी संदर्भावर आधारित एस्केपिंग (text vs. attribute) लागू करा, पाइपलाइनमध्ये आधी नाही.
- क्लायंट-साइड आणि सर्व्हर-साइड दोन्ही तपासणी करा – युनिट टेस्ट्स स्पष्ट त्रुटी शोधतात; लाइव्ह UI द्वारे मॅन्युअल एंड-टू-एंड टेस्ट केल्यामुळे प्रत्यक्ष ट्रॅफिकमध्ये सुरक्षा व्यवस्था टिकून आहे याची खात्री होते.
- ईमेल क्लायंटच्या वैशिष्ट्यांची (quirks) जाणीव ठेवा – काही क्लायंट आपोआप URL ला लिंकमध्ये रूपांतरित करतात, ज्यामुळे सुरक्षेचा चुकीचा आभास निर्माण होऊ शकतो. मूळ HTML मध्ये कोणतेही ॲक्टिव्ह घटक नाहीत याची खात्री करा.
सारांश
वापरकर्त्याच्या इनपुट हाताळण्यातील एका साध्या चुकीमुळे नियमित नोटिफिकेशन ईमेल फिशिंग वेक्टरमध्ये बदलले. सर्वसमावेशक HTML-एस्केपिंग रूटीन लागू करून आणि स्थानिक तसेच प्रोडक्शनमध्ये फिक्सची पडताळणी करून इनबॉक्सची अखंडता (integrity) पुन्हा प्रस्थापित करण्यात आली. ही घटना कोणत्याही वेब ॲपसाठी एक शाश्वत धडा देते जे अविश्वसनीय डेटापासून HTML तयार करते: योग्य सॅनिटायझेशन करणे अनिवार्य आहे आणि त्याकडे दुर्लक्ष केल्यास तुमच्या वापरकर्त्यांच्या इनबॉक्समध्ये थेट धोका पोहोचू शकतो.