GET ಕಲೆಕ್ಷನ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಲ್ಲಿನ ಒಂದು ಸೆಕ್ಯೂರಿಟಿ ಚೆಕ್ ಮಿಸ್ ಆಗಿದ್ದರಿಂದ, ಸಾಮಾನ್ಯ CoopCycle ಖಾತೆಯನ್ನು ಹೊಂದಿರುವ ಯಾರೇ ಆದವರು ಹಂಚಿಕೆಯ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಲ್ಲಿರುವ (shared instance) ಪ್ರತಿಯೊಂದು ಮಳಿಗೆಯ ಸಂಪೂರ್ಣ ವಿಳಾಸ ಪುಸ್ತಕವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಯಿತು. ಇದರಿಂದ ಅಸಂಖ್ಯಾತ ಗ್ರಾಹಕರ ಹೆಸರುಗಳು, ಬೀದಿ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋಸ್ಟ್‌ಕೋಡ್‌ಗಳು ಬಹಿರಂಗಗೊಂಡವು. ಈ ದೋಷವನ್ನು ಎರಡು ದಿನಗಳಲ್ಲೇ ಸರಿಪಡಿಸಲಾಯಿತು (patched), ಮತ್ತು ಬಳಕೆದಾರರು ಬಿಡುಗಡೆಯಾದ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಬೇಕೆಂದು ಸೂಚಿಸಲಾಗಿದೆ.

ಸೋರಿಕೆ ಹೇಗೆ ಸಂಭವಿಸಿತು

CoopCycle – ಆಹಾರ ವಿತರಣಾ ಸಹಕಾರ ಸಂಘಗಳು ಬಳಸುವ ಒಂದು ಓಪನ್-ಸೋರ್ಸ್ ಲಾಜಿಸ್ಟಿಕ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ – ತನ್ನ API ಅನ್ನು PHP ಫ್ರೇಮ್‌ವರ್ಕ್ API Platform ಬಳಸಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಆ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಪ್ರತಿ ಆಪರೇಷನ್ (POST, GET, ಇತ್ಯಾದಿ) ಒಂದು ಸೆಕ್ಯೂರಿಟಿ ಎಕ್ಸ್‌ಪ್ರೆಶನ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಲ್ಪಟ್ಟಿರಬೇಕು; ಒಂದು ವೇಳೆ ಆ ಎಕ್ಸ್‌ಪ್ರೆಶನ್ ಅನ್ನು ಬಿಟ್ಟರೆ, ಫ್ರೇಮ್‌ವರ್ಕ್ ಯಾವುದೇ ಅಧಿಕಾರೀಕರಣದ ಪರಿಶೀಲನೆ (authorization check) ಇಲ್ಲದೆ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಮಳಿಗೆಯ ವಿಳಾಸ ಪಟ್ಟಿಯನ್ನು ರಚಿಸುವ ಅಥವಾ ಅಪ್‌ಡೇಟ್ ಮಾಡುವ POST ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಪ್ರಮಾಣಿತ ಎಕ್ಸ್‌ಪ್ರೆಶನ್ is_granted('edit', object) ಮೂಲಕ ರಕ್ಷಿಸಿದ್ದರು. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ರಿಕ್ವೆಸ್ಟ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಳಿಗೆ ಎಂಟಿಟಿಯನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿರುತ್ತದೆ, ಇದು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಒಂದು ನಿರ್ದಿಷ್ಟ "object" ಅನ್ನು ನೀಡುತ್ತದೆ.

