MCS ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಭದ್ರತಾ ಲೆಕ್ಕಪರಿಶೋಧನೆ

ಸ್ಕೈಶಿಪ್ ಮುಸ್ಸಂಜೆ ಸೀರ್‌ಲೈಟ್ ಮೂಲಕ

ಯಾವುದೇ ಸೇವೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಭದ್ರತೆಯ ಮೇಲೆ ನಿರಂತರ ಕೆಲಸವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಭದ್ರತೆಯು ನಿರಂತರವಾದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು ಅದು ನಿರಂತರ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಉತ್ಪನ್ನ ಸುರಕ್ಷತೆಯ ಸುಧಾರಣೆ, ದೋಷಗಳ ಬಗ್ಗೆ ಸುದ್ದಿಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು ಹೆಚ್ಚಿನದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಲೆಕ್ಕಪರಿಶೋಧನೆ ಸೇರಿದಂತೆ. ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳನ್ನು ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ ತಜ್ಞರು ನಡೆಸುತ್ತಾರೆ, ಅವರು ಯೋಜನೆಯಲ್ಲಿ ಮುಳುಗಿಲ್ಲ ಮತ್ತು ಮುಕ್ತ ಮನಸ್ಸನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಭದ್ರತೆಗೆ ಆಮೂಲಾಗ್ರವಾಗಿ ಸಹಾಯ ಮಾಡಬಹುದು.

ಲೇಖನವು ಮೇಲ್.ರು ಕ್ಲೌಡ್ ಸೊಲ್ಯೂಷನ್ಸ್ (ಎಂಸಿಎಸ್) ತಂಡವು ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಹಾಯ ಮಾಡಿದ ಬಾಹ್ಯ ತಜ್ಞರ ಈ ಅತ್ಯಂತ ನೇರವಾದ ನೋಟವನ್ನು ಮತ್ತು ಅವರು ಕಂಡುಕೊಂಡ ಬಗ್ಗೆ. "ಬಾಹ್ಯ ಶಕ್ತಿಯಾಗಿ," MCS ಡಿಜಿಟಲ್ ಸೆಕ್ಯುರಿಟಿ ಕಂಪನಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ, ಇದು ಮಾಹಿತಿ ಭದ್ರತಾ ವಲಯಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಪರಿಣತಿಗೆ ಹೆಸರುವಾಸಿಯಾಗಿದೆ. ಮತ್ತು ಈ ಲೇಖನದಲ್ಲಿ ಬಾಹ್ಯ ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಭಾಗವಾಗಿ ಕಂಡುಬರುವ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ದೋಷಗಳನ್ನು ನಾವು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ - ಇದರಿಂದ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ರಚಿಸುವಾಗ ಅದೇ ಕುಂಟೆಯನ್ನು ತಪ್ಪಿಸುತ್ತೀರಿ.

ವಿವರಣೆ

Mail.ru ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳು (MCS) ಕ್ಲೌಡ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ವೇದಿಕೆಯಾಗಿದೆ. ಇದು IaaS, PaaS ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಸಿದ್ಧ-ಸಿದ್ಧ ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳ ಮಾರುಕಟ್ಟೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. MCS ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಈ ಕೆಳಗಿನ ಪ್ರದೇಶಗಳಲ್ಲಿ ಉತ್ಪನ್ನದ ಸುರಕ್ಷತೆಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು:

• ವರ್ಚುವಲೈಸೇಶನ್ ಪರಿಸರದ ಮೂಲಸೌಕರ್ಯವನ್ನು ರಕ್ಷಿಸುವುದು: ಹೈಪರ್ವೈಸರ್ಗಳು, ರೂಟಿಂಗ್, ಫೈರ್ವಾಲ್ಗಳು;
• ಗ್ರಾಹಕರ ವರ್ಚುವಲ್ ಮೂಲಸೌಕರ್ಯದ ರಕ್ಷಣೆ: ನೆಟ್‌ವರ್ಕ್ ಸೇರಿದಂತೆ, ಎಸ್‌ಡಿಎನ್‌ನಲ್ಲಿ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಸೇರಿದಂತೆ ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕತೆ;
• OpenStack ಮತ್ತು ಅದರ ತೆರೆದ ಘಟಕಗಳು;
• ನಮ್ಮದೇ ವಿನ್ಯಾಸದ S3;
• IAM: ರೋಲ್ ಮಾಡೆಲ್ ಹೊಂದಿರುವ ಬಹು-ಬಾಡಿಗೆದಾರರ ಯೋಜನೆಗಳು;
• ದೃಷ್ಟಿ (ಕಂಪ್ಯೂಟರ್ ದೃಷ್ಟಿ): ಚಿತ್ರಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ API ಗಳು ಮತ್ತು ದುರ್ಬಲತೆಗಳು;
• ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಕ್ಲಾಸಿಕ್ ವೆಬ್ ದಾಳಿಗಳು;
• PaaS ಘಟಕಗಳ ದುರ್ಬಲತೆಗಳು;
• ಎಲ್ಲಾ ಘಟಕಗಳ API.

