𝗥𝗲𝗮𝗰𝘁 𝗕𝘂𝗻𝗱𝗹𝗲 ನಲ್ಲಿ 𝗔𝗣𝗜 𝗞𝗲𝘆: 𝟯𝟯 ದಿನಗಳ ಕಾಲ ಸಂಭವಿಸಿದ ಅಪಾಯ

ನಾನು 33 ದಿನಗಳ ಕಾಲ ಸಾರ್ವಜನಿಕ React bundle ನಲ್ಲಿ API key ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದ್ದೆ.

Amsterdam ನಲ್ಲಿರುವ ಒಂದು VPS ನನ್ನ Brevo key ಅನ್ನು ಬಳಸಿಕೊಂಡಿತು. ಯಾವುದೇ ಹಾನಿಯಾಗುವ ಮೊದಲೇ Brevo ವಂಚನೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಅದನ್ನು ರದ್ದುಗೊಳಿಸಿತು. ನಾನು ಅದೃಷ್ಟವಂತನಾಗಿದ್ದೆ. ಹೆಚ್ಚಿನ ಜನರು ಅಷ್ಟು ಅದೃಷ್ಟವಂತರಾಗಿರುವುದಿಲ್ಲ.

ಇದು ಹೇಗೆ ಸಂಭವಿಸಿತು ಮತ್ತು ನಾನು ಏನು ಕಲಿತೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಮಾಡಿದ ತಪ್ಪೆ

ನಾನು ಒಂದು ಸಣ್ಣ ಟೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೆ. ನನ್ನ ಇತರ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಫ್ರಂಟ್‌ಎಂಡ್‌ನಿಂದಲೇ ನೇರವಾಗಿ Brevo API ಅನ್ನು ಕರೆಯುತ್ತಿರುವುದನ್ನು ನಾನು ಗಮನಿಸಿದೆ. ಅಲ್ಲಿ ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರಿಂದ, ನಾನು ಈ ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್‌ಗೂ ಅದೇ ರೀತಿ ಮಾಡಿದೆ.

ನಾನು ಒಂದು ವಿಷಯವನ್ನು ಗಮನಿಸಲಿಲ್ಲ. ನನ್ನ ಇತರ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಸಾರ್ವಜನಿಕ production bundles ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ ಇದು ಮಾಡಿತು.

Vite ನನ್ನ API key ಅನ್ನು JavaScript ಫೈಲ್‌ಗೆ ಇನ್‌ಲೈನ್ (inline) ಮಾಡಿತು. ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡುವ ಯಾರೇ ಆದರೂ Ctrl+U ಒತ್ತಿ ನನ್ನ ಸೀಕ್ರೆಟ್ ಕೀಯನ್ನು ನೋಡಬಹುದು. GitHub repo ಖಾಸಗಿಯಾಗಿತ್ತು (private), ಆದರೆ bundle ವಿನ್ಯಾಸದ ಪ್ರಕಾರವೇ ಸಾರ್ವಜನಿಕವಾಗಿದೆ (public). ಬ್ರೌಸರ್ಗಳು ಕೆಲಸ ಮಾಡುವುದು ಹೀಗೆಯೇ.

ಸುಳ್ಳು ಭದ್ರತೆಯ ಭಾವನೆ

ಕೀಯನ್ನು ರೊಟೇಟ್ (rotate) ಮಾಡುವುದರಿಂದ ಎಲ್ಲವೂ ಸರಿಹೋಗುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. ಆದರೆ ಹಾಗಾಗಲಿಲ್ಲ. ನಾನು ಎರಡು ಪ್ರಮುಖ ತಪ್ಪುಗಳಿಗೆ ಸಿಲುಕಿದೆ:

  • Cloudflare Pages: ನಾನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಸೀಕ್ರೆಟ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿದೆ. ಆದರೂ ಸೈಟ್ ಹಳೆಯ ಕೀಯನ್ನೇ ಬಳಸುತ್ತಿತ್ತು. Cloudflare ಸೀಕ್ರೆಟ್‌ಗಳನ್ನು ಡಿಪ್ಲಾಯ್ ಮಾಡುವ ಸಮಯದಲ್ಲಿ (deploy time) ಬೈಂಡ್ ಮಾಡುತ್ತದೆ, ರಿಕ್ವೆಸ್ಟ್ ಮಾಡುವ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ. ಬದಲಾವಣೆಯು ಅನ್ವಯವಾಗಲು ನೀವು ಮರು-ಡಿಪ್ಲಾಯ್ (redeploy) ಮಾಡಲೇಬೇಕು.

  • Azure App Service (.NET): ನಾನು Application Settings ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿದೆ. ಆದರೆ ಚಾಲನೆಯಲ್ಲಿದ್ದ ಪ್ರಕ್ರಿಯೆಯು (running process) ಹಳೆಯ ಕೀಯನ್ನೇ ಬಳಸುತ್ತಿತ್ತು. ಏಕೆಂದರೆ ನಾನು ಕೀಯನ್ನು singleton HttpClient ಗೆ ಇಂಜೆಕ್ಟ್ ಮಾಡಿದ್ದೆ. ಅಪ್ಲಿಕೇಶನ್ ಹೊಸ ಮೌಲ್ಯವನ್ನು ಮತ್ತೆ ಓದಲಿಲ್ಲ. ನಾನು App Service ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ರೀಸ್ಟಾರ್ಟ್ ಮಾಡಬೇಕಾಯಿತು.

