ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ದಾಳಿಗಳ ವಿವರಣೆ

ಹಣ ಕದಿಯಲು ದಾಳಿಕೋರರು ಯಾವಾಗಲೂ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮುರಿಯುವುದಿಲ್ಲ.

ಅನೇಕ ಡೆವಲಪರ್‌ಗಳು APIಗಳು ಮತ್ತು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಲು ತಿಂಗಳುಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುತ್ತಾರೆ. ಅವರು SQL injection ಅಥವಾ XSS ಅನ್ನು ತಡೆಯುವತ್ತ ಗಮನ ಹರಿಸುತ್ತಾರೆ. ಆದರೆ ನಂತರ, ಒಬ್ಬ ದಾಳಿಕೋರನು ಯಾವುದೇ ಭದ್ರತಾ ನಿಯಂತ್ರಣವನ್ನು ಮುರಿಯದೆ ಹಣವನ್ನು ಕದಿಯಬಹುದು.

ಇದು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ದಾಳಿ (business logic attack).

ಅಪ್ಲಿಕೇಶನ್ ವಿನ್ಯಾಸಗೊಳಿಸಿದಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ದಾಳಿಕೋರನು ಕೇವಲ ನಿಮ್ಮದೇ ನಿಯಮಗಳನ್ನು ನಿಮ್ಮ ವಿರುದ್ಧವೇ ಬಳಸುತ್ತಾನೆ.

ಒಂದು ಬ್ಯಾಂಕ್ ವಾಲ್ಟ್ (bank vault) ಬಗ್ಗೆ ಯೋಚಿಸಿ. ಹೆಚ್ಚಿನ ಭದ್ರತಾ ಪರೀಕ್ಷೆಗಳು ಬಾಗಿಲು ಬಲವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತವೆ. ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಪರೀಕ್ಷೆಯು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತದೆ. ಯಾರಾದರೂ ಗಾರ್ಡ್ ಅನ್ನು ನಂಬಿಸಿ ತಮಗಾಗಿ ಬಾಗಿಲನ್ನು ತೆರೆಯಲು ಒಪ್ಪಿಸಿದರೆ ಏನಾಗಬಹುದು?

ವಾಲ್ಟ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಪ್ರಕ್ರಿಯೆಯು ವಿಫಲವಾಗುತ್ತದೆ.

ದಾಳಿಕೋರರು ಬ್ಯಾಂಕಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವ ಮೂರು ವಿಧಾನಗಳು ಇಲ್ಲಿವೆ:

  1. ಕಾಯುವ ಅವಧಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದು (Bypassing Waiting Periods) ಬ್ಯಾಂಕುಗಳು ಹೊಸ ಸ್ವೀಕ ability (recipient) ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ ಸಾಮಾನ್ಯವಾಗಿ 24 ಗಂಟೆಗಳ ಕಾಯುವ ಅವಧಿಯನ್ನು ಬಯಸುತ್ತವೆ. ಇದು ತಕ್ಷಣದ ಕಳ್ಳತನವನ್ನು ತಡೆಯುತ್ತದೆ. ದಾಳಿಕೋರನು ಈ ಪರಿಶೀಲನೆಯನ್ನು ಬಿಟ್ಟುಹೋಗುವ API endpoint ಅನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದು. ಅವರು UI ನಿರ್ಬಂಧವನ್ನು ತಪ್ಪಿಸಿ ತಕ್ಷಣವೇ ಹಣವನ್ನು ವರ್ಗಾಯಿಸಬಹುದು.

  2. ವಹಿವಾಟಿನ ಮಿತಿಗಳನ್ನು ಮುರಿಯುವುದು (Breaking Transaction Limits) ಬ್ಯಾಂಕ್ ದಿನಕ್ಕೆ 50,000 ಮಿತಿಯನ್ನು ನಿಗದಿಪಡಿಸಿರಬಹುದು. ಕೋಡ್ ಪ್ರತಿಯೊಂದು ವಹಿವಾಟನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾತ್ರ ಪರಿಶೀಲಿಸುವುದಾದರೆ, ದಾಳಿಕೋರನು 49,000 ರ ಐದು ವರ್ಗಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು. ಪ್ರತಿಯೊಂದು ವಹಿವಾಟು ಕೂಡ ಸರಿಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ಒಟ್ಟು ಮೊತ್ತವು ಮಿತಿಯನ್ನು ಮೀರಿದ್ದರೂ, ಸಿಸ್ಟಮ್ ಅದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ.

  3. ರಿವಾರ್ಡ್ ದುರುಪಯೋಗ (Reward Abuse) ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬಿಲ್ ಪಾವತಿಗಳಿಗೆ ಕ್ಯಾಶ್‌ಬ್ಯಾಕ್ ನೀಡುತ್ತವೆ. ದಾಳಿಕೋರನು ಒಂದು ಬಿಲ್ ಪಾವತಿಸಿ ತಕ್ಷಣವೇ ಅದನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು. ಸಿಸ್ಟಮ್ ಆ ರಿವಾರ್ಡ್ ಅನ್ನು ಹಿಂಪಡೆಯದಿದ್ದರೆ, ದಾಳಿಕೋರನು ಅಂತ್ಯವಿಲ್ಲದ ಕ್ಯಾಶ್‌ಬ್ಯಾಕ್ ಪಡೆಯಲು ಒಂದು ಲೂಪ್ ಅನ್ನು ಸೃಷ್ಟಿಸಬಹುದು.

ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ಯಾನರ್‌ಗಳು (Automated scanners) ಇದನ್ನು ಏಕೆ ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತವೆ?

