ಫ್ರಂಟ್-ಎಂಡ್-ಬ್ಯಾಕೆಂಡ್ ಸಿಸ್ಟಂಗಳ ಮೇಲೆ ಹೊಸ ದಾಳಿಯು ನಿಮ್ಮನ್ನು ವಿನಂತಿಗಳಿಗೆ ಸೇರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ

ಮುಂಭಾಗವು HTTP/2 ಮೂಲಕ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಮತ್ತು HTTP/1.1 ಮೂಲಕ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ರವಾನಿಸುವ ವೆಬ್ ವ್ಯವಸ್ಥೆಗಳು "HTTP ವಿನಂತಿ ಸ್ಮಗ್ಲಿಂಗ್" ದಾಳಿಯ ಹೊಸ ರೂಪಾಂತರಕ್ಕೆ ಒಡ್ಡಿಕೊಂಡಿವೆ, ಇದು ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಅನುಮತಿಸುತ್ತದೆ. ಮುಂಭಾಗ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ನಡುವೆ ಅದೇ ಹರಿವಿನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾದ ಇತರ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳ ವಿಷಯಗಳಿಗೆ ಬೆಣೆ. ಕಾನೂನುಬದ್ಧ ವೆಬ್‌ಸೈಟ್‌ನೊಂದಿಗೆ ಸೆಷನ್‌ನಲ್ಲಿ ದುರುದ್ದೇಶಪೂರಿತ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸಲು, ಪ್ರವೇಶ ನಿರ್ಬಂಧ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಮತ್ತು ದೃಢೀಕರಣ ನಿಯತಾಂಕಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ದಾಳಿಯನ್ನು ಬಳಸಬಹುದು.

ಸಮಸ್ಯೆಯು ವೆಬ್ ಪ್ರಾಕ್ಸಿಗಳು, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು, ವೆಬ್ ವೇಗವರ್ಧಕಗಳು, ವಿಷಯ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಇತರ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಇದರಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಫ್ರಂಟ್-ಎಂಡ್-ಟು-ಬ್ಯಾಕೆಂಡ್ ರೀತಿಯಲ್ಲಿ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಅಧ್ಯಯನದ ಲೇಖಕರು Netflix, Verizon, Bitbucket, Netlify CDN ಮತ್ತು Atlassian ವ್ಯವಸ್ಥೆಗಳ ಮೇಲೆ ದಾಳಿ ಮಾಡುವ ಸಾಧ್ಯತೆಯನ್ನು ಪ್ರದರ್ಶಿಸಿದರು ಮತ್ತು ದುರ್ಬಲತೆಗಳನ್ನು ಗುರುತಿಸಲು 56 ಸಾವಿರ ಡಾಲರ್‌ಗಳನ್ನು ಬಹುಮಾನ ಕಾರ್ಯಕ್ರಮಗಳಲ್ಲಿ ಪಡೆದರು. F5 ನೆಟ್‌ವರ್ಕ್ ಉತ್ಪನ್ನಗಳಲ್ಲಿಯೂ ಸಹ ಸಮಸ್ಯೆಯನ್ನು ದೃಢಪಡಿಸಲಾಗಿದೆ. ಸಮಸ್ಯೆಯು ಅಪಾಚೆ http ಸರ್ವರ್‌ನಲ್ಲಿ (CVE-2021-33193) mod_proxy ಮೇಲೆ ಭಾಗಶಃ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಆವೃತ್ತಿ 2.4.49 ರಲ್ಲಿ ಪರಿಹಾರವನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ (ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಮಸ್ಯೆಯ ಕುರಿತು ಮೇ ಆರಂಭದಲ್ಲಿ ತಿಳಿಸಲಾಯಿತು ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು 3 ತಿಂಗಳ ಕಾಲಾವಕಾಶ ನೀಡಲಾಗಿದೆ). nginx ನಲ್ಲಿ, "ವಿಷಯ-ಉದ್ದ" ಮತ್ತು "ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್" ಹೆಡರ್‌ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕೊನೆಯ ಬಿಡುಗಡೆಯಲ್ಲಿ (1.21.1) ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಅಟ್ಯಾಕ್ ಪರಿಕರಗಳನ್ನು ಈಗಾಗಲೇ ಬರ್ಪ್ ಟೂಲ್‌ಕಿಟ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ ಮತ್ತು ಟರ್ಬೊ ಇಂಟ್ರೂಡರ್ ವಿಸ್ತರಣೆಯ ರೂಪದಲ್ಲಿ ಲಭ್ಯವಿದೆ.