ಅದೇ ಸಂಪನ್ಮೂಲವನ್ನು ಓದುವ GET ರಿಕ್ವೆಸ್ಟ್ ಒಂದು ಕಲೆಕ್ಷನ್ ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದೆ: /api/stores/{id}/addresses. ಕಲೆಕ್ಷನ್‌ಗೆ ಯಾವುದೇ ಏಕೈಕ ಆಬ್ಜೆಕ್ಟ್ ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದೇ is_granted('edit', object) ಎಕ್ಸ್‌ಪ್ರೆಶನ್ ಅನ್ನು ಅನ್ವಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಡೆವಲಪರ್‌ಗಳು ಸೆಕ್ಯೂರಿಟಿ ಲೈನ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದ್ದರಿಂದ, ಫ್ರೇಮ್‌ವರ್ಕ್ ಯಾವುದೇ ಟೆನೆನ್ಸಿ (tenancy) ಲೆಕ್ಕಿಸದೆ, ಅಧಿಕೃತ ಬಳಕೆದಾರರಿಗೆ ವಿಳಾಸದ ಡೇಟಾವನ್ನು ಒದಗಿಸಿತು.

ಹಂಚಿಕೆಯ CoopCycle ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಲ್ಲಿ, ದುರುದ್ದೇಶಪೂರಿತ ಬಳಕೆದಾರರು ಕೇವಲ ಸ್ಟೋರ್ ಐಡಿಗಳ ಮೂಲಕ ಸಂಚರಿಸುತ್ತಾ (iterate), ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ GET ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಪ್ರತಿಯೊಬ್ಬ ಗ್ರಾಹಕರ ಮನೆ ವಿಳಾಸಗಳನ್ನು ಸ್ಕ್ರೇಪ್ (scrape) ಮಾಡಬಹುದಿತ್ತು. ಇದಕ್ಕೆ ಸಾಮಾನ್ಯ ಖಾತೆಯ ಹೊರತಾಗಿ ಯಾವುದೇ ಹೆಚ್ಚಿನ ಅಧಿಕಾರಗಳ ಅಗತ್ಯವಿರಲಿಲ್ಲ.

ಈ ಬಗ್ ಏಕೆ ಉಳಿದುಕೊಂಡಿತು

ಈ ಸಮಸ್ಯೆ ಕೇವಲ ಒಂದು ಸಣ್ಣ ಅಜಾಗರೂಕತೆಯಲ್ಲ. API Platform ನ ಡಿಕ್ಲರೇಟಿವ್ ಸೆಕ್ಯೂರಿಟಿ ಮಾಡೆಲ್‌ನಲ್ಲಿ "ಬಳಕೆದಾರನು ಕಲೆಕ್ಷನ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಸೇರಿದ ಒಂದೇ ಟೆನೆಂಟ್‌ಗೆ (tenant) ಸೇರಿರಬೇಕು" ಎಂದು ವ್ಯಕ್ತಪಡಿಸಲು ನೇರವಾದ ಮಾರ್ಗವಿಲ್ಲ. ಫ್ರೇಮ್‌ವರ್ಕ್ ಅಧಿಕಾರೀಕರಣವನ್ನು ಕಷ್ಟಕರವಾಗಿಸಿದ ಜಾಗದಲ್ಲೇ ಈ ಕೋಡ್ ಲೈನ್ ಮಿಸ್ ಆಗಿತ್ತು.

ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಉಲ್ಬಣಗೊಳಿಸಿದ್ದು ಏನೆಂದರೆ, ಪ್ರಾಜೆಕ್ಟ್‌ನ ಟೆಸ್ಟ್ ಸೂಟ್ (test suite) ಎಲ್ಲಾ ವಿಳಾಸಗಳನ್ನು ಒಳಗೊಂಡ GET ರೆಸ್ಪಾನ್ಸ್ ನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಯಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿತ್ತು. ಅಂದರೆ, ಟೆಸ್ಟಿಂಗ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಫಿಕ್ಚರ್‌ಗಳು (fixtures) ಕ್ರಾಸ್-ಟೆನೆಂಟ್ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಿದ್ದರಿಂದ ಆಟೋಮೇಟೆಡ್ ಟೆಸ್ಟ್‌ಗಳು ಪಾಸಾದವು, ಇದು ಅಸಲಿ ದೋಷವನ್ನು ಮರೆಮಾಚಿತು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪಾಸಾದ ಟೆಸ್ಟ್ ಸೂಟ್ ಒಂದು ಸುಳ್ಳು ಭದ್ರತೆಯ ಭಾವನೆಯನ್ನು ನೀಡಿತು.

ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ ಮತ್ತು ಯಾರು ಸೋಲುತ್ತಾರೆ

  • ಗ್ರಾಹಕರು: ಅವರ ವೈಯಕ್ತಿಕವಾಗಿ ಗುರುತಿಸಬಹುದಾದ ಮಾಹಿತಿ (PII) – ಪೂರ್ಣ ಹೆಸರುಗಳು ಮತ್ತು ಮನೆ ವಿಳಾಸಗಳು – ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿರುವ ಯಾರಿಗಾದರೂ ಲಭ್ಯವಾಯಿತು. ಡೇಟಾವನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಪೋಸ್ಟ್ ಮಾಡದಿದ್ದರೂ ಸಹ, ಈ ಉಲ್ಲಂಘನೆಯು ಹಲವಾರು ಸಹಕಾರ ಸಂಘಗಳ ಗೌಪ್ಯತೆಯನ್ನು ಹಾಳುಮಾಡಿತು.
  • CoopCycle ಬಳಸುವ ಸಹಕಾರ ಸಂಘಗಳು: ಟೆನೆಂಟ್ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸಾಮರ್ಥ್ಯದ ಮೇಲಿನ ನಂಬಿಕೆ ಕುಸಿಯಿತು. ಇನ್ನೂ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡದ ಯಾವುದೇ ಸಹಕಾರ ಸಂಘವು ಡೇಟಾ ಸೋರಿಕೆಯ ಅಪಾಯವನ್ನು ಎದುರಿಸಬೇಕಾಯಿತು.
  • CoopCycle ನಿರ್ವಾಹಕರು (maintainers): ಅವರ ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆ – ಎರಡು ದಿನಗಳೊಳಗೆ ಪ್ಯಾಚ್ ಮತ್ತು ರಿಗ್ರೆಷನ್ ಟೆಸ್ಟ್‌ಗಳ ಸೇರ್ಪಡೆ – ದುರುಪಯೋಗದ ಸಮಯವನ್ನು ಸೀಮಿತಗೊಳಿಸಿತು ಮತ್ತು ಜವಾಬ್ದಾರಿಯುತ ಓಪನ್-ಸೋರ್ಸ್ ನಿರ್ವಹಣೆಯನ್ನು ಪ್ರದರ್ಶಿಸಿತು. ಆದಾಗ್ಯೂ, ಈ ಘಟನೆಯು ವಿಶೇಷವಾಗಿ ಫ್ರೇಮ್‌ವರ್ಕ್-ಚಾಲಿತ ಡಿಫಾಲ್ಟ್‌ಗಳ ಸುತ್ತ ಕಟ್ಟುನಿಟ್ಟಾದ ಸೆಕ್ಯೂರಿಟಿ ರಿವ್ಯೂ ಪ್ರಕ್ರಿಯೆಗಳ ಅಗತ್ಯವನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಆಡಿಟರ್‌ಗಳು ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • ಆಪರೇಷನ್ ಅಸಿಮೆಟ್ರಿ (Operation asymmetry): ಒಂದು ಪಾತ್‌ನಲ್ಲಿ POST (ಅಥವಾ ಯಾವುದೇ ಬದಲಾವಣೆ ಮಾಡುವ ಆಪರೇಷನ್) ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದ್ದರೆ ಆದರೆ ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ GET ಮುಕ್ತವಾಗಿದ್ದರೆ, ಆ ವ್ಯತ್ಯಾಸವು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತವಾಗಿದೆ. POST ರಿಕ್ಯೂಸ್ಟ್ ಸಂಪನ್ಮೂಲವನ್ನು ರಕ್ಷಿಸುವ ಡೆವಲಪರ್‌ಗಳ ಉದ್ದೇಶವನ್ನು ತೋರಿಸುತ್ತದೆ.
  • ಕಲೆಕ್ಷನ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು: ಏಕೈಕ ಐಟಂ ಬದಲಿಗೆ ಪಟ್ಟಿಯನ್ನು (list) ನೀಡುವ ಯಾವುದೇ ವಿಷಯವು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಮಾನ್ಯ ಸೆಕ್ಯೂರಿಟಿ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಹೊರಗಡೆ ಇರುತ್ತದೆ. ಬಲ್ಕ್ ರೀಡ್‌ಗಳಿಗಾಗಿ (bulk reads) ಅಧಿಕಾರೀಕರಣದ ಪರಿಶೀಲನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೇರಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
  • ಟೆಸ್ಟ್ ಸೂಟ್ ವಾಸ್ತವಿಕತೆ: ಫಿಕ್ಚರ್‌ಗಳು ನೈಜ ಟೆನೆನ್ಸಿ ಗಡಿಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಕ್ರಾಸ್-ಟೆನೆಂಟ್ ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ದೃಢೀಕರಿಸುವ ಪಾಸಾದ ಟೆಸ್ಟ್ ಒಂದು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತವೇ ಹೊರತು ಹಸಿರು ದೀಪವಲ್ಲ.

