InvoiceShelf ಸಂಸ್ಥೆಯು CVE-2026-55610 ಗಾಗಿ ಒಂದು ಪ್ಯಾಚ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಇದು ಒಂದು ಗಂಭೀರ ದೋಷವಾಗಿದ್ದು, ಒಂದು ಕಂಪನಿಯ ಯಾವುದೇ ಮಾಲೀಕರು ಮತ್ತೊಂದು ಕಂಪನಿಯ ಬಳಕೆದಾರರ ಖಾತೆಗಳನ್ನು ಹೈಜಾಕ್ ಮಾಡಲು ಇದು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಿತ್ತು. CVSS ಪ್ರಮಾಣದಲ್ಲಿ 8.7 ರೇಟಿಂಗ್ ಹೊಂದಿರುವ ಈ ದುರ್ಬಲತೆಯು ಅಪ್ಲಿಕೇಶನ್‌ನ Laravel ಕೋಡ್‌ನಲ್ಲಿ 'tenant-scope' ಪರಿಶೀಲನೆ ಇಲ್ಲದಿರುವುದರಿಂದ ಉಂಟಾಗಿದೆ.

ಈ ದೋಷವು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು

InvoiceShelf ಎಂಬುದು Laravel ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಒಂದು SaaS ಟೂಲ್ ಆಗಿದ್ದು, ಇದು ಕಂಪನಿಗಳು ಬಳಕೆದಾರರು, ಇನ್‌ವಾಯ್ಸ್‌ಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಂದೇ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಿಂದ ನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಟೆನೆಂಟ್ ಅನ್ನು ಗುರುತಿಸಲು ಒಂದು ಕಸ್ಟಮ್ ಹೆಡರ್ ಅನ್ನು ಓದುತ್ತದೆ. ಒಬ್ಬ ಮಾಲೀಕರು (Owner) ಬಳಕೆದಾರರ ದಾಖಲೆಯನ್ನು ವಿನಂತಿಸಿದಾಗ, ಕೋಡ್ ಕೇವಲ "ವಿನಂತಿಸಿದವರು ತಮ್ಮ ಸ್ವಂತ ಕಂಪನಿಯ ಮಾಲೀಕರೇ?" ಎಂದು ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತದೆ.

ಗುರಿ ಹೊಂದಿರುವ ಬಳಕೆದಾರರು ಅದೇ ಟೆನೆಂಟ್‌ಗೆ ಸೇರಿದವರೇ ಎಂದು ಇದು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. Laravel ನ 'implicit route-model binding' ಬಳಕೆದಾರರ ID ಅನ್ನು ಗ್ಲೋಬಲ್ ಬಳಕೆದಾರರ ಟೇಬಲ್‌ನಲ್ಲಿರುವ ಒಂದು ಸಾಲಿಗೆ (row) ಲಿಂಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಧಿಕಾರ ನೀತಿಯು (authorization policy) ಕೇವಲ ವಿನಂತಿಸಿದವರ ಪಾತ್ರದ (role) ಆಧಾರದ ಮೇಲೆ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ, ಒಬ್ಬ ದಾಳಿಕೋರನು:

  • ವಿನಂತಿ URL ನಲ್ಲಿ ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರ ID ಅನ್ನು ನೀಡಬಹುದು.
  • ಇಮೇಲ್ ಸೇರಿದಂತೆ ಸಂಪೂರ್ಣ ಬಳಕೆದಾರರ ದಾಖಲೆಯನ್ನು ಪಡೆಯಬಹುದು.
  • ಬಲಿಪಶುವಿನ ಇಮೇಲ್, ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಪ್‌ಡೇಟ್ ನೀಡಬಹುದು ಮತ್ತು ಅಕೌಂಟ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸಿ ದಾಳಿಕೋರನ ಕಂಪನಿಗೆ 'super-admin' ಆಗಿ ಮರುಹಂಚಿಕೆ ಮಾಡಬಹುದು.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಒಬ್ಬ ದುರುದ್ದೇಶಪೂರಿತ ಮಾಲೀಕರು ಕಂಪನಿ-ನಿರ್ವಹಣಾ ಸಾಧನವನ್ನು ಸಾರ್ವತ್ರಿಕ ಅಕೌಂಟ್-ಟೇಕ್ ಓವರ್ (account-takeover) ಅಸ್ತ್ರವಾಗಿ ಪರಿವರ್ತಿಸಿದರು. ಇದಕ್ಕೆ "Owner" ಪಾತ್ರಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಅಧಿಕಾರಗಳ ಅಗತ್ಯವಿರಲಿಲ್ಲ.

ಯಾರು ಬಾಧಿತರಾಗಿದ್ದಾರೆ

2.4.1 ಕ್ಕಿಂತ ಹಿಂದಿನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತಿರುವ ಪ್ರತಿಯೊಬ್ಬ InvoiceShelf ಗ್ರಾಹಕರು ಇದಕ್ಕೆ ತುತ್ತಾಗಿದ್ದಾರೆ. ಈ ದೋಷವು ಕೋರ್ ರಿಕ್ವೆಸ್ಟ್-ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಪಥದಲ್ಲಿರುವುದರಿಂದ, ಯಾವುದೇ ಟೆನೆಂಟ್‌ನ ಗಾತ್ರ ಅಥವಾ ಭದ್ರತಾ ಸ್ಥಿತಿಯನ್ನು ಲೆಕ್ಕಿಸದೆ, ಯಾವುದೇ ಟೆನೆಂಟ್‌ನ ಮಾಲೀಕರು ಮತ್ತೊಬ್ಬ ಟೆನೆಂಟ್ ಅನ್ನು ಗುರಿಯಾಗಿಸಬಹುದು. ಇದರ ಪರಿಣಾಮವು ಗೌಪ್ಯತೆಯ ನಷ್ಟ (ಇಮೇಲ್ ವಿಳಾಸಗಳು) ಮತ್ತು ಸಮಗ್ರತೆಯ ನಷ್ಟವನ್ನು (ಅನಧಿಕೃತ ಪಾಸ್‌ವರ್ಡ್ ಬದಲಾವಣೆಗಳು, super-admin ಗೆ ಏರಿಕೆ) ಒಳಗೊಂಡಿದೆ.

ಪ್ಯಾಚ್ (ತಿದ್ದುಪಡಿ)

ಡೆವಲಪರ್‌ಗಳು ಆವೃತ್ತಿ 2.4.1 ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದಾರೆ, ಇದು ಬಳಕೆದಾರರ ದಾಖಲೆಯ ಮೇಲೆ ಯಾವುದೇ ಓದು ಅಥವಾ ಬರೆಯುವ ಪ್ರಕ್ರಿಯೆಗಿಂತ ಮೊದಲು ಸ್ಪಷ್ಟವಾದ ಟೆನೆಂಟ್ ಪರಿಶೀಲನೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಈ ಪರಿಹಾರವು ಕ್ವೇರಿಯನ್ನು ಸಕ್ರಿಯ ಕಂಪನಿ ಐಡೆಂಟಿಫೈಯರ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಇದರಿಂದ Laravel ಕೇವಲ ವಿನಂತಿಸಿದವರ ಟೆನೆಂಟ್‌ಗೆ ಸೇರಿದ ಸಾಲುಗಳನ್ನು (rows) ಮಾತ್ರ ನೀಡುವಂತೆ ಮಾಡುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಏನು ಕಲಿಯಬೇಕು

  • ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಎಂದಿಗೂ ಗ್ಲೋಬಲ್ ಪ್ರೈಮರಿ ಕೀಗಳನ್ನು ಅವಲಂಬಿಸಬೇಡಿ.
  • ಕೇವಲ ಡಿಲೀಟ್ ಅಥವಾ ಕ್ರಿಯೇಟ್ ಕ್ರಮಗಳಿಗೆ ಮಾತ್ರವಲ್ಲದೆ, ಪ್ರತಿಯೊಂದು ಡೇಟಾಬೇಸ್ ಲುಕ್‌ಅಪ್‌ಗೆ ಟೆನೆಂಟ್ ಫಿಲ್ಟರ್ ಅನ್ನು ಅನ್ವಯಿಸಿ.
  • ಅಧಿಕಾರ ನೀತಿಗಳು (authorization policies) ಕೇವಲ ಕಾರ್ಯನಿರ್ವಹಿಸುವವರ ಪಾತ್ರವನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಗುರಿ ವಸ್ತುವಿನ (target object) ಟೆನೆನ್ಸಿ ಅನ್ನದೂ ಪರಿಶೀಲಿಸುವಂತೆ ಮಾಡಿ.
  • ನೀವು ಸ್ಪಷ್ಟವಾದ ಸ್ಕೋಪಿಂಗ್ ಅನ್ನು ಸೇರಿಸದ ಹೊರತು, route-model binding ನಂತಹ ಇಂಪ್ಲಿಸಿಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಭದ್ರತಾ ಲೋಪಗಳನ್ನು ಮರೆಮಾಚಬಲ್ಲ ಸೌಲಭ್ಯಗಳೆಂದು ಪರಿಗಣಿಸಿ.

ಮುಂದಿನ ದೃಷ್ಟಿಕೋನ

ಈ ಘಟನೆಯು ಟೇಬಲ್‌ಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಯಾವುದೇ SaaS ಗೆ ಇರುವ ವಿಶಾಲವಾದ ಅಪಾಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ಭದ್ರತಾ ಆಡಿಟ್‌ಗಳು (Security audits) ಐಡೆಂಟಿಫೈಯರ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಎಲ್ಲಾ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಟೆನೆಂಟ್ ಸ್ಕೋಪಿಂಗ್ ಅನ್ನು ಏಕರೂಪವಾಗಿ ಜಾರಿಗೆ ತರಲಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.

ಸಾರಾಂಶ: ಕೇವಲ ಒಂದು ಮಿಸ್ಸಿಂಗ್ ಟೆನೆಂಟ್ ಚೆಕ್, ಅಧಿಕಾರವಿರುವ ಬಳಕೆದಾರರ ಪಾತ್ರವನ್ನು ಸಾರ್ವತ್ರಿಕ ಬ್ಯಾಕ್‌ಡೋರ್ ಆಗಿ ಪರಿವರ್ತಿಸಬಹುದು. ಸರಿಯಾದ ಸ್ಕೋಪಿಂಗ್ ಎಂಬುದು ಐಚ್ಛಿಕವಲ್ಲ; ಇದು ಯಾವುದೇ ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಡೇಟಾ ಐಸೊಲೇಶನ್‌ನ (data isolation) ಅಡಿಪಾಯವಾಗಿದೆ.