ಟ್ರಾಫಿಕ್‌ಗೆ ವೆಡ್ಜಿಂಗ್ ವಿನಂತಿಗಳ ಹೊಸ ವಿಧಾನದ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವವು ಎರಡು ವರ್ಷಗಳ ಹಿಂದೆ ಅದೇ ಸಂಶೋಧಕರು ಗುರುತಿಸಿದ ದುರ್ಬಲತೆಯನ್ನು ಹೋಲುತ್ತದೆ, ಆದರೆ HTTP/1.1 ಮೂಲಕ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಮುಂಭಾಗಗಳಿಗೆ ಸೀಮಿತವಾಗಿದೆ. ಮುಂಭಾಗ-ಬ್ಯಾಕೆಂಡ್ ಸ್ಕೀಮ್‌ನಲ್ಲಿ, ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಹೆಚ್ಚುವರಿ ನೋಡ್‌ನಿಂದ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೆನಪಿಸಿಕೊಳ್ಳೋಣ - ಮುಂಭಾಗ, ಇದು ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ದೀರ್ಘಕಾಲೀನ TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಇದು ವಿನಂತಿಗಳನ್ನು ನೇರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಈ ಸಾಮಾನ್ಯ ಸಂಪರ್ಕದ ಮೂಲಕ, ವಿಭಿನ್ನ ಬಳಕೆದಾರರಿಂದ ವಿನಂತಿಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ರವಾನಿಸಲಾಗುತ್ತದೆ, ಇದು ಸರಣಿಯನ್ನು ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಅನುಸರಿಸುತ್ತದೆ, HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.

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

ಲೈನ್ ಮಟ್ಟದಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಲಾದ ಪಠ್ಯ ಪ್ರೋಟೋಕಾಲ್ HTTP/1.1 ಗಿಂತ ಭಿನ್ನವಾಗಿ, HTTP/2 ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ ಮತ್ತು ಪೂರ್ವ-ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಮ್ಯಾನಿಪುಲೇಟ್ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, HTTP/2 ಸಾಮಾನ್ಯ HTTP ಹೆಡರ್‌ಗಳಿಗೆ ಅನುಗುಣವಾದ ಹುಸಿ-ಹೆಡರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. HTTP/1.1 ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಮುಂಭಾಗವು ಈ ಹುಸಿ-ಹೆಡರ್‌ಗಳನ್ನು ಇದೇ ರೀತಿಯ HTTP ಹೆಡರ್‌ಗಳಿಗೆ HTTP/1.1 ಆಗಿ ಭಾಷಾಂತರಿಸುತ್ತದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ, ಮೂಲ ವಿನಂತಿಯ ನಿಯತಾಂಕಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯಿಲ್ಲದೆ, ಮುಂಭಾಗದಿಂದ ಹೊಂದಿಸಲಾದ HTTP ಹೆಡರ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುವ ಕುರಿತು ಬ್ಯಾಕೆಂಡ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, "ವಿಷಯ-ಉದ್ದ" ಮತ್ತು "ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್" ಮೌಲ್ಯಗಳನ್ನು ಹುಸಿ-ಹೆಡರ್‌ಗಳ ರೂಪದಲ್ಲಿ ರವಾನಿಸಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು HTTP/2 ನಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಎಲ್ಲಾ ಡೇಟಾದ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರದಲ್ಲಿ. ಆದಾಗ್ಯೂ, HTTP/2 ವಿನಂತಿಯನ್ನು HTTP/1.1 ಗೆ ಪರಿವರ್ತಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಈ ಹೆಡರ್‌ಗಳನ್ನು ಒಯ್ಯಲಾಗುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಗೊಂದಲಗೊಳಿಸಬಹುದು. ಎರಡು ಪ್ರಮುಖ ದಾಳಿಯ ರೂಪಾಂತರಗಳಿವೆ: H2.TE ಮತ್ತು H2.CL, ಇದರಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್ ತಪ್ಪಾದ ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್ ಅಥವಾ ವಿಷಯ-ಉದ್ದದ ಮೌಲ್ಯದಿಂದ ದಾರಿತಪ್ಪಿಸುತ್ತದೆ, ಅದು ಮುಂಭಾಗದ ಮೂಲಕ ಸ್ವೀಕರಿಸಿದ ವಿನಂತಿಯ ದೇಹದ ನೈಜ ಗಾತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. HTTP/2 ಪ್ರೋಟೋಕಾಲ್.

ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ಗೆ HTTP/2 ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವಾಗ ವಿಷಯ-ಉದ್ದದ ಹುಸಿ-ಹೆಡರ್‌ನಲ್ಲಿ ತಪ್ಪಾದ ಗಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು H2.CL ದಾಳಿಯ ಉದಾಹರಣೆಯಾಗಿದೆ. ಈ ವಿನಂತಿಯು HTTP/1.1 ಮೂಲಕ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವಾಗ ಇದೇ ರೀತಿಯ HTTP ಹೆಡರ್ ವಿಷಯ-ಉದ್ದದ ಸೇರ್ಪಡೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಆದರೆ ವಿಷಯ-ಉದ್ದದಲ್ಲಿನ ಗಾತ್ರವು ನಿಜವಾದ ಒಂದಕ್ಕಿಂತ ಕಡಿಮೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಿರುವುದರಿಂದ, ಬಾಲದಲ್ಲಿರುವ ಡೇಟಾದ ಭಾಗವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮುಂದಿನ ವಿನಂತಿಯ ಪ್ರಾರಂಭ.