ಸ್ಕ್ಯಾನರ್‌ಗಳು ಮಾಲ್‌ವೇರ್ ಅಥವಾ ಇಂಜೆಕ್ಷನ್‌ನಂತಹ ತಾಂತ್ರಿಕ ದೋಷಗಳನ್ನು ಹುಡುಕುತ್ತವೆ. ಸ್ಕ್ಯಾನರ್ ಒಂದು ಯಶಸ್ವಿ ವರ್ಗಾವಣೆಯನ್ನು ನೋಡಿ 200 OK ಸ್ಟೇಟಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ಅದು ಭಾವಿಸುತ್ತದೆ.

ಒಬ್ಬ ಮಾನವ ಪರೀಕ್ಷಕನು ಹೀಗೆ ಕೇಳುತ್ತಾನೆ: ಈ ವರ್ಗಾವಣೆ আদৌ ನಡೆಯಬೇಕಿತ್ತೇ?

ಈ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು, ಒಂದು ಫೀಚರ್ ಅನ್ನು ಹ್ಯಾಕ್ ಮಾಡಬಹುದೇ ಎಂದು ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಬದಲಾಗಿ, ಆ ಫೀಚರ್ ಅನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಬಹುದೇ ಎಂದು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿ.

ಈ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:

  • ಬಳಕೆದಾರರು ಪರಿಶೀಲನಾ ಹಂತಗಳನ್ನು (verification steps) ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದೇ?
  • ಬಳಕೆದಾರರು ಐಡಿಯ (ID) ಮಾಲೀಕತ್ವವನ್ನು ಬದಲಾಯಿಸಬಹುದೇ?
  • API ಮೂಲಕ ಕಾಯುವ ಅವಧಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದೇ?
  • ಮಿತಿಗಳನ್ನು ಒಟ್ಟು ಮೊತ್ತದ ಮೇಲೆ ವಿಧಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಕೇವಲ ಪ್ರತಿ ಕ್ಲಿಕ್ ಮೇಲೆ ಮಾತ್ರವೇ?
  • ರಿವಾರ್ಡ್‌ಗಳನ್ನು ಹಲವಾರು ಬಾರಿ ಪಡೆಯಬಹುದೇ?

ಎಲೈಟ್ ಭದ್ರತಾ ತಂಡಗಳು ಕೇವಲ use casesಗಳನ್ನು ರಚಿಸುವುದಿಲ್ಲ. ಅವು abuse casesಗಳನ್ನು ರಚಿಸುತ್ತವೆ.

"User transfers money" ಎಂದು ಪರೀಕ್ಷಿಸುವ ಬದಲು, "Attacker attempts 500 small transfers to bypass limits" ಎಂದು ಪರೀಕ್ಷಿಸಿ.

ಎರಡನೇ ಪ್ರಶ್ನೆಯು ನಿಜವಾದ ಅಪಾಯವನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.

ಮೂಲ: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj