ஒரு React Bundle-இல் API Key: பாதிப்புக்குள்ளாக 33 நாட்கள்

நான் ஒரு பொதுவான React bundle-இல் API key-ஐ 33 நாட்களுக்கு விட்டுவிட்டேன்.

ஆம்ஸ்டர்டாமில் (Amsterdam) உள்ள ஒரு VPS எனது Brevo key-ஐப் பயன்படுத்தியது. Brevo அந்த மோசடியைக் கண்டறிந்து, எந்தப் பாதிப்பும் ஏற்படுவதற்கு முன்பே அதை ரத்து செய்துவிட்டது. நான் அதிர்ஷ்டசாலியாக இருந்தேன். பெரும்பாலானவர்கள் அப்படி இருக்க மாட்டார்கள்.

இது எப்படி நடந்தது மற்றும் நான் கற்றுக்கொண்ட பாடங்கள் இதோ.

The Mistake நான் ஒரு சிறிய கருவியை (tool) உருவாக்கி வந்தேன். எனது மற்ற திட்டங்கள் Brevo API-ஐ நேரடியாக frontend-லிருந்து அழைப்பதைக் கண்டேன். அது அங்கு வேலை செய்ததால், இந்த புதிய திட்டத்திலும் அதையே செய்தேன்.

நான் ஒரு விஷயத்தை உணரவில்லை. எனது மற்ற திட்டங்கள் பொதுவான production bundles-களை வெளியிடுவதில்லை. ஆனால் இது வெளியிட்டது.

Vite எனது API key-ஐ JavaScript கோப்பிற்குள் இணைத்துவிட்டது (inlined). இணையதளத்தைப் பார்வையிடும் எவரும் Ctrl+U அழுத்தி எனது ரகசியத் திறனை (secret key) பார்த்துவிட முடியும். GitHub repo தனிப்பட்டதாக (private) இருந்தது, ஆனால் bundle வடிவமைப்பிலேயே பொதுவானது (public). உலாவிகள் (browsers) அவ்வாறே செயல்படுகின்றன.

The False Sense of Security Key-ஐ மாற்றுவது (rotating) அனைத்தையும் சரிசெய்துவிடும் என்று நான் நினைத்தேன். ஆனால் அது நடக்கவில்லை. நான் இரண்டு முக்கிய சிக்கல்களைச் சந்தித்தேன்:

  • Cloudflare Pages: நான் dashboard-இல் ரகசியத் திறனைப் புதுப்பித்தேன். ஆனால் இணையதளம் இன்னும் பழைய key-யையே பயன்படுத்தியது. Cloudflare ரகசியங்களை deploy செய்யும் நேரத்தில் இணைக்கிறது, request செய்யும் நேரத்தில் அல்ல. மாற்றங்கள் நடைமுறைக்கு வர நீங்கள் மீண்டும் redeploy செய்ய வேண்டும்.

  • Azure App Service (.NET): நான் Application Settings-ஐப் புதுப்பித்தேன். ஆனால் இயங்கிக் கொண்டிருந்த செயல்முறை (running process) பழைய key-யையே தொடர்ந்து பயன்படுத்தியது. நான் அந்த key-ஐ ஒரு singleton HttpClient-க்குள் செலுத்தியதால் (injected) இது நடந்தது. ஆப் (app) புதிய மதிப்பை மீண்டும் படிக்கவில்லை. நான் App Service-ஐ கைமுறையாக (manually) மறுதொடக்கம் செய்ய வேண்டியிருந்தது.

The Attacker Strategy தாக்குபவர் அந்த key-ஐ மட்டும் பயன்படுத்தவில்லை. அவர்கள் Brevo-வின் auto-allowlist அம்சத்தைப் பயன்படுத்தினர். பல வாரங்களாக அவர்கள் தங்களது IP முகவரிகளை எனது நம்பகமான பட்டியலில் (trusted list) சேர்த்தனர். பின்னர் அமைதியாகச் செயல்படத் தேவையான நம்பிக்கையை அவர்கள் கட்டியெழுப்பிக் கொண்டிருந்தனர்.

My Lessons Learned

  • ஒருபோதும் frontend bundle-இல் API key-ஐ வைக்காதீர்கள். உங்கள் கோரிக்கைகளை (requests) proxy செய்ய எப்போதும் ஒரு backend function-ஐப் பயன்படுத்துங்கள். frontend ஒருபோதும் ரகசியத் திறனைப் பார்க்கக்கூடாது.

  • பிரித்தெடுத்தலைப் (segmentation) பயன்படுத்துங்கள். அனைத்திற்கும் ஒரே key-யைப் பயன்படுத்தாதீர்கள். இப்போது நான் ஒவ்வொரு deployment target-க்கும் ஒரு தனித்துவமான key-யைப் பயன்படுத்துகிறேன். ஒன்று கசிந்தாலும், மற்றவை பாதுகாப்பாக இருக்கும்.

  • serverless சூழல்களில் auto-allowlists-களை நம்பியிருக்க வேண்டாம். அவை கணிக்க முடியாதவை.

  • ஒரு rotation playbook-ஐ உருவாக்குங்கள். ஒரு key-ஐப் புதுப்பிப்பது என்பது ஒரு ஒற்றை, நம்பகமான செயல்முறையாக இருக்க வேண்டும்; பல்வேறு தளங்களில் மேற்கொள்ளப்படும் தொடர்ச்சியான கைமுறைப் படிகளாக இருக்கக்கூடாது.

பாதுகாப்புப் பணி மிக முக்கியமான தருணம் வரும் வரை பயனற்றதாகத் தோன்றும். தேவைப்படும் முன்பே உங்கள் rotation படிகளைத் தயார் செய்து கொள்ளுங்கள்.

Source: https://dev.to/lainagent_ai/an-api-key-in-a-react-bundle-33-days-to-compromise-2mi6

விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi