ಸಮಸ್ಯೆಯ ಮುಖ್ಯ ಅಂಶವೆಂದರೆ ಮುಂಭಾಗಗಳು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ HTTP ಪ್ರೋಟೋಕಾಲ್ಗೆ ವಿವಿಧ ಹಂತದ ಬೆಂಬಲವನ್ನು ಒದಗಿಸುತ್ತವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ವಿಭಿನ್ನ ಬಳಕೆದಾರರಿಂದ ವಿನಂತಿಗಳನ್ನು ಸಾಮಾನ್ಯ ಚಾನಲ್ಗೆ ಸೇರಿಸುತ್ತವೆ. ಮುಂಭಾಗವನ್ನು ಸ್ವೀಕರಿಸುವ ವಿನಂತಿಗಳು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಪ್ರಕ್ರಿಯೆಯ ವಿನಂತಿಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು, ದೀರ್ಘಾವಧಿಯ TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಅದರ ಮೂಲಕ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ರವಾನಿಸಲಾಗುತ್ತದೆ, ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಸರಪಳಿಯಲ್ಲಿ ರವಾನಿಸಲಾಗುತ್ತದೆ, HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಬೇರ್ಪಡಿಸಲಾಗುತ್ತದೆ. ವಿನಂತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ಶೀರ್ಷಿಕೆಗಳು "ವಿಷಯ-ಉದ್ದ" (ವಿನಂತಿಯಲ್ಲಿನ ಡೇಟಾದ ಒಟ್ಟು ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ) ಮತ್ತು "
ಮುಂಭಾಗವು "ವಿಷಯ-ಉದ್ದ"ವನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸಿದರೆ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ ಆದರೆ "ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" (ಉದಾಹರಣೆಗೆ, Akamai CDN ಇದನ್ನು ಮಾಡಿದೆ) ಅಥವಾ ಪ್ರತಿಯಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್ ಅನ್ನು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಬೆಂಬಲಿಸಿದರೆ, HTTP ಹೆಡರ್ ಪಾರ್ಸರ್ಗಳ ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಆಕ್ರಮಣಕ್ಕಾಗಿ ಬಳಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಮುಂಭಾಗದ ತುದಿಯು “ಟ್ರಾನ್ಸ್ಫರ್-ಎನ್ಕೋಡಿಂಗ್: xchunked”, “ಟ್ರಾನ್ಸ್ಫರ್-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್ನಂತಹ ಸಾಲುಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದಾಗ ”, “ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್” :[ಟ್ಯಾಬ್] ಚಂಕ್ಡ್", "X: X[\n]ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್", "ಟ್ರಾನ್ಸ್ಫರ್-ಎನ್ಕೋಡಿಂಗ್[\n]: ಚಂಕ್ಡ್" ಅಥವಾ "ಟ್ರಾನ್ಸ್ಫರ್-ಎನ್ಕೋಡಿಂಗ್ : ಚಂಕ್ಡ್", ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಅವುಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ).
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಆಕ್ರಮಣಕಾರರು "ವಿಷಯ-ಉದ್ದ" ಮತ್ತು "ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಹೆಡರ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು, ಆದರೆ "ವಿಷಯ-ಉದ್ದ"ದಲ್ಲಿನ ಗಾತ್ರವು ಚಂಕ್ಡ್ ಚೈನ್ನ ಗಾತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನಿಜವಾದ ಮೌಲ್ಯಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗಿದೆ. ಮುಂಭಾಗವು "ವಿಷಯ-ಉದ್ದ" ಪ್ರಕಾರ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೆ ಮತ್ತು "ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಆಧಾರದ ಮೇಲೆ ಬ್ಲಾಕ್ ಪೂರ್ಣಗೊಳ್ಳಲು ಬ್ಯಾಕೆಂಡ್ ಕಾಯುತ್ತಿದ್ದರೆ, ನಂತರ ಡೇಟಾದ ಅಂತ್ಯವು "ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್" ಅನ್ನು ಆಧರಿಸಿದೆ ಮೊದಲೇ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯ ಉಳಿದ ಬಾಲವು ಮುಂದಿನ ವಿನಂತಿಯ ಆರಂಭದಲ್ಲಿ ಆಕ್ರಮಣಕಾರರಾಗಿರುತ್ತದೆ, ಅಂದರೆ. ಆಕ್ರಮಣಕಾರರು ಮುಂದೆ ರವಾನೆಯಾಗುವ ಬೇರೊಬ್ಬರ ವಿನಂತಿಯ ಪ್ರಾರಂಭಕ್ಕೆ ಅನಿಯಂತ್ರಿತ ಡೇಟಾವನ್ನು ಲಗತ್ತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಬಳಸಿದ ಮುಂಭಾಗ-ಬ್ಯಾಕೆಂಡ್ ಸಂಯೋಜನೆಯಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸಲು, ನೀವು ಮುಂಭಾಗದ ಮೂಲಕ ಈ ರೀತಿಯ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು:
ಪೋಸ್ಟ್ / HTTP/1.1 ಕುರಿತು
ಹೋಸ್ಟ್: example.com
ವರ್ಗಾವಣೆ-ಎನ್ಕೋಡಿಂಗ್: ಚಂಕ್ಡ್
ವಿಷಯ-ಉದ್ದ: 4
1
Z
Q
ಬ್ಯಾಕೆಂಡ್ ವಿನಂತಿಯನ್ನು ತಕ್ಷಣವೇ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದಿದ್ದರೆ ಮತ್ತು ಚಂಕ್ಡ್ ಡೇಟಾದ ಅಂತಿಮ ಶೂನ್ಯ ಬೌಂಡಿಂಗ್ ಬ್ಲಾಕ್ ಆಗಮನಕ್ಕಾಗಿ ಕಾಯುತ್ತಿದ್ದರೆ ಸಮಸ್ಯೆ ಇರುತ್ತದೆ. ಹೆಚ್ಚು ಸಂಪೂರ್ಣ ಪರಿಶೀಲನೆಗಾಗಿ
ನಿಜವಾದ ದಾಳಿಯನ್ನು ನಡೆಸುವುದು ದಾಳಿಗೊಳಗಾದ ಸೈಟ್ನ ಸಾಮರ್ಥ್ಯಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, Trello ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ನ ಮೇಲೆ ದಾಳಿ ಮಾಡುವಾಗ, ನೀವು ವಿನಂತಿಯ ಪ್ರಾರಂಭವನ್ನು ಬದಲಾಯಿಸಬಹುದು ("PUT /1/members/1234 ನಂತಹ ಬದಲಿ ಡೇಟಾ... x=x&csrf =1234&username=testzzz&bio=cake”) ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರ ಮೂಲ ವಿನಂತಿ ಮತ್ತು ಅದರಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ದೃಢೀಕರಣದ ಕುಕೀ ಸೇರಿದಂತೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಿ. saas-app.com ಮೇಲಿನ ದಾಳಿಗಾಗಿ, ವಿನಂತಿಯ ಪ್ಯಾರಾಮೀಟರ್ಗಳಲ್ಲಿ ಒಂದನ್ನು ಬದಲಿಸುವ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ JavaScript ಕೋಡ್ ಅನ್ನು ಬದಲಿಸಲು ಸಾಧ್ಯವಿದೆ. redhat.com ಮೇಲಿನ ದಾಳಿಗಾಗಿ, ಆಕ್ರಮಣಕಾರರ ವೆಬ್ಸೈಟ್ಗೆ ಮರುನಿರ್ದೇಶಿಸಲು ಆಂತರಿಕ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಬಳಸಲಾಗಿದೆ (“POST /search?dest=../assets/idx?redir=// ಫಾರ್ಮ್ನ ವಿನಂತಿ[ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]/ HTTP/1.1").
ವಿಷಯ ವಿತರಣಾ ನೆಟ್ವರ್ಕ್ಗಳಿಗಾಗಿ ವಿಧಾನವನ್ನು ಬಳಸುವುದರಿಂದ "ಹೋಸ್ಟ್:" ಹೆಡರ್ ಅನ್ನು ಬದಲಿಸುವ ಮೂಲಕ ವಿನಂತಿಸಿದ ಸೈಟ್ ಅನ್ನು ಸರಳವಾಗಿ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಕಂಟೆಂಟ್ ಕ್ಯಾಶಿಂಗ್ ಸಿಸ್ಟಮ್ಗಳ ವಿಷಯಗಳನ್ನು ವಿಷಪೂರಿತಗೊಳಿಸಲು ಮತ್ತು ಸಂಗ್ರಹಿಸಲಾದ ಗೌಪ್ಯ ಡೇಟಾವನ್ನು ಹೊರತೆಗೆಯಲು ದಾಳಿಯನ್ನು ಬಳಸಬಹುದು. ವಿಧಾನದ ಪರಾಕಾಷ್ಠೆಯು PayPal ಮೇಲಿನ ದಾಳಿಯ ಸಂಘಟನೆಯಾಗಿದೆ, ಇದು ದೃಢೀಕರಣದ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರು ಕಳುಹಿಸಿದ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು (paypal.com/us/gifts ಪುಟದ ಸಂದರ್ಭದಲ್ಲಿ JavaScript ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು iframe ವಿನಂತಿಯನ್ನು ಮಾರ್ಪಡಿಸಲಾಗಿದೆ. ಯಾವ CSP (ವಿಷಯ ಭದ್ರತಾ ನೀತಿ) ಅನ್ವಯಿಸಲಾಗಿಲ್ಲ).
ಕುತೂಹಲಕಾರಿಯಾಗಿ, 2005 ರಲ್ಲಿ ಇತ್ತು
ಮೂಲ: opennet.ru