RamenHire வேலைவாய்ப்புத் தளத்தில் இருந்த ஒரு 'stored HTML injection' பிழை, யார் வேண்டுமானாலும் ஒரு பொதுவான படிவத்தைப் (public form) பூர்த்தி செய்து, குழுவினருக்கான அறிவிப்பு மின்னஞ்சல்களை (notification emails) ஒரு ஃபிஷிங் (phishing) தளமாக மாற்ற வழிவகுத்தது.
இந்த பிழை எவ்வாறு உருவானது
RamenHire ஆனது Next.js மற்றும் Supabase ஆகியவற்றின் அடிப்படையில் இயங்குகிறது, மேலும் இது ஸ்டார்ட்அப்கள் (startups) லாகின் செய்யாமலேயே வேலைவாய்ப்புகளைப் பதிவிட அனுமதிக்கிறது. ஒவ்வொரு சமர்ப்பிப்பும் (submission) உள்நாட்டுத் தேர்வு குழுவிற்கு (internal hiring team) ஒரு மின்னஞ்சலை அனுப்புகிறது. மின்னஞ்சலின் உள்ளடக்கமானது (email body), படிவத்தில் உள்ள மூலத் தரவுகளை—நிறுவனத்தின் பெயர், வேலை விவரம், தொடர்பு பெயர்—நேரடியாக ஒரு HTML சரத்துடன் (string) இணைப்பதன் மூலம் உருவாக்கப்படுகிறது. இந்தத் தரவு மின்னஞ்சல் சேவையைச் சென்றடைவதற்கு முன்பு, எந்தவிதமான 'escaping' அல்லது 'sanitisation' முறைகளும் செய்யப்படவில்லை.
இந்த டெம்ப்ளேட் (template) பயனரின் உள்ளீட்டைப் பாதுகாப்பான HTML என்று கருதுவதால், ஒரு தீய நோக்கமுள்ள விண்ணப்பதாரர் போலியான “click here to verify” என்ற இணைப்பை (link) உள்ளீடு செய்ய முடியும். இந்தத் தரவு (payload) வேலைவாய்ப்புப் பட்டியலின் ஒரு பகுதியாகச் சேவையகத்தில் (server) சேமிக்கப்படுவதால், அதன் பிறகு வரும் ஒவ்வொரு அறிவிப்பு மின்னஞ்சலிலும் இந்தத் தீய குறியீடு (malicious code) இடம்பெறும். ஒரு தாக்குதல் நடத்துபவர், அந்த இணைப்பை உண்மையான “View Dashboard” பொத்தானுக்கு அருகிலேயே மறைத்து வைத்து, குழு உறுப்பினரைத் தனது கடவுச்சொற்களை (credentials) வெளிப்படுத்தவோ அல்லது ஒரு ஃபிஷிங் தளத்திற்குச் செல்லவோ தூண்ட முடியும்.
இது ஏன் முக்கியமானது
இந்த மின்னஞ்சல்கள் முக்கியத் தேர்வு குழுவினருக்குச் செல்கின்றன; இவர்கள் விண்ணப்பதாரர்களை அடுத்தடுத்த நிலைகளுக்குக் கொண்டு செல்லத் தொடர்ந்து இணைப்புகளைக் கிளிக் செய்யும் நபர்கள் ஆவர்.
தொழில்நுட்ப இடைவெளி
HTML-ஐ 'escape' செய்வது என்பது ஒரு படிநிலை மட்டுமல்ல. இரண்டு சூழல்களில் பாதுகாப்பு தேவைப்படுகிறது:
- Text nodes – டேக்குகளுக்கு (tags) இடையிலான உள்ளடக்கம்.
<என்பதை<ஆகவும்,>என்பதை>ஆகவும் மாற்றுவது டேக்குகளைத் தடுக்கும், ஆனால் ஒரு தாக்குதல் நடத்துபவர் ஒரு 'attribute value'-லிருந்து வெளியேறுவதைத் தடுக்காது. - Attribute values –
href="…"போன்ற டேக்குகளுக்குள் இருக்கும் சரங்கள் (strings). ஒரு மேற்கோள் குறியீட்டை ("அல்லது') உள்ளீடு செய்வதன் மூலம், ஒரு தாக்குதல் நடத்துபவர் அந்த 'attribute'-ஐ முன்கூட்டியே முடித்துவிட்டு, தனது சொந்த மார்க்கப்பைப் (markup) புகுத்த முடியும்.
அசல் குறியீடு (original code) வெறும் சாதாரண உரையை (plain text) மட்டுமே கையாண்டது, இதனால் 'attribute injection' செய்ய வழிவகை ஏற்பட்டது.
சிக்கலைத் தீர்த்தல்
டெவலப்பர் ஒரு சிறிய escapeHtml உதவியாளரை (helper) உருவாக்கி, பயனர் வழங்கும் ஒவ்வொரு மதிப்பையும் (value), அது ஒரு 'text node'-ஆகவோ அல்லது 'attribute'-ஆகவோ இருந்தாலும், இணைப்பதற்கு (interpolation) முன்னரே அதைப் பயன்படுத்தினார்.
சரிபார்ப்புப் படிகள்
- Local testing – டெம்ப்ளேட் செயல்பாடுகளுக்கு (template functions) பல்வேறு 'injection strings' வழங்கப்பட்டன. ஒவ்வொரு சோதனையும் 'escaped characters'-களை மட்டுமே காட்டியது, இயங்கக்கூடிய டேக்குகள் (executable tags) எதுவும் இல்லை.
- Production testing – திருத்தத்தைச் (patch) செயல்படுத்திய பிறகு, நேரலைத் தளத்தின் (live site) மூலம் ஒரு 'payload' சமர்ப்பிக்கப்பட்டது, அது Cloudflare Turnstile பாட் (bot) சோதனையைத் தாண்டியது. அதன் விளைவாக வந்த மின்னஞ்சல் டெவலப்பரின் இன்பாக்ஸிற்கு வந்தது; அதில் இருந்த தீய இணைப்பு மற்றும் ஸ்கிரிப்ட் டேக்குகள் (script tags) கிளிக் செய்யக்கூடிய கூறுகளாக இல்லாமல், சிதைந்த உரையாகவே (garbled text) தோன்றின.
Gmail குறித்த குறிப்பு: அந்தச் சேவை ஒரு URL-ஐ நீல நிறமாக மாற்றி, அதை கிளிக் செய்யக்கூடியதாக வைத்திருக்கலாம், ஆனால் அது கிளையண்ட் பக்க வசதி (client-side convenience) மட்டுமே; அது HTML injection வெற்றி பெற்றுவிட்டது என்று அர்த்தமல்ல. இந்தத் திருத்தம், உண்மையான பொத்தான்களை உருவாக்கவோ அல்லது ஸ்கிரிப்ட்களை இயக்கவோ செய்யும் 'injection'-ஐத் தடுக்கிறது.
டெவலப்பர்கள் கவனிக்க வேண்டியவை
- பொதுவான படிவங்களிலிருந்து வரும் தரவை ஒருபோதும் நம்பாதீர்கள் – சாதாரணமானதாகத் தோன்றும் படிவங்கள் கூட, வேறு இடங்களில் பயன்படுத்தப்படும் 'stored output'-ஐ உருவாக்கக்கூடும்.
- பயன்படுத்தும் இடத்திலேயே 'escape' செய்யுங்கள் – தரவை ரெண்டர் (rendering) செய்வதற்குச் சரியாக முன்னதாகவே, சூழலுக்கு ஏற்ப (text vs. attribute) 'escaping'-ஐப் பயன்படுத்துங்கள்; குழாயின் (pipeline) ஆரம்பத்திலேயே செய்ய வேண்டாம்.
- கிளையண்ட் மற்றும் சர்வர் ஆகிய இரண்டையும் சோதியுங்கள் – யூனிட் டெஸ்ட்கள் (Unit tests) தெளிவான தோல்விகளைக் கண்டறியும்; நேரலை UI மூலம் செய்யப்படும் ஒரு கைமுறை 'end-to-end' சோதனை, உண்மையான டிராஃபிக் (traffic) சூழலில் பாதுகாப்புத் தடுப்புகள் சரியாகச் செயல்படுகின்றன என்பதை உறுதிப்படுத்தும்.
- மின்னஞ்சல் கிளையண்ட்களின் விசித்திரமான தன்மைகளைத் தெரிந்து கொள்ளுங்கள் – சில கிளையண்ட்கள் தானாகவே URL-களை இணைக்கும் (auto-link), இது ஒரு தவறான பாதுகாப்பு உணர்வை உருவாக்கும். அடிப்படையான HTML-இல் எந்தச் செயல்பாட்டு கூறுகளும் (active elements) இல்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.
சுருக்கம்
பயனர் உள்ளீட்டைக் கையாள்வதில் ஏற்பட்ட ஒரு சிறிய கவனக்குறைவு, வழக்கமான அறிவிப்பு மின்னஞ்சல்களை ஒரு ஃபிஷிங் கருவியாக (phishing vector) மாற்றியது. ஒரு விரிவான HTML-escaping முறையை அறிமுகப்படுத்தியதும், அதை உள்ளூர் மற்றும் நேரலைச் சூழல்களில் சரிபார்த்ததும் இன்பாக்ஸின் பாதுகாப்பை மீட்டெடுத்தது. நம்பகத்தன்மையற்ற தரவிலிருந்து HTML-ஐ உருவாக்கும் எந்தவொரு இணைய செயலிக்கும் (web app) இந்தச் சம்பவம் ஒரு காலத்தால் அழியாத பாடத்தைக் கற்பிக்கிறது: முறையான 'sanitisation' என்பது தவிர்க்க முடியாதது, அதை அலட்சியப்படுத்துவது உங்கள் பயனர்களின் இன்பாக்ஸிற்குத் தாக்குதலுக்கான நேரடி வழியைத் திறந்துவிடும்.