ಪರಿಹಾರ ಮತ್ತು ಮುಂದಿನ ಹಂತಗಳು

ದೋಷದ ಬಗ್ಗೆ ವರದಿ ಮಾಡಿದ ನಂತರ, CoopCycle ಕೋರ್ ತಂಡವು GET ಕಲೆಕ್ಷನ್ ಆಪರೇಷನ್‌ಗೆ ಮಿಸ್ ಆಗಿದ್ದ ಸೆಕ್ಯೂರಿಟಿ ಎಕ್ಸ್‌ಪ್ರೆಶನ್ ಅನ್ನು ಸೇರಿಸಿತು ಮತ್ತು ಏಕೈಕ-ಐಟಂ ಹಾಗೂ ಕಲೆಕ್ಷನ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳೆರಡಕ್ಕೂ ಟೆನೆಂಟ್ ಐಸೊಲೇಶನ್ ಅನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುವ ರಿಗ್ರೆ

ಭದ್ರತೆಯನ್ನು ಘೋಷಣಾತ್ಮಕವಾಗಿ (declarative) ಮಾಡುವ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು, ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು ಕೇವಲ ಏಕೈಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯವಾಗುವ ಮಾದರಿಗಳನ್ನು ಅವಲಂಬಿಸಿದಾಗ ಅಪಾಯಕಾರಿ ಲೋಪದೋಷಗಳನ್ನು ಮರೆಮಾಚಬಹುದು. ಒಂದು ಸರಳ ಪರಿಶೀಲನೆ—ಎಂಡ್ ಪಾಯಿಂಟ್‌ನ ರೀಡ್ ಸೈಡ್ (read side), ರೈಟ್ ಸೈಡ್‌ನಂತೆಯೇ ರಕ್ಷಣಾತ್ಮಕ ವ್ಯವಸ್ಥೆಯನ್ನು (guard) ಹೊಂದಿದೆಯೇ?—ಎಂಬುದು, ಇಲ್ಲದಿದ್ದರೆ ಹಸಿರು ಟೆಸ್ಟ್ ಸೂಟ್‌ಗಳ (green test suites) ಹಿಂದೆ ಮರೆಯಾಗಿರುತ್ತಿದ್ದ ಕ್ರಾಸ್-ಟ್ಯಾನೆಂಟ್ ಸೋರಿಕೆಗಳ (cross-tenant leaks) ಒಂದು ವರ್ಗವನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.