ದಾಳಿಕೋರನ ತಂತ್ರ

ದಾಳಿಕೋರ ಕೇವಲ ಕೀಯನ್ನು ಬಳಸಲಿಲ್ಲ. ಅವರು Brevo ನ auto-allowlist ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಿದರು. ಅವರು ಹಲವಾರು ವಾರಗಳ ಕಾಲ ನನ್ನ ನಂಬಿಕಸ್ತ ಪಟ್ಟಿಗೆ (trusted list) ತಮ್ಮದೇ ಆದ IP ಗಳನ್ನು ಸೇರಿಸಿದರು. ನಂತರ ಯಾವುದೇ ಅನುಮಾನ ಬರದಂತೆ ಕೆಲಸ ಮಾಡಲು ಅವರು ನಂಬಿಕೆಯನ್ನು ಗಳಿಸುತ್ತಿದ್ದರು.

ನಾನು ಕಲಿತ ಪಾಠಗಳು

  • ಫ್ರಂಟ್‌ಎಂಡ್ ಬಂಡಲ್‌ಗಳಲ್ಲಿ ಎಂದಿಗೂ API key ಅನ್ನು ಇರಿಸಬೇಡಿ. ನಿಮ್ಮ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ಪ್ರೊಕ್ಸಿ (proxy) ಮಾಡಲು ಯಾವಾಗಲೂ ಬ್ಯಾಕ್‌ಎಂಡ್ ಫಂಕ್ಷನ್ ಬಳಸಿ. ಫ್ರಂಟ್‌ಎಂಡ್ ಎಂದಿಗೂ ಸೀಕ್ರೆಟ್ ಅನ್ನು ನೋಡಬಾರದು.

  • ಸೆಗ್ಮೆಂಟೇಶನ್ (segmentation) ಬಳಸಿ. ಎಲ್ಲದಕ್ಕೂ ಒಂದೇ ಕೀಯನ್ನು ಬಳಸಬೇಡಿ. ಈಗ ನಾನು ಪ್ರತಿ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಟಾರ್ಗೆಟ್‌ಗೆ ಒಂದು ವಿಶಿಷ್ಟ ಕೀಯನ್ನು ಬಳಸುತ್ತೇನೆ. ಒಂದು ಸೋರಿಕೆಯಾದರೆ, ಉಳಿದವು ಸುರಕ್ಷಿತವಾಗಿರುತ್ತವೆ.

  • ಸರ್ವರ್‌ಲೆಸ್ (serverless) ಪರಿಸರಗಳಲ್ಲಿ auto-allowlist ಗಳನ್ನು ಅವಲಂಬಿಸಬೇಡಿ. ಅವು ಅನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತವೆ.

  • ರೊಟೇಶನ್ ಪ್ಲೇಬುಕ್ (rotation playbook) ಸಿದ್ಧಪಡಿಸಿಕೊಳ್ಳಿ. ಕೀಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು ಒಂದು ಸುಲಭ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಕ್ರಿಯೆಯಾಗಿರಬೇಕು, ವಿವಿಧ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಮಾಡುವ ಮ್ಯಾನುಯಲ್ ಹಂತಗಳ ಸರಣಿಯಾಗಿರಬಾರದು.

ಭದ್ರತಾ ಕೆಲಸವು ಅತ್ಯಗತ್ಯವಾಗುವ ಕ್ಷಣದವರೆಗೆ ಅದು ಪ್ರಯೋಜನವಿಲ್ಲದಂತೆ ಅನಿಸುತ್ತದೆ. ನಿಮಗೆ ಅಗತ್ಯವಾಗುವ ಮೊದಲೇ ನಿಮ್ಮ ರೊಟೇಶನ್ ಹಂತಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿಕೊಳ್ಳಿ.

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

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi