ನನ್ನದೇ ಆದ ಅಥೆಂಟಿಕೇಶನ್ ಲೇಯರ್ (authentication layer) ಅನ್ನು ಬರೆಯುವುದು ಒಂದು ಗೌರವದ ಸಂಕೇತ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ. ನಿಮಗೆ JWTಗಳು ಅರ್ಥವಾಗಿದ್ದರೆ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಹ್ಯಾಶ್ ಮಾಡಬಲ್ಲರೆ, ಇದು ಎಷ್ಟು ಕಷ್ಟವಾಗಬಹುದು? ನಾನು ಒಂದು Node ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದೆ, ಟೋಕನ್ಗಳನ್ನು ನೀಡಿದೆ ಮತ್ತು ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸಿದೆ. ಕೋಡ್ ಕೆಲಸ ಮಾಡಿತು. ಟೆಸ್ಟ್ಗಳು ಪಾಸಾದವು. ನಂತರ ನೈಜ ದಾಳಿಗಳು (attacks) ಹೇಗೆ ನಡೆಯುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಓದಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನನ್ನ ಅಡಿಪಾಯವೇ ಕುಸಿದಂತಾಯಿತು. ಇಂಜೆಕ್ಷನ್, ಎನ್ಯೂಮರೇಶನ್ ಮತ್ತು ಸೈಡ್-ಚಾನೆಲ್ ಲೀಕ್ಸ್ ಬಗ್ಗೆ ಪ್ರತಿಯೊಂದು ಅಧ್ಯಾಯವೂ ನನ್ನನ್ನು ಅತೀವ ಆತಂಕದೊಂದಿಗೆ ನನ್ನ ಎಡಿಟರ್ ಬಳಿಗೆ ಕಳುಹಿಸಿತು. ನನ್ನ ಅಥೆನ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಕೇವಲ ಲೋಪದೋಷಗಳಿರಲಿಲ್ಲ; ನಾನು ಸ್ವತಃ ಅಳವಡಿಸಿಕೊಂಡಿದ್ದ ನಾಲ್ಕು ತೆರೆದ ಬಾಗಿಲುಗಳಿದ್ದವು. ನಾನು ಕಂಡುಕೊಂಡ ವಿಷಯಗಳು ಮತ್ತು ನಾನು ಬದಲಾಯಿಸಿದ ಕ್ರಮಗಳು ಇಲ್ಲಿವೆ.
ಸ್ಟ್ರಿಂಗ್ ಕನ್ಕ್ಯಾಟಿನೇಶನ್ ಮೂಲಕ SQL ಇಂಜೆಕ್ಷನ್
ಮೊದಲ ಬಗ್ ಅತ್ಯಂತ ಹಳೆಯ ತಂತ್ರವಾಗಿತ್ತು. ನಾನು ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ನೇರವಾಗಿ SQL ಸ್ಟ್ರಿಂಗ್ಗಳಿಗೆ ಸೇರಿಸುತ್ತಿದ್ದೆ. ನನ್ನ ಲಾಗಿನ್ ರೂಟ್ನಲ್ಲಿ, ನಾನು ರಿಕ್ವೆಸ್ಟ್ ಬಾಡಿಯಿಂದ ಇಮೇಲ್ ಅನ್ನು ಪಡೆದು, ಅದನ್ನು SELECT * FROM users WHERE email = '${email}' ಎಂಬ ಕ್ವೆರಿಯಲ್ಲಿ ಕನ್ಕ್ಯಾಟೇಟ್ ಮಾಡುತ್ತಿದ್ದೆ. ನಾನು ಫ್ರಂಟ್-ಎಂಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಿರುವುದರಿಂದ ಇದು ಹಾನಿಕಾರಕವಲ್ಲ ಎಂದು ನನಗೆ ಅನಿಸಿತ್ತು. ಅದು ಅಪಾಯಕಾರಿ ಕಲ್ಪನೆ. ದಾಳಿಕೋರರಿಗೆ ನಿಮ್ಮ ಫ್ರಂಟ್-ಎಂಡ್ ಅಗತ್ಯವಿಲ್ಲ. ಒಂದು ಸಿದ್ಧಪಡಿಸಿದ POST ಬಾಡಿ ಆ ಲಾಗಿನ್ ಚೆಕ್ ಅನ್ನು ಡೇಟಾ ಬ್ರೀಚ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಅಳಿಸಿಹಾಕುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ' OR '1'='1 ನಂತಹ ಪೇಲೋಡ್ ಅಥವಾ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ, ಟೇಬಲ್ಗಳನ್ನು ಡ್ರಾಪ್ ಮಾಡುವ ಸ್ಟ್ಯಾಕ್ಡ್ ಕ್ವೆರಿಯನ್ನು ಕಳುಹಿಸಿದರೆ, ಮತ್ತು ಆ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ರಾಗಾಗಿ ಎಕ್ಸಿಕ್ಯೂಟ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಡೇಟಾ ಹೋದಂತೆಯೇ. ನನ್ನ ಕೋಡ್ ಮತ್ತು ದಾಳಿಕೋರರ ಡೇಟಾ ನಡುವೆ ವ್ಯತ್ಯಾಸ ಮಾಡಿಕೊಳ್ಳಲು ನಾನು ಡೇಟಾಬೇಸ್ಗೆ ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ನೀಡಿರಲಿಲ್ಲ.
ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಹೆಚ್ಚಿನ ಇನ್ಪುಟ್ ವ್ಯಾಲಿಡೇಶನ್ ಅಥವಾ ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು ಕೈಯಿಂದ ಎಸ್ಕೇಪ್ ಮಾಡುವುದಲ್ಲ. ನಿಜವಾದ ಪರಿಹಾರವೆಂದರೆ ಪ್ಯಾರಾಮೀಟರೈಸ್ಡ್ ಕ್ವೆರಿಗಳು (parameterized queries). ನಾನು node-postgres ಗೆ ಬದಲಾಯಿಸಿದೆ ಮತ್ತು $1 ನಂತಹ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಈಗ ಕ್ವೆರಿ ಒಂದು ಟೆಂಪ್ಲೇಟ್ ಆಗಿ ಬದಲಾಗುತ್ತದೆ: SELECT * FROM users WHERE email = $1. ಡ್ರೈವರ್ SQL ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಚಾನಲ್ಗಳ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ. ಇನ್ಪುಟ್ನಲ್ಲಿ ಎಂತಹ ಅಕ್ಷರಗಳಿದ್ದರೂ, ಡೇಟಾಬೇಸ್ ಅದನ್ನು ಕೇವಲ ಡೇಟಾ ಎಂದು ಮಾತ್ರ ಪರಿಗಣಿಸುತ್ತದೆ. ಈ ಒಂದು ಬದಲಾವಣೆಯು ಇಂಜೆಕ್ಷನ್ ದಾಳಿಗಳ ಇಡೀ ವರ್ಗವನ್ನೇ ಮುಚ್ಚಿಡುತ್ತದೆ. ಇದು ಓದಲು ಸರಳವಾಗಿದೆ, ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ WHERE ಕ್ಲಾಸ್ ಬರೆಯುವಾಗ ರೆಜೆಕ್ಸ್ ವಿಜರ್ಡ್ ಆಗಬೇಕಾದ ಅಗತ್ಯವನ್ನು ಇದು ತಪ್ಪಿಸುತ್ತದೆ.
ಎರರ್ ಮೆಸೇಜ್ಗಳ ಮೂಲಕ ಇಮೇಲ್ ಎನ್ಯೂಮರೇಶನ್
ನನ್ನ ಎರಡನೇ ತಪ್ಪು ಉತ್ತಮ UX (User Experience) ನಂತೆ ಕಂಡಿತು. ಬಳಕೆದಾರರು ತಪ್ಪು ಇಮೇಲ್ ಟೈಪ್ ಮಾಡಿದಾಗ, ನಾನು User not found ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದ್ದೆ. ಅವರು ಸರಿಯಾದ ಇಮೇಲ್ ನೀಡಿ ತಪ್ಪು ಪಾಸ್ವರ್ಡ್ ನೀಡಿದಾಗ, ನಾನು Incorrect password ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದ್ದೆ. ಇದು ಸಹಕಾರಿಯೆಂದು ಅನಿಸಿತು. ಆದರೆ ಇದು ದಾಳಿಕೋರರಿಗೆ ಮಾಹಿತಿಯ ಶೋಧದ ಸಾಧನವಾಗಿಯೂ (reconnaissance tool) ಕೆಲಸ ಮಾಡಿತು. ಎನ್ಯೂಮರೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಸಾವಿರಾರು ಇಮೇಲ್ ವಿಳಾಸಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಲಾಗಿನ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು. ಖಾತೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದರ ಮೇಲೆ ಪ್ರತಿಕ್ರಿಯೆಯ ಬಾಡಿ ಅಥವಾ ಸ್ಟೇಟಸ್ ಕೋಡ್ ಬದಲಾದರೆ, ಆ ಸ್ಕ್ರಿಪ್ಟ್ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಪರಿಶುದ್ಧ ಪಟ್ಟಿಯನ್ನು ತಯಾರಿಸಬಹುದು. ಆ ಪಟ್ಟಿಯು ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಸ್ಟಫಿಂಗ್, ಟಾರ್ಗೆಟೆಡ್ ಫಿಶಿಂಗ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಬ್ರೂಟ್-ಫೋರ್ಸ್ ಪ್ರಯತ್ನಗಳಿಗೆ ಅಡಿಪಾಯವಾಗುತ್ತದೆ.
ಬಳಕೆದಾರ ಸ್ನೇಹಿ ಗುಣವು ಕೆಲವೊಮ್ಮೆ ಭದ್ರತೆಗಾಗಿ ಬಿಟ್ಟುಕೊಡಬೇಕಾಗುತ್ತದೆ ಎಂಬ ಸತ್ಯವನ್ನು ನಾನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾಯಿತು. ನಾನು ಎಲ್ಲಾ ವಿಫಲ ಲಾಗಿನ್ ಹಾದಿಗಳನ್ನು ಒಂದೇ ರೀತಿಯ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ನೀಡುವಂತೆ ಬದಲಾಯಿಸಿದೆ: Invalid credentials. ಯಾವುದೇ ಸುಳಿವು ಇಲ್ಲ. ಎರರ್ ರೆಸ್ಪಾನ್ಸ್ನಲ್ಲಿ ಯಾವುದೇ ಬ್ರಾಂಚಿಂಗ್ ಲಾಜಿಕ್ ಇಲ್ಲ. ಇಮೇಲ್ ಇಲ್ಲದಿದ್ದರೂ, ಪಾಸ್ವರ್ಡ್ ತಪ್ಪಾಗಿದ್ದರೂ ಅಥವಾ ಖಾತೆಯನ್ನು ಲಾಕ್ ಮಾಡಿದ್ದರೂ, ಪಠ್ಯವು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಇದು ರಿಜಿಸ್ಟ್ರೇಶನ್ ಮತ್ತು ಪಾಸ್ವರ್ಡ್-ರೀಸೆಟ್ ಫ್ಲೋಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ; ಒಂದು ವಿಳಾಸವು ಈಗಾಗಲೇ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ನಲ್ಲಿದೆಯೇ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸಬೇಡಿ. ಒಂದು ಸಾಮಾನ್ಯ ಸಂದೇಶವು ದಾಳಿಕೋರರು ಅವಲಂಬಿಸುವ ಮಾಹಿತಿ ಸೋರಿಕೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
ಪಾಸ್ವರ್ಡ್ ಹೋಲಿಕೆಯಲ್ಲಿ ಟೈಮಿಂಗ್ ಅಟ್ಯಾಕ್ಗಳು
ಮೂರನೇ ಬಗ್ ಅದೃಶ್ಯವಾಗಿತ್ತು. ನಾನು...