ಉದಾಹರಣೆಗೆ, HTTP/2 :ಮೆಥೋಡ್ POST :path /n

ಬ್ಯಾಕೆಂಡ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ: POST /n HTTP/1.1 ಹೋಸ್ಟ್: www.netflix.com ವಿಷಯ-ಉದ್ದ: 4 abcdGET /n HTTP/1.1 ಹೋಸ್ಟ್: 02.rs?x.netflix.com ಫೂ: ಬಾರ್

ವಿಷಯ-ಉದ್ದವು 4 ರ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಬ್ಯಾಕೆಂಡ್ ವಿನಂತಿಯ ಮುಖ್ಯ ಭಾಗವಾಗಿ “abcd” ಅನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಉಳಿದ “GET /n HTTP/1.1...” ಅನ್ನು ನಂತರದ ವಿನಂತಿಯ ಪ್ರಾರಂಭವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿದೆ. ಅಂತೆಯೇ, ಸ್ಟ್ರೀಮ್ ಡಿಸಿಂಕ್ರೊನೈಸ್ ಆಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, ನಕಲಿ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ನಕಲಿ ವಿನಂತಿಯಲ್ಲಿ "ಹೋಸ್ಟ್:" ಹೆಡರ್‌ನಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಹೋಸ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದರಿಂದ ಕ್ಲೈಂಟ್ "ಸ್ಥಳ: https://02.rs?x.netflix.com/n" ಎಂಬ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ ಮತ್ತು Netflix ಸೈಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮ್ಮ JavaScript ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುವುದು ಸೇರಿದಂತೆ ಕ್ಲೈಂಟ್‌ಗೆ ಅನಿಯಂತ್ರಿತ ವಿಷಯವನ್ನು ಕಳುಹಿಸಲು ಅನುಮತಿಸಲಾಗಿದೆ.