ಬಹುಶಃ ಮುಂದಿನ ಇತಿಹಾಸಕ್ಕೆ ಇದು ಅತ್ಯಗತ್ಯ.

ಯಾವ ರೀತಿಯ ಕೆಲಸವನ್ನು ಕೈಗೊಳ್ಳಲಾಯಿತು ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು?

ಭದ್ರತಾ ಲೆಕ್ಕಪರಿಶೋಧನೆಯು ವೈಯಕ್ತಿಕ ಡೇಟಾದ ಸೋರಿಕೆ, ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯ ಮಾರ್ಪಾಡು ಅಥವಾ ಸೇವೆಯ ಲಭ್ಯತೆಯ ಅಡಚಣೆಗೆ ಕಾರಣವಾಗುವ ದೋಷಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷಗಳನ್ನು ಗುರುತಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ.

ಕೆಲಸದ ಸಮಯದಲ್ಲಿ, ಸರಾಸರಿ 1-2 ತಿಂಗಳುಗಳವರೆಗೆ ಇರುತ್ತದೆ, ಲೆಕ್ಕಪರಿಶೋಧಕರು ಸಂಭಾವ್ಯ ದಾಳಿಕೋರರ ಕ್ರಮಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ ಮತ್ತು ಆಯ್ದ ಸೇವೆಯ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಭಾಗಗಳಲ್ಲಿ ದುರ್ಬಲತೆಗಳನ್ನು ಹುಡುಕುತ್ತಾರೆ. MCS ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಕೆಳಗಿನ ಗುರಿಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ:

1. ಸೇವೆಯಲ್ಲಿ ದೃಢೀಕರಣದ ವಿಶ್ಲೇಷಣೆ. ಈ ಘಟಕದಲ್ಲಿನ ದೋಷಗಳು ಇತರ ಜನರ ಖಾತೆಗಳಿಗೆ ತಕ್ಷಣವೇ ಪ್ರವೇಶಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
2. ವಿಭಿನ್ನ ಖಾತೆಗಳ ನಡುವಿನ ರೋಲ್ ಮಾಡೆಲ್ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಅಧ್ಯಯನ ಮಾಡುವುದು. ಆಕ್ರಮಣಕಾರರಿಗೆ, ಬೇರೊಬ್ಬರ ವರ್ಚುವಲ್ ಯಂತ್ರಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವು ಅಪೇಕ್ಷಣೀಯ ಗುರಿಯಾಗಿದೆ.
3. ಕ್ಲೈಂಟ್ ಸೈಡ್ ದುರ್ಬಲತೆಗಳು. XSS/CSRF/CRLF/ಇತ್ಯಾದಿ. ದುರುದ್ದೇಶಪೂರಿತ ಲಿಂಕ್‌ಗಳ ಮೂಲಕ ಇತರ ಬಳಕೆದಾರರ ಮೇಲೆ ದಾಳಿ ಮಾಡಲು ಸಾಧ್ಯವೇ?
4. ಸರ್ವರ್ ಸೈಡ್ ದುರ್ಬಲತೆಗಳು: RCE ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ಚುಚ್ಚುಮದ್ದು (SQL/XXE/SSRF ಮತ್ತು ಹೀಗೆ). ಸರ್ವರ್ ದೋಷಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡುಹಿಡಿಯುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಅವು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಬಳಕೆದಾರರ ರಾಜಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ.
5. ನೆಟ್ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ಬಳಕೆದಾರರ ವಿಭಾಗದ ಪ್ರತ್ಯೇಕತೆಯ ವಿಶ್ಲೇಷಣೆ. ಆಕ್ರಮಣಕಾರರಿಗೆ, ಪ್ರತ್ಯೇಕತೆಯ ಕೊರತೆಯು ಇತರ ಬಳಕೆದಾರರ ವಿರುದ್ಧ ಆಕ್ರಮಣದ ಮೇಲ್ಮೈಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
6. ವ್ಯಾಪಾರ ತರ್ಕ ವಿಶ್ಲೇಷಣೆ. ವ್ಯವಹಾರಗಳನ್ನು ಮೋಸಗೊಳಿಸಲು ಮತ್ತು ಉಚಿತವಾಗಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವೇ?

ಈ ಯೋಜನೆಯಲ್ಲಿ, "ಗ್ರೇ-ಬಾಕ್ಸ್" ಮಾದರಿಯ ಪ್ರಕಾರ ಕೆಲಸವನ್ನು ಕೈಗೊಳ್ಳಲಾಯಿತು: ಲೆಕ್ಕಪರಿಶೋಧಕರು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ಸೇವೆಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಿದರು, ಆದರೆ ಭಾಗಶಃ API ಯ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಡೆವಲಪರ್ಗಳೊಂದಿಗೆ ವಿವರಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವ ಅವಕಾಶವನ್ನು ಹೊಂದಿದ್ದರು. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಅನುಕೂಲಕರವಾಗಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಸಾಕಷ್ಟು ವಾಸ್ತವಿಕ ಕೆಲಸದ ಮಾದರಿಯಾಗಿದೆ: ಆಂತರಿಕ ಮಾಹಿತಿಯನ್ನು ಇನ್ನೂ ಆಕ್ರಮಣಕಾರರಿಂದ ಸಂಗ್ರಹಿಸಬಹುದು, ಇದು ಕೇವಲ ಸಮಯದ ವಿಷಯವಾಗಿದೆ.

Найденные уязвимости

ಲೆಕ್ಕಪರಿಶೋಧಕರು ವಿವಿಧ ಪೇಲೋಡ್‌ಗಳನ್ನು (ದಾಳಿ ನಡೆಸಲು ಬಳಸುವ ಪೇಲೋಡ್) ಯಾದೃಚ್ಛಿಕ ಸ್ಥಳಗಳಿಗೆ ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ವಿಷಯಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಯಾವ ಕಾರ್ಯವನ್ನು ಒದಗಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ. ಇದು ನಿಷ್ಪ್ರಯೋಜಕ ವ್ಯಾಯಾಮ ಎಂದು ತೋರುತ್ತದೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಅಧ್ಯಯನ ಮಾಡಿದ ಸ್ಥಳಗಳಲ್ಲಿ ಯಾವುದೇ ದುರ್ಬಲತೆಗಳು ಇರುವುದಿಲ್ಲ. ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ರಚನೆ ಮತ್ತು ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ತರ್ಕವನ್ನು ಮಾತ್ರ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅತ್ಯಂತ ಸಂಕೀರ್ಣವಾದ ದಾಳಿ ವಾಹಕಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಅನುಮಾನಾಸ್ಪದವಾಗಿ ತೋರುವ ಅಥವಾ ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಇತರರಿಂದ ತುಂಬಾ ಭಿನ್ನವಾಗಿರುವ ಸ್ಥಳಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಮತ್ತು ಮೊದಲ ಅಪಾಯಕಾರಿ ದುರ್ಬಲತೆ ಈ ರೀತಿಯಲ್ಲಿ ಕಂಡುಬಂದಿದೆ.

IDOR

IDOR (ಅಸುರಕ್ಷಿತ ನೇರ ಆಬ್ಜೆಕ್ಟ್ ರೆಫರೆನ್ಸ್) ದುರ್ಬಲತೆಗಳು ವ್ಯವಹಾರ ತರ್ಕದಲ್ಲಿನ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ದುರ್ಬಲತೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಇದು ಪ್ರವೇಶವನ್ನು ನಿಜವಾಗಿ ಅನುಮತಿಸದ ವಸ್ತುಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಒಂದು ಅಥವಾ ಇನ್ನೊಬ್ಬರಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. IDOR ದುರ್ಬಲತೆಗಳು ವಿವಿಧ ಹಂತದ ವಿಮರ್ಶಾತ್ಮಕತೆಯ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುವ ಸಾಧ್ಯತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ.

ಈ ವಸ್ತುಗಳಿಗೆ ಪ್ರವೇಶ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಸಿಸ್ಟಮ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ (ಬಳಕೆದಾರರು, ಬ್ಯಾಂಕ್ ಖಾತೆಗಳು, ಶಾಪಿಂಗ್ ಕಾರ್ಟ್‌ನಲ್ಲಿರುವ ಐಟಂಗಳು) ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು IDOR ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದು ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಹಣವನ್ನು ಕಳುಹಿಸುವವರ ಖಾತೆಯನ್ನು ಬದಲಿಸುವ ಸಾಧ್ಯತೆ, ಅದರ ಮೂಲಕ ನೀವು ಇತರ ಬಳಕೆದಾರರಿಂದ ಅವುಗಳನ್ನು ಕದಿಯಬಹುದು.

MCS ನ ಸಂದರ್ಭದಲ್ಲಿ, ಲೆಕ್ಕಪರಿಶೋಧಕರು ಸುರಕ್ಷಿತವಲ್ಲದ ಗುರುತಿಸುವಿಕೆಗಳೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ IDOR ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದಾರೆ. ಬಳಕೆದಾರರ ವೈಯಕ್ತಿಕ ಖಾತೆಯಲ್ಲಿ, ಯಾವುದೇ ವಸ್ತುಗಳನ್ನು ಪ್ರವೇಶಿಸಲು UUID ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಇದು ಭದ್ರತಾ ತಜ್ಞರು ಹೇಳುವಂತೆ, ಪ್ರಭಾವಶಾಲಿಯಾಗಿ ಅಸುರಕ್ಷಿತವಾಗಿದೆ (ಅಂದರೆ, ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿ ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲಾಗಿದೆ). ಆದರೆ ಕೆಲವು ಘಟಕಗಳಿಗೆ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ನಿಯಮಿತ ಊಹಿಸಬಹುದಾದ ಸಂಖ್ಯೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಬಳಕೆದಾರ ID ಅನ್ನು ಒಂದರಿಂದ ಬದಲಾಯಿಸಲು, ವಿನಂತಿಯನ್ನು ಮತ್ತೊಮ್ಮೆ ಕಳುಹಿಸಲು ಮತ್ತು ACL (ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಪಟ್ಟಿ, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಡೇಟಾ ಪ್ರವೇಶ ನಿಯಮಗಳು) ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ ಮಾಹಿತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ನೀವು ಊಹಿಸಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಸರ್ವರ್ ಸೈಡ್ ರಿಕ್ವೆಸ್ಟ್ ಫೋರ್ಜರಿ (SSRF)

