ಓದುವ ಅಧಿಕಾರವಿದ್ದ (read-only) ಅಕೌಂಟೆಂಟ್, ಮುಕ್ತ ತಂತ್ರಾಂಶದ (open-source) ಬುಕ್ಕೀಪಿಂಗ್ ಸಾಧನವಾದ Akaunting ನಲ್ಲಿ ಇನ್ವಾಯ್ಸ್ಗಳನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು ಮತ್ತು ಪಾವತಿ ಇತಿಹಾಸವನ್ನು ಅಳಿಸಿಹಾಕಬಹುದು, ಇದು ಸಣ್ಣ ವ್ಯವಹಾರಗಳನ್ನು ಮೌನವಾಗಿ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ತುತ್ತಾಗುವಂತೆ ಮಾಡುತ್ತದೆ. ಈ ದೋಷವನ್ನು ಆವೃತ್ತಿ 3.2.0 ರಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಅನುಮತಿ ತಪಾಸಣೆಗಳನ್ನು (permission checks) ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡಲಾದ ಮೆಥಡ್ ಹೆಸರುಗಳ ಪಟ್ಟಿಗೆ ಜೋಡಿಸಿರುವುದು ಎಂಬ ತಪ್ಪು, ಪಾತ್ರ ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು (role-based access control) ಅವಲಂಬಿಸಿರುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಗೆ ಇಂದಿಗೂ ಅಪಾಯಕಾರಿಯಾಗಿದೆ.
ಈ ಬಗ್ ಹೇಗೆ ತಪ್ಪಿಹೋಯಿತು
Akaunting ನ API ಮೆಥಡ್ ಹೆಸರುಗಳ 'ಅಲೌ್ಲಿಸ್ಟ್' (allowlist) ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಈ ಪಟ್ಟಿಯು ಸಾಮಾನ್ಯ CRUD ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು—create, read, update, delete—ಒಳಗೊಂಡಿತ್ತು, ಆದರೆ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ (status-changing) ಹಲವಾರು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು (endpoints) ಮರೆತಿದೆ:
markSentmarkCancelledmarkReceived
ಆ ಹ್ಯಾಂಡ್ಲರ್ಗಳು ಪಟ್ಟಿಯಲ್ಲಿ ಇಲ್ಲದ ಕಾರಣ, ಅವು ಚಾಲನೆಯಾದಾಗ ಫ್ರೇಮ್ವರ್ಕ್ ಎಂದಿಗೂ ಅನುಮತಿ ತಪಾಸಣಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು (permission-checking routine) ಕರೆಯಲಿಲ್ಲ. ಓದುವ ಅಧಿಕಾರವಿದ್ದ (read-only) ಬಳಕೆದಾರರು markCancelled ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸರಳವಾದ GET ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಕಳುಹಿಸಿದರೆ, ಸಿಸ್ಟಮ್ ಅದನ್ನು ಕಾನೂನುಬದ್ಧ ಸ್ಥಿತಿ ಬದಲಾವಣೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ.
ಇನ್ವಾಯ್ಸ್ ಅನ್ನು ರದ್ದುಗೊಳಿಸುವುದು ಕೇವಲ ದಾಖಲೆಯನ್ನು ಅಸಿಂಧು ಎಂದು ಗುರುತಿಸುವುದಷ್ಟೇ ಅಲ್ಲ; ಅದು ಆ ಇನ್ವಾಯ್ಸ್ಗೆ ಸಂಬಂಧಿಸಿದ ಯಾವುದೇ ಪಾವತಿ ದಾಖಲೆಗಳನ್ನು ಸಹ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದರ ಪರಿಣಾಮ: ಎಡಿಟ್ ಮಾಡುವ ಹಕ್ಕು ಇಲ್ಲದ ಬಳಕೆದಾರರು ವಹಿವಾಟಿನ ಹಣಕಾಸಿನ ದಾಖಲೆಗಳನ್ನು (financial trail) ಅಳಿಸಿಹಾಕಬಹುದು.
ಪರೀಕ್ಷೆಯು ಏನನ್ನು ತೋರಿಸಿತು
ಈ ದುರ್ಬಲತೆಯು Akaunting ನ ಅಧಿಕೃತ Docker ಇಮೇಜ್ನಲ್ಲಿ ಕಂಡುಬಂದಿತು:
- ಇನ್ವಾಯ್ಸ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಲು ಕಳುಹಿಸಿದ ಸಾಮಾನ್ಯ PUT ರಿಕ್ವೆಸ್ಟ್ 403 Forbidden ಅನ್ನು ನೀಡಿತು, ಇದು ಸಾಮಾನ್ಯ ಅಪ್ಡೇಟ್ ಮಾರ್ಗವು ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿತು.
- ರದ್ದತಿ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಕಳುಹಿಸಿದ GET ರಿಕ್ವೆಸ್ಟ್ ಯಾವುದೇ ಅಧಿಕಾರ ದೋಷವಿಲ್ಲದೆ ಯಶಸ್ವಿಯಾಯಿತು, ಇದು ಈ ಲೋಪವನ್ನು ಎತ್ತಿ ತೋರಿಸಿತು.
ಇದು ಏಕೆ ಮುಖ್ಯ
ಸ್ಪಷ್ಟವಾದ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ಇಲ್ಲದೆ ಹಣಕಾಸಿನ ಹೇಳಿಕೆಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ವಂಚನೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಪರಿಹಾರ
ಆವೃತ್ತಿ 3.2.0 ರ ಅನುಮತಿ ಮ್ಯಾಪ್ ಅನ್ನು ವಿಸ್ತರಿಸಲಾಗಿದ್ದು, ಈ ಮೊದಲು ಬಿಟ್ಟುಹೋಗಿದ್ದ ಸ್ಥಿತಿ ಕ್ರಿಯೆಗಳನ್ನು (status actions) ಒಳಗೊಂಡಿದೆ. ಆ ಬಿಡುಗಡೆಯಿಂದ ಮುಂದೆ, ದಾಖಲೆಯ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಯಾವುದೇ ರಿಕ್ವೆಸ್ಟ್—ಅದು mark sent, cancelled ಅಥವಾ received ಆಗಿರಲಿ—ಸಾಮಾನ್ಯ ಅಪ್ಡೇಟ್ನಂತೆಯೇ ಪಾತ್ರದ ಪರಿಶೀಲನೆಯನ್ನು (role verification) ಕಡ್ಡಾಯವಾಗಿ ಪೂರೈಸಬೇಕು. ಇದು ಓದುವ ಅಧಿಕಾರವಿದ್ದ (read-only) ಪಾತ್ರವು ನಿಜವಾಗಿಯೂ ಡೇಟಾವನ್ನು ಮಾರ್ಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬ ನಿರೀಕ್ಷೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸುತ್ತದೆ.
ಡೆವಲಪರ್ಗಳಿಗೆ ಪಾಠಗಳು
- ಮೆಥಡ್ ಹೆಸರುಗಳನ್ನು ಸುರಕ್ಷತೆಯೊಂದಿಗೆ ಎಂದಿಗೂ ಸಮಾನೀಕರಿಸಬೇಡಿ. ಹೊಸ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಸೇರಿಸಿದ ತಕ್ಷಣ ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಕ್ಷಣೆ ಪಡೆಯುವುದಿಲ್ಲ; ಪ್ರತಿಯೊಂದು ಪಬ್ಲಿಕ್ ಮೆಥಡ್ ಅನ್ನು ಅದರ ಪರಿಣಾಮಗಳಿಗಾಗಿ (side effects) ಆಡಿಟ್ ಮಾಡಿ.
- ಅಲೌ್ಲಿಸ್ಟ್ಗಳು ಆ ಪಟ್ಟಿಯಷ್ಟೇ ಪರಿಪೂರ್ಣವಾಗಿರುತ್ತವೆ. "ಒಳ್ಳೆಯ" ವರ್ಬ್ಗಳ (verbs) ಸ್ಥಿರ ಪಟ್ಟಿಯು ಅಜಾಗರೂಕತೆಗೆ ದಾರಿಯಾಗುತ್ತದೆ.
- ಉದ್ದೇಶವನ್ನು HTTP ವರ್ಬ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. GET ಎಂಬುದು ಕೇವಲ ಓದಲು ಮಾತ್ರ ಇರಬೇಕು, ಆದರೆ ಇಲ್ಲಿ ಅದು ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಿತು. ಬದಲಾವಣೆಗಳನ್ನು (mutations) ಕೇವಲ POST, PUT, DELETE, PATCH ಗೆ ಸೀಮಿತಗೊಳಿಸಿ.
- ಅನುಮತಿ ವ್ಯಾಪ್ತಿಯ ತಪಾಸಣೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ. ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ ಟೂಲ್ಗಳು ಅಧಿಕಾರ ಪ್ರಕ್ರಿಯೆ ಇಲ್ಲದ ಕಂಟ್ರೋಲರ್ ಮೆಥಡ್ಗಳನ್ನು ಗುರುತಿಸಬಹುದು, ಇದರಿಂದ ಲೋಪಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಬಹುದು.
- ಕನಿಷ್ಠ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿರುವ ಖಾತೆಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. Docker ಆಧಾರಿತ ಪರೀಕ್ಷೆಯು ಓದುವ ಅಧಿಕಾರವಿದ್ದ ಬಳಕೆದಾರರನ್ನು ಬಳಸಿತು; ಇಂತಹ ಸನ್ನಿವೇಶಗಳನ್ನು CI ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ ಪುನರಾವರ್ತಿಸುವುದರಿಂದ ಇಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಬಹುದು.
ಮುಂದೆ ಏನು ಗಮನಿಸಬೇಕು
Akaunting ಸಮುದಾಯವು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾದ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ಗಳು ತಮ್ಮ ಇನ್ಸ್ಟೆನ್ಸ್ನ ಆವೃತ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ತಕ್ಷಣವೇ ಅಪ್ಡೇಟ್ ಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಯಾವುದೇ ಪಾತ್ರ ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯನ್ನು (role-based system) ನಿರ್ಮಿಸುತ್ತಿರುವ ಡೆವಲಪರ್ಗಳಿಗೆ, ಇದರಿಂದ ಕಲಿಯಬೇಕಾದ ಪಾಠ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಪ್ರತಿಯೊಂದು ಸಂಭವನೀಯ ಕ್ರಿಯೆಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವ ಅನುಮತಿ ಮಾದರಿಯು (permission model) ಮೂಲತಃ ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಯಾವ ಕಾರ್ಯಾಚರಣೆಗಳು ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸಿ, ಫ್ರೇಮ್ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ತಪಾಸಣೆಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ ಮತ್ತು ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ನಿಯಮಿತವಾಗಿ ಆಡಿಟ್ ಮಾಡಿ. ಆಗ ಮಾತ್ರ ಹಣಕಾಸಿನ ದಾಖಲೆಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡಲು "read-only" ಎಂಬ ಲೇಬಲ್ ಅನ್ನು ನಂಬಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