ಎರಡನೇ ದಾಳಿ ಆಯ್ಕೆಯು (H2.TE) "ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಹೆಡರ್ ಅನ್ನು ಬದಲಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. HTTP/2 ನಲ್ಲಿ ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್ ಹುಸಿ-ಹೆಡರ್‌ನ ಬಳಕೆಯನ್ನು ನಿರ್ದಿಷ್ಟತೆಯ ಮೂಲಕ ನಿಷೇಧಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ವಿನಂತಿಗಳನ್ನು ತಪ್ಪಾಗಿ ಪರಿಗಣಿಸಲು ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಇದರ ಹೊರತಾಗಿಯೂ, ಕೆಲವು ಮುಂಭಾಗದ ಅಳವಡಿಕೆಗಳು ಈ ಅಗತ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು HTTP/2 ನಲ್ಲಿ ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್ ಹುಸಿ-ಹೆಡರ್ ಅನ್ನು ಬಳಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಇದನ್ನು ಇದೇ ರೀತಿಯ HTTP ಹೆಡರ್ ಆಗಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ. “ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್” ಹೆಡರ್ ಇದ್ದರೆ, ಬ್ಯಾಕೆಂಡ್ ಅದನ್ನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು “{size}\r\n{block ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಗಾತ್ರದ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು “ಚಂಕ್ಡ್” ಮೋಡ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ತುಂಡು ತುಂಡಾಗಿ ಪಾರ್ಸ್ ಮಾಡಬಹುದು }\r\n{size} \r\n{block}\r\n0", ಒಟ್ಟಾರೆ ಗಾತ್ರದಿಂದ ಆರಂಭಿಕ ವಿಭಜನೆಯ ಹೊರತಾಗಿಯೂ.

ಅಂತಹ ಅಂತರದ ಉಪಸ್ಥಿತಿಯನ್ನು ವೆರಿಝೋನ್ನ ಉದಾಹರಣೆಯಿಂದ ಪ್ರದರ್ಶಿಸಲಾಯಿತು. ಸಮಸ್ಯೆಯು ದೃಢೀಕರಣ ಪೋರ್ಟಲ್ ಮತ್ತು ವಿಷಯ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸಂಬಂಧಿಸಿದೆ, ಇದನ್ನು ಹಫಿಂಗ್ಟನ್ ಪೋಸ್ಟ್ ಮತ್ತು ಎಂಗಾಡ್ಜೆಟ್‌ನಂತಹ ಸೈಟ್‌ಗಳಲ್ಲಿಯೂ ಬಳಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, HTTP/2: :method POST:path /identitfy/XUI x=

ಬ್ಯಾಕೆಂಡ್‌ಗೆ HTTP/1.1 ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವಲ್ಲಿ ಫಲಿತಾಂಶವಾಗಿದೆ: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com ವಿಷಯ-ಉದ್ದ: 66 ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್: 0 GET /oops HTTP/1.1 ಹೋಸ್ಟ್: psres. ನಿವ್ವಳ ವಿಷಯ- ಉದ್ದ: 10x=

ಬ್ಯಾಕೆಂಡ್, ಪ್ರತಿಯಾಗಿ, "ಕಂಟೆಂಟ್-ಲೆಂತ್" ಹೆಡರ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದೆ ಮತ್ತು "ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಆಧಾರದ ಮೇಲೆ ಇನ್-ಸ್ಟ್ರೀಮ್ ವಿಭಜನೆಯನ್ನು ನಿರ್ವಹಿಸಿತು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, OAuth ದೃಢೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವಿನಂತಿಗಳನ್ನು ತಡೆಹಿಡಿಯುವುದು ಸೇರಿದಂತೆ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಅವರ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಲು ದಾಳಿಯು ಸಾಧ್ಯವಾಗಿಸಿತು, ಅದರ ನಿಯತಾಂಕಗಳನ್ನು ರೆಫರರ್ ಹೆಡರ್‌ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ, ಜೊತೆಗೆ ದೃಢೀಕರಣ ಸೆಶನ್ ಅನ್ನು ಅನುಕರಿಸುವುದು ಮತ್ತು ರುಜುವಾತುಗಳನ್ನು ಕಳುಹಿಸಲು ಬಳಕೆದಾರರ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ದಾಳಿಕೋರನ ಹೋಸ್ಟ್‌ಗೆ. HTTP/2 ಅನ್ನು ಪಡೆಯಿರಿ

ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್ ಸ್ಯೂಡೋ-ಹೆಡರ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಅನುಮತಿಸದ HTTP/2 ಅಳವಡಿಕೆಗಳ ಮೇಲೆ ದಾಳಿ ಮಾಡಲು, "ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್" ಹೆಡರ್ ಅನ್ನು ಹೊಸ ಸಾಲಿನ ಅಕ್ಷರದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾದ ಇತರ ಹುಸಿ-ಹೆಡರ್‌ಗಳಿಗೆ ಲಗತ್ತಿಸುವ ಮೂಲಕ ಪರ್ಯಾಯವಾಗಿ ಒಳಗೊಂಡಿರುವ ಮತ್ತೊಂದು ವಿಧಾನವನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ ( ಈ ಸಂದರ್ಭದಲ್ಲಿ HTTP/1.1 ಗೆ ಪರಿವರ್ತಿಸಿದಾಗ ಎರಡು ಪ್ರತ್ಯೇಕ HTTP ಹೆಡರ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ).