ಓಪನ್ ಸೋರ್ಸ್ ಉತ್ಪನ್ನಗಳ ಬಗ್ಗೆ ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ ಅವುಗಳು ಉದ್ಭವಿಸುವ ಸಮಸ್ಯೆಗಳ ವಿವರವಾದ ತಾಂತ್ರಿಕ ವಿವರಣೆಗಳೊಂದಿಗೆ ಬೃಹತ್ ಸಂಖ್ಯೆಯ ವೇದಿಕೆಗಳನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ನೀವು ಅದೃಷ್ಟವಂತರಾಗಿದ್ದರೆ, ಪರಿಹಾರದ ವಿವರಣೆ. ಆದರೆ ಈ ನಾಣ್ಯವು ಫ್ಲಿಪ್ ಸೈಡ್ ಅನ್ನು ಹೊಂದಿದೆ: ತಿಳಿದಿರುವ ದುರ್ಬಲತೆಗಳನ್ನು ಸಹ ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, OpenStack ವೇದಿಕೆಯಲ್ಲಿ ದುರ್ಬಲತೆಗಳ ಅದ್ಭುತ ವಿವರಣೆಗಳಿವೆ [XSS] и [SSRF], ಕೆಲವು ಕಾರಣಗಳಿಂದ ಯಾರೂ ಸರಿಪಡಿಸಲು ಹಸಿವಿನಲ್ಲಿ ಇಲ್ಲ.

ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಾಮಾನ್ಯ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಬಳಕೆದಾರರಿಗೆ ಸರ್ವರ್‌ಗೆ ಲಿಂಕ್ ಅನ್ನು ಕಳುಹಿಸುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ, ಅದನ್ನು ಸರ್ವರ್ ಕ್ಲಿಕ್ ಮಾಡುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮೂಲದಿಂದ ಚಿತ್ರವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು). ಭದ್ರತಾ ಪರಿಕರಗಳು ಲಿಂಕ್‌ಗಳನ್ನು ಸ್ವತಃ ಫಿಲ್ಟರ್ ಮಾಡದಿದ್ದರೆ ಅಥವಾ ಸರ್ವರ್‌ನಿಂದ ಬಳಕೆದಾರರಿಗೆ ಹಿಂತಿರುಗಿದ ಪ್ರತಿಕ್ರಿಯೆಗಳು, ಅಂತಹ ಕಾರ್ಯವನ್ನು ಆಕ್ರಮಣಕಾರರು ಸುಲಭವಾಗಿ ಬಳಸಬಹುದು.

SSRF ದೌರ್ಬಲ್ಯಗಳು ದಾಳಿಯ ಬೆಳವಣಿಗೆಯನ್ನು ಹೆಚ್ಚು ಮುನ್ನಡೆಸಬಹುದು. ಆಕ್ರಮಣಕಾರರು ಪಡೆಯಬಹುದು:

• ದಾಳಿಗೊಳಗಾದ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೀಮಿತ ಪ್ರವೇಶ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗಗಳ ಮೂಲಕ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಪ್ರೋಟೋಕಾಲ್ ಬಳಸಿ;
• ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಪೂರ್ಣ ಪ್ರವೇಶ, ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಿಂದ ಸಾರಿಗೆ ಮಟ್ಟಕ್ಕೆ ಡೌನ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು ಸಾಧ್ಯವಾದರೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಪೂರ್ಣ ಲೋಡ್ ನಿರ್ವಹಣೆ;
• ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಫೈಲ್‌ಗಳನ್ನು ಓದಲು ಪ್ರವೇಶ (ಫೈಲ್:/// ಸ್ಕೀಮ್ ಬೆಂಬಲಿತವಾಗಿದ್ದರೆ);
• ಮತ್ತು ಹೆಚ್ಚು.

ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಎಸ್‌ಎಸ್‌ಆರ್‌ಎಫ್ ದುರ್ಬಲತೆಯು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ತಿಳಿದುಬಂದಿದೆ, ಇದು ಪ್ರಕೃತಿಯಲ್ಲಿ "ಕುರುಡು" ಆಗಿದೆ: ನೀವು ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದಾಗ, ನೀವು ಅದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಆದರೆ ವಿನಂತಿಯ ಫಲಿತಾಂಶವನ್ನು ಅವಲಂಬಿಸಿ ನೀವು ವಿವಿಧ ರೀತಿಯ ದೋಷಗಳು / ವಿಳಂಬಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ . ಇದರ ಆಧಾರದ ಮೇಲೆ, ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ನೀವು ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ನಂತರದ ಎಲ್ಲಾ ಪರಿಣಾಮಗಳನ್ನು ಕಡಿಮೆ ಅಂದಾಜು ಮಾಡಬಾರದು. ಉದಾಹರಣೆಗೆ, ಉತ್ಪನ್ನವು ಕಾರ್ಪೊರೇಟ್ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಮಾತ್ರ ಪ್ರವೇಶಿಸಬಹುದಾದ ಬ್ಯಾಕ್-ಆಫೀಸ್ API ಅನ್ನು ಹೊಂದಿರಬಹುದು. ದಾಖಲಾತಿಯೊಂದಿಗೆ (ಒಳಗಿನವರ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ), ಆಕ್ರಮಣಕಾರರು ಆಂತರಿಕ ವಿಧಾನಗಳನ್ನು ಪ್ರವೇಶಿಸಲು SSRF ಅನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಹೇಗಾದರೂ ಉಪಯುಕ್ತ URL ಗಳ ಅಂದಾಜು ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾದರೆ, SSRF ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಅವುಗಳ ಮೂಲಕ ಹೋಗಿ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು - ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ಖಾತೆಯಿಂದ ಖಾತೆಗೆ ಹಣವನ್ನು ವರ್ಗಾಯಿಸಿ ಅಥವಾ ಮಿತಿಗಳನ್ನು ಬದಲಾಯಿಸಿ.

ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಎಸ್‌ಎಸ್‌ಆರ್‌ಎಫ್ ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಇದೇ ಮೊದಲಲ್ಲ. ಹಿಂದೆ, ನೇರ ಲಿಂಕ್‌ನಿಂದ VM ISO ಚಿತ್ರಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು, ಇದು ಇದೇ ರೀತಿಯ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಯಿತು. ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಈಗ OpenStack ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ. ಸ್ಪಷ್ಟವಾಗಿ, ಸಮುದಾಯವು ಇದನ್ನು ಸಮಸ್ಯೆಗೆ ಸರಳ ಮತ್ತು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಹಾರವೆಂದು ಪರಿಗಣಿಸಿದೆ.

ಮತ್ತು ಸೈನ್ ಇದು HackerOne ಸೇವೆಯಿಂದ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ ವರದಿ (h1), ನಿದರ್ಶನ ಮೆಟಾಡೇಟಾವನ್ನು ಓದುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಇನ್ನು ಮುಂದೆ ಕುರುಡು SSRF ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಸಂಪೂರ್ಣ Shopify ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ರೂಟ್ ಪ್ರವೇಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

MCS ನಲ್ಲಿ, SSRF ದೌರ್ಬಲ್ಯಗಳನ್ನು ಒಂದೇ ರೀತಿಯ ಕಾರ್ಯನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಕಂಡುಹಿಡಿಯಲಾಯಿತು, ಆದರೆ ಫೈರ್‌ವಾಲ್‌ಗಳು ಮತ್ತು ಇತರ ರಕ್ಷಣೆಗಳಿಂದಾಗಿ ಅವುಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯವಾಗಿತ್ತು. ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, MCS ತಂಡವು ಸಮುದಾಯಕ್ಕಾಗಿ ಕಾಯದೆ ಹೇಗಾದರೂ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದೆ.

ಶೆಲ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡುವ ಬದಲು XSS

ನೂರಾರು ಅಧ್ಯಯನಗಳು ಬರೆದಿದ್ದರೂ, ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ XSS (ಕ್ರಾಸ್-ಸೈಟ್ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್) ದಾಳಿಯು ಇನ್ನೂ ಹೆಚ್ಚು ಆಗಾಗ್ಗೆ ಎದುರಾಗುತ್ತದೆ ವೆಬ್ ದುರ್ಬಲತೆ (ಅಥವಾ ದಾಳಿ?).

ಯಾವುದೇ ಭದ್ರತಾ ಸಂಶೋಧಕರಿಗೆ ಫೈಲ್ ಅಪ್‌ಲೋಡ್‌ಗಳು ನೆಚ್ಚಿನ ಸ್ಥಳವಾಗಿದೆ. ಪೆಂಟೆಸ್ಟರ್‌ಗಳ ಪರಿಭಾಷೆಯಲ್ಲಿ ನೀವು ಅನಿಯಂತ್ರಿತ ಸ್ಕ್ರಿಪ್ಟ್ (asp/jsp/php) ಅನ್ನು ಲೋಡ್ ಮಾಡಬಹುದು ಮತ್ತು OS ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು - “ಲೋಡ್ ಶೆಲ್”. ಆದರೆ ಅಂತಹ ದುರ್ಬಲತೆಗಳ ಜನಪ್ರಿಯತೆಯು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಅವುಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ವಿರುದ್ಧ ಪರಿಹಾರಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಇತ್ತೀಚೆಗೆ "ಶೆಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವ" ಸಂಭವನೀಯತೆಯು ಶೂನ್ಯಕ್ಕೆ ಒಲವು ತೋರುತ್ತದೆ.

ಆಕ್ರಮಣಕಾರಿ ತಂಡ (ಡಿಜಿಟಲ್ ಸೆಕ್ಯುರಿಟಿ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ) ಅದೃಷ್ಟಶಾಲಿಯಾಗಿತ್ತು. ಸರಿ, ಸರ್ವರ್ ಬದಿಯಲ್ಲಿರುವ MCS ನಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ, ಚಿತ್ರಗಳನ್ನು ಮಾತ್ರ ಅನುಮತಿಸಲಾಗಿದೆ. ಆದರೆ SVG ಕೂಡ ಒಂದು ಚಿತ್ರ. SVG ಚಿತ್ರಗಳು ಹೇಗೆ ಅಪಾಯಕಾರಿಯಾಗಬಹುದು? ಏಕೆಂದರೆ ನೀವು ಅವುಗಳಲ್ಲಿ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ತುಣುಕುಗಳನ್ನು ಎಂಬೆಡ್ ಮಾಡಬಹುದು!

ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು MCS ಸೇವೆಯ ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು, ಅಂದರೆ ಇತರ ಕ್ಲೌಡ್ ಬಳಕೆದಾರರನ್ನು ಆಕ್ರಮಣ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ, ಅವುಗಳೆಂದರೆ ನಿರ್ವಾಹಕರು.

ಫಿಶಿಂಗ್ ಲಾಗಿನ್ ಫಾರ್ಮ್‌ನಲ್ಲಿ XSS ದಾಳಿಯ ಉದಾಹರಣೆ

XSS ದಾಳಿ ಶೋಷಣೆಯ ಉದಾಹರಣೆಗಳು:

• ಲೋಡ್ ಮಾಡಲಾದ ಸ್ಕ್ರಿಪ್ಟ್ ಸಂಪನ್ಮೂಲ API ಅನ್ನು ತಕ್ಷಣವೇ ಪ್ರವೇಶಿಸಬಹುದಾದರೆ, ಸೆಷನ್ ಅನ್ನು ಕದಿಯಲು ಏಕೆ ಪ್ರಯತ್ನಿಸಬೇಕು (ವಿಶೇಷವಾಗಿ HTTP-ಕೇವಲ ಕುಕೀಗಳು ಎಲ್ಲೆಡೆ ಇವೆ, js ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಳ್ಳತನದಿಂದ ರಕ್ಷಿಸಲಾಗಿದೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪೇಲೋಡ್ ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಲು XHR ವಿನಂತಿಗಳನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಆಕ್ರಮಣಕಾರರ ಸಾರ್ವಜನಿಕ SSH ಕೀಲಿಯನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಸರ್ವರ್‌ಗೆ SSH ಪ್ರವೇಶವನ್ನು ಪಡೆದುಕೊಳ್ಳಿ.
• CSP ನೀತಿಯು (ವಿಷಯ ಸಂರಕ್ಷಣಾ ನೀತಿ) ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುವುದನ್ನು ನಿಷೇಧಿಸಿದರೆ, ಆಕ್ರಮಣಕಾರರು ಅದನ್ನು ಇಲ್ಲದೆಯೇ ಪಡೆಯಬಹುದು. ಶುದ್ಧ HTML ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಸೈಟ್‌ಗಾಗಿ ನಕಲಿ ಲಾಗಿನ್ ಫಾರ್ಮ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಈ ಸುಧಾರಿತ ಫಿಶಿಂಗ್ ಮೂಲಕ ನಿರ್ವಾಹಕರ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಕದಿಯಿರಿ: ಬಳಕೆದಾರರ ಫಿಶಿಂಗ್ ಪುಟವು ಅದೇ URL ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ.
• ಅಂತಿಮವಾಗಿ, ಆಕ್ರಮಣಕಾರರು ವ್ಯವಸ್ಥೆ ಮಾಡಬಹುದು ಕ್ಲೈಂಟ್ DoS - 4 KB ಗಿಂತ ದೊಡ್ಡದಾದ ಕುಕೀಗಳನ್ನು ಹೊಂದಿಸಿ. ಬಳಕೆದಾರರು ಒಮ್ಮೆ ಮಾತ್ರ ಲಿಂಕ್ ಅನ್ನು ತೆರೆಯಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರು ನಿರ್ದಿಷ್ಟವಾಗಿ ಬ್ರೌಸರ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಯೋಚಿಸುವವರೆಗೆ ಸಂಪೂರ್ಣ ಸೈಟ್ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ: ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ವೆಬ್ ಸರ್ವರ್ ಅಂತಹ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ.

ಮತ್ತೊಂದು ಪತ್ತೆಯಾದ XSS ನ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ, ಈ ಬಾರಿ ಹೆಚ್ಚು ಬುದ್ಧಿವಂತ ಶೋಷಣೆಯೊಂದಿಗೆ. MCS ಸೇವೆಯು ಫೈರ್‌ವಾಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಗುಂಪುಗಳಾಗಿ ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. XSS ಪತ್ತೆಯಾದ ಸ್ಥಳದಲ್ಲಿ ಗುಂಪಿನ ಹೆಸರು. ಇದರ ವಿಶಿಷ್ಟತೆಯೆಂದರೆ, ವೆಕ್ಟರ್ ಅನ್ನು ತಕ್ಷಣವೇ ಪ್ರಚೋದಿಸಲಾಗಿಲ್ಲ, ನಿಯಮಗಳ ಪಟ್ಟಿಯನ್ನು ನೋಡುವಾಗ ಅಲ್ಲ, ಆದರೆ ಗುಂಪನ್ನು ಅಳಿಸುವಾಗ:

ಅಂದರೆ, ಸನ್ನಿವೇಶವು ಈ ಕೆಳಗಿನಂತಿದೆ: ಆಕ್ರಮಣಕಾರರು ಹೆಸರಿನಲ್ಲಿ "ಲೋಡ್" ನೊಂದಿಗೆ ಫೈರ್ವಾಲ್ ನಿಯಮವನ್ನು ರಚಿಸುತ್ತಾರೆ, ನಿರ್ವಾಹಕರು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಅದನ್ನು ಗಮನಿಸುತ್ತಾರೆ ಮತ್ತು ಅಳಿಸುವಿಕೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಮತ್ತು ಇಲ್ಲಿ ದುರುದ್ದೇಶಪೂರಿತ JS ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ SVG ಚಿತ್ರಗಳಲ್ಲಿ XSS ನಿಂದ ರಕ್ಷಿಸಲು MCS ಡೆವಲಪರ್‌ಗಳಿಗೆ (ಅವುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗದಿದ್ದರೆ), ಡಿಜಿಟಲ್ ಭದ್ರತಾ ತಂಡವು ಶಿಫಾರಸು ಮಾಡಿದೆ:

• "ಕುಕೀಸ್" ನೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರತ್ಯೇಕ ಡೊಮೇನ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು ಇರಿಸಿ. ವಿಭಿನ್ನ ಡೊಮೇನ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು MCS ಗೆ ಬೆದರಿಕೆಯನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ.
• ಸರ್ವರ್‌ನ HTTP ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ, "ವಿಷಯ-ವಿಚಾರ: ಲಗತ್ತು" ಹೆಡರ್ ಅನ್ನು ಕಳುಹಿಸಿ. ನಂತರ ಫೈಲ್‌ಗಳನ್ನು ಬ್ರೌಸರ್‌ನಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, XSS ಶೋಷಣೆಯ ಅಪಾಯಗಳನ್ನು ತಗ್ಗಿಸಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಈಗ ಹಲವು ಮಾರ್ಗಗಳಿವೆ:

• "HTTP ಮಾತ್ರ" ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಸೆಷನ್ "ಕುಕೀಸ್" ಹೆಡರ್‌ಗಳನ್ನು ದುರುದ್ದೇಶಪೂರಿತ JavaScript ಗೆ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ;
• CSP ನೀತಿಯನ್ನು ಸರಿಯಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ XSS ಅನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಆಕ್ರಮಣಕಾರರಿಗೆ ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ;
• ಕೋನೀಯ ಅಥವಾ ರಿಯಾಕ್ಟ್‌ನಂತಹ ಆಧುನಿಕ ಟೆಂಪ್ಲೇಟ್ ಎಂಜಿನ್‌ಗಳು ಬಳಕೆದಾರರ ಬ್ರೌಸರ್‌ಗೆ ಔಟ್‌ಪುಟ್ ಮಾಡುವ ಮೊದಲು ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತವೆ.

ಎರಡು ಅಂಶದ ದೃಢೀಕರಣ ದೋಷಗಳು

ಖಾತೆಯ ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು, ಬಳಕೆದಾರರಿಗೆ ಯಾವಾಗಲೂ 2FA (ಎರಡು ಅಂಶ ದೃಢೀಕರಣ) ಸಕ್ರಿಯಗೊಳಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ಬಳಕೆದಾರರ ರುಜುವಾತುಗಳನ್ನು ರಾಜಿ ಮಾಡಿಕೊಂಡಿದ್ದರೆ ಆಕ್ರಮಣಕಾರರು ಸೇವೆಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುವುದನ್ನು ತಡೆಯಲು ಇದು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವಾಗಿದೆ.

ಆದರೆ ಎರಡನೇ ದೃಢೀಕರಣ ಅಂಶವನ್ನು ಬಳಸುವುದು ಯಾವಾಗಲೂ ಖಾತೆಯ ಸುರಕ್ಷತೆಯನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆಯೇ? 2FA ಅನುಷ್ಠಾನದಲ್ಲಿ ಈ ಕೆಳಗಿನ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳಿವೆ:

• OTP ಕೋಡ್‌ನ ಬ್ರೂಟ್-ಫೋರ್ಸ್ ಹುಡುಕಾಟ (ಒನ್-ಟೈಮ್ ಕೋಡ್‌ಗಳು). ಕಾರ್ಯಾಚರಣೆಯ ಸರಳತೆಯ ಹೊರತಾಗಿಯೂ, OTP ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯ ಕೊರತೆಯಂತಹ ದೋಷಗಳನ್ನು ದೊಡ್ಡ ಕಂಪನಿಗಳು ಎದುರಿಸುತ್ತವೆ: ಸ್ಲಾಕ್ ಕೇಸ್, ಫೇಸ್ಬುಕ್ ಪ್ರಕರಣ.
• ದುರ್ಬಲ ಪೀಳಿಗೆಯ ಅಲ್ಗಾರಿದಮ್, ಉದಾಹರಣೆಗೆ ಮುಂದಿನ ಕೋಡ್ ಅನ್ನು ಊಹಿಸುವ ಸಾಮರ್ಥ್ಯ.
• ನಿಮ್ಮ ಫೋನ್‌ನಲ್ಲಿ ಬೇರೆಯವರ OTP ಯನ್ನು ವಿನಂತಿಸುವ ಸಾಮರ್ಥ್ಯದಂತಹ ತಾರ್ಕಿಕ ದೋಷಗಳು ಆಗಿತ್ತು Shopify ನಿಂದ.

MCS ನ ಸಂದರ್ಭದಲ್ಲಿ, 2FA ಅನ್ನು Google Authenticator ಮತ್ತು ಆಧರಿಸಿ ಅಳವಡಿಸಲಾಗಿದೆ ಜೋಡಿ. ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಈಗಾಗಲೇ ಸಮಯ-ಪರೀಕ್ಷೆ ಮಾಡಲಾಗಿದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಭಾಗದಲ್ಲಿ ಕೋಡ್ ಪರಿಶೀಲನೆಯ ಅನುಷ್ಠಾನವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

MCS 2FA ಅನ್ನು ಹಲವಾರು ಸ್ಥಳಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ:

• ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುವಾಗ. ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿಯ ವಿರುದ್ಧ ರಕ್ಷಣೆ ಇದೆ: ಬಳಕೆದಾರರು ಒಂದು-ಬಾರಿ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ನಮೂದಿಸಲು ಕೆಲವು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತಾರೆ, ನಂತರ ಇನ್ಪುಟ್ ಅನ್ನು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನಿರ್ಬಂಧಿಸಲಾಗುತ್ತದೆ. ಇದು OTP ಯ ಬ್ರೂಟ್-ಫೋರ್ಸ್ ಆಯ್ಕೆಯ ಸಾಧ್ಯತೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
• 2FA ನಿರ್ವಹಿಸಲು ಆಫ್‌ಲೈನ್ ಬ್ಯಾಕಪ್ ಕೋಡ್‌ಗಳನ್ನು ರಚಿಸುವಾಗ, ಹಾಗೆಯೇ ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವಾಗ. ಇಲ್ಲಿ, ಯಾವುದೇ ವಿವೇಚನಾರಹಿತ ರಕ್ಷಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿಲ್ಲ, ನೀವು ಖಾತೆಗೆ ಪಾಸ್‌ವರ್ಡ್ ಮತ್ತು ಸಕ್ರಿಯ ಸೆಷನ್ ಹೊಂದಿದ್ದರೆ, ಬ್ಯಾಕಪ್ ಕೋಡ್‌ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಅಥವಾ 2FA ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.

OTP ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ರಚಿಸಲಾದ ಅದೇ ಶ್ರೇಣಿಯ ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯಗಳಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್ ಕೋಡ್‌ಗಳು ನೆಲೆಗೊಂಡಿವೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಅಲ್ಪಾವಧಿಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವ ಅವಕಾಶವು ತುಂಬಾ ಹೆಚ್ಚಾಗಿದೆ.

"Burp: Intruder" ಉಪಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು 2FA ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು OTP ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆ

ಪರಿಣಾಮವಾಗಿ

ಒಟ್ಟಾರೆಯಾಗಿ, MCS ಒಂದು ಉತ್ಪನ್ನವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿದೆ. ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಸಮಯದಲ್ಲಿ, ಪೆಂಟೆಸ್ಟಿಂಗ್ ತಂಡವು ಕ್ಲೈಂಟ್ VM ಗಳು ಮತ್ತು ಅವುಗಳ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಮತ್ತು ಪತ್ತೆಯಾದ ದೋಷಗಳನ್ನು MCS ತಂಡವು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸಿತು.

ಆದರೆ ಇಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಅಂಶವೆಂದರೆ ಭದ್ರತೆ ನಿರಂತರ ಕೆಲಸ. ಸೇವೆಗಳು ಸ್ಥಿರವಾಗಿಲ್ಲ, ಅವು ನಿರಂತರವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿವೆ. ಮತ್ತು ದುರ್ಬಲತೆಗಳಿಲ್ಲದೆ ಉತ್ಪನ್ನವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಅಸಾಧ್ಯ. ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ಸಮಯಕ್ಕೆ ಕಂಡುಹಿಡಿಯಬಹುದು ಮತ್ತು ಅವುಗಳ ಮರುಕಳಿಸುವಿಕೆಯ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಈಗ MCS ನಲ್ಲಿ ನಮೂದಿಸಲಾದ ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ. ಮತ್ತು ಹೊಸವರ ಸಂಖ್ಯೆಯನ್ನು ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಅವರ ಜೀವಿತಾವಧಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡವು ಇದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ:

• ಬಾಹ್ಯ ಕಂಪನಿಗಳಿಂದ ನಿಯಮಿತವಾಗಿ ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳನ್ನು ನಡೆಸುವುದು;
• ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಬೆಂಬಲಿಸಿ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಿ Mail.ru ಗುಂಪಿನ ಬಗ್ ಬೌಂಟಿ ಕಾರ್ಯಕ್ರಮದಲ್ಲಿ;
• ಭದ್ರತೆಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳಿ. 🙂

ಮೂಲ: www.habr.com