ಉದಾಹರಣೆಗೆ, ಅಟ್ಲಾಸಿಯನ್ ಜಿರಾ ಮತ್ತು ನೆಟ್ಲಿಫೈ ಸಿಡಿಎನ್ (ಫೈರ್‌ಫಾಕ್ಸ್‌ನಲ್ಲಿ ಮೊಜಿಲ್ಲಾ ಪ್ರಾರಂಭ ಪುಟವನ್ನು ಪೂರೈಸಲು ಬಳಸಲಾಗುತ್ತದೆ) ಈ ಸಮಸ್ಯೆಯಿಂದ ಪ್ರಭಾವಿತವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, HTTP/2 ವಿನಂತಿ: ವಿಧಾನ POST:path / :authority start.mozilla.org foo b\r\n ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್ 0\r\n \r\n GET / HTTP/1.1\r\n ಹೋಸ್ಟ್ : evil-netlify-domain\r\n ವಿಷಯ-ಉದ್ದ: 5\r\n \r\nx=

HTTP/1.1 POST / HTTP/1.1 ವಿನಂತಿಯನ್ನು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ\r\n ಹೋಸ್ಟ್: start.mozilla.org\r\n ಫೂ: b\r\n ವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್\r\n ವಿಷಯ-ಉದ್ದ : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n ಹೋಸ್ಟ್: evil-netlify-domain\r\n ವಿಷಯ-ಉದ್ದ: 5\r\n \r \nx=

"ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್" ಶಿರೋಲೇಖವನ್ನು ಬದಲಿಸುವ ಮತ್ತೊಂದು ಆಯ್ಕೆಯೆಂದರೆ ಅದನ್ನು ಮತ್ತೊಂದು ಹುಸಿ-ಹೆಡರ್ನ ಹೆಸರಿಗೆ ಅಥವಾ ವಿನಂತಿಯ ವಿಧಾನದೊಂದಿಗೆ ಸಾಲಿಗೆ ಲಗತ್ತಿಸುವುದು. ಉದಾಹರಣೆಗೆ, ಅಟ್ಲಾಸಿಯನ್ ಜಿರಾವನ್ನು ಪ್ರವೇಶಿಸುವಾಗ, ಹುಸಿ-ಶೀರ್ಷಿಕೆ ಹೆಸರು "ಫೂ: ಬಾರ್\r\nಟ್ರಾನ್ಸ್‌ಫರ್-ಎನ್‌ಕೋಡಿಂಗ್" ಮೌಲ್ಯದೊಂದಿಗೆ "ಚಂಕ್ಡ್" HTTP ಹೆಡರ್‌ಗಳು "foo: bar" ಮತ್ತು "transfer-encoding: chunked" ಅನ್ನು ಸೇರಿಸಲು ಕಾರಣವಾಯಿತು. , ಮತ್ತು ಹುಸಿ ಹೆಡರ್ ":ಮೆಥೋಡ್" ಮೌಲ್ಯವನ್ನು "GET / HTTP/1.1\r\nವರ್ಗಾವಣೆ-ಎನ್‌ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಅನ್ನು "GET / HTTP/1.1\r\nಟ್ರಾನ್ಸ್‌ಫರ್-ಎನ್‌ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಎಂದು ಅನುವಾದಿಸಲಾಗಿದೆ.

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

ಮೂಲ: opennet.ru