HTTP request smuggling: Difference between revisions
No edit summary |
Citation bot (talk | contribs) Alter: journal. Add: doi-access, pages, volume, authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 198/533 |
||
| (23 intermediate revisions by 16 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|Web security vulnerability}} |
{{short description|Web security vulnerability}} |
||
{{HTTP}} |
{{HTTP}} |
||
'''HTTP request smuggling''' is a [[security exploit]] on the [[HTTP]] protocol that |
'''HTTP request smuggling''' ('''HRS''') is a [[security exploit]] on the [[HTTP]] protocol that takes advantage of an inconsistency between the interpretation of [[List of HTTP header fields#content-length-response-header|<code>Content-Length</code>]] and [[List of HTTP header fields#transfer-encoding-response-header|<code>Transfer-Encoding</code>]] headers between HTTP server implementations in an [[HTTP proxy server]] chain.<ref>{{Cite web|url=https://cwe.mitre.org/data/definitions/444.html|title=CWE - CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') (4.0)|website=cwe.mitre.org|access-date=2020-03-13}}</ref><ref name="portswigger1">{{Cite web|url=https://portswigger.net/web-security/request-smuggling|title=What is HTTP request smuggling? Tutorial & Examples {{!}} Web Security Academy|website=portswigger.net|access-date=2020-03-13}}</ref> It was first documented in 2005 by Linhart et al.<ref name="HRS">{{cite web|url=https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf|title=HTTP request smuggling|date=2005|last1=Linhart|first1=Chaim|last2=Klein|first2=Amit|last3=Heled|first3=Ronen|last4=Orrin|first4=Steve}}</ref> |
||
The Transfer-Encoding header works by defining a directive on how to interpret the body of the [[HTTP request]], with the common and necessary directive for this attack being the [[chunked transfer encoding]].<ref name ="mozillatransfer">{{Cite web|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding|title=Transfer-Encoding|website=developer.mozilla.org|access-date=2022-12-15}}</ref> When the Transfer-Encoding header is present, the Content-Length header is supposed to be omitted.<ref name="mozillatransfer" /> Working similarly but with a different syntax, the Content-Length header works by specifying the size in bytes of the body as a value in the header itself. <ref name="mozillacontentlength">{{Cite web|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length#:~:text=The%20Content%2DLength%20header%20indicates,bytes%2C%20sent%20to%20the%20recipient.|title=Content-Length|website=developer.mozilla.org|access-date=2022-12-15}}</ref> Vulnerabilities arise when both of these headers are included in a malicious HTTP request, bypassing security functions meant to prevent malicious HTTP queries to the server by causing either the [[Frontend and backend|front-end or back-end]] server to incorrectly interpret the request. <ref name="imperva">{{Cite web|url=https://www.imperva.com/learn/application-security/http-request-smuggling/#:~:text=An%20HTTP%20request%20smuggling%20vulnerability,through%20a%20malicious%20HTTP%20query|title=HTTP Request Smuggling|website=imperva.com|access-date=2022-12-15}}</ref> HTTP request smuggling commonly takes the form of CL.TE, TE.CL, or TE.TE, although more complex attacks using HRS do exist. <ref name='imperva' /> |
|||
==Types== |
==Types== |
||
===CL.TE=== |
===CL.TE=== |
||
In this type of HTTP request smuggling, the front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header.<ref name="portswigger1"> |
In this type of HTTP request smuggling, the front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header.<ref name="portswigger1" /> The attack would be carried out with the first part of the request declaring a zero length chunk. <ref name="imperva" /> The front end server seeing this would only read the first part of the request and unintentionally pass the second part to the back end server. <ref name="imperva" /> Once passed through to the back end server, it would be treated as the next request and processed, carrying out the attackers hidden request. <ref name="imperva" /> |
||
===TE.CL=== |
===TE.CL=== |
||
In this type of HTTP request smuggling, the front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header.<ref name="portswigger1" /> |
In this type of HTTP request smuggling, the front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header.<ref name="portswigger1" /> In this attack, a hacker would declare the valid length of the first chunk, which houses the malicious request and then declare a second chunk with a length of 0. <ref name ="imperva" /> When the front end server sees the second chunk with a length of 0 it believes the request to be complete and passes it along to the back end server. <ref name="imperva" /> The back end server processes the request using the Content-Length header, however, and as a result the malicious request left in the first chunk go unprocessed until they are treating as being at the start of next request in the sequence and are carried out. <ref name="portswigger1" /> |
||
===TE.TE=== |
|||
In this type of HTTP request smuggling, the front end and backend both process the request using Transfer-Encoding header, but the header can be obfuscated in a way (for example by nonstandard whitespace formatting or duplicate headers) that makes one of the servers but not the other one ignore it.<ref name="portswigger1" /> Obscuring the header may take the form of adding in an incorrect character, such as Transfer-Encoding: xchunked, or an unusual new line character between 'Transfer-Encoding' and ': chunked'. <ref name="imperva" /> If one of the front of back end servers still processes these obfuscated HTTP requests, then the rest of the attack will be similar to how CL.TE or TE.CL attacks work. <ref name="imperva" /> |
|||
==Prevention== |
==Prevention== |
||
The best prevention to these attacks would clearly be if front end and back end servers interpreted HTTP requests the same way. However, this is usually not an option as [[load balancer]]s support backend servers run on distinct platforms, using different software. <ref name="imperva" /> Most variants{{Specify|date=May 2023}} of this attack can be prevented by using [[HTTP/2]], as it uses a different method to determine the length of a request. Another method of avoiding the attack is for the frontend server to normalize HTTP requests before passing them to the backend, ensuring that they get interpreted in the same way. <ref name="portswigger1" /> Configuring a [[web application firewall]] is another good way to prevent HRS attacks as many feature technology that identify attack attempts and either blocks or sanitize the suspicious incoming requests.<ref name="imperva" /> |
|||
HTTP/2 should be used for backend connections and web server accepting same type of HTTP header should be used. <ref name="portswigger1" /> |
|||
Grenfeldt et al. (2021) found that most front-end web servers (e.g. proxy servers) provided the parsing features for hindering in practice, all the known HRS attacks on the back-end web servers.<ref name="Grenfeldt et al. (2021)">{{cite conference| vauthors=Grenfeldt M, Olofsson A, Engström V, Lagerström R |date=2021 | title=Attacking websites using HTTP request smuggling: empirical testing of servers and proxies | book-title=2021 IEEE 25th international enterprise distributed object computing conference (EDOC) | pages=173–181| publisher=IEEE| location=Australia | doi=10.1109/EDOC52215.2021.00028}}</ref> Huang et al. (2022) proposed a method using [[Flask (web framework)|Flask]] so to implement suitable parsing features that prevent HRS attacks, from a front-end program or web server.<ref name="Huang et al. (2022)">{{cite journal| vauthors=Huang Q, Chiu M, Chen Y, Sun H |date=2022 | title=Attacking websites: detecting and preventing HTTP request smuggling attacks| journal=Security and Communication Networks|volume=2022 |pages=1–14 | doi=10.1155/2022/3121177 |doi-access=free }}</ref> |
|||
== References == |
== References == |
||
{{reflist}} |
{{reflist}} |
||
| Line 17: | Line 25: | ||
[[Category:Web security exploits]] |
[[Category:Web security exploits]] |
||
[[Category:Hypertext Transfer Protocol headers]] |
[[Category:Hypertext Transfer Protocol headers]] |
||
{{computer-security-stub}} |
|||
{{Web-stub}} |
|||
Latest revision as of 21:04, 26 May 2023
| HTTP |
|---|
 |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
HTTP request smuggling (HRS) is a security exploit on the HTTP protocol that takes advantage of an inconsistency between the interpretation of Content-Length and Transfer-Encoding headers between HTTP server implementations in an HTTP proxy server chain.[1][2] It was first documented in 2005 by Linhart et al.[3]
The Transfer-Encoding header works by defining a directive on how to interpret the body of the HTTP request, with the common and necessary directive for this attack being the chunked transfer encoding.[4] When the Transfer-Encoding header is present, the Content-Length header is supposed to be omitted.[4] Working similarly but with a different syntax, the Content-Length header works by specifying the size in bytes of the body as a value in the header itself. [5] Vulnerabilities arise when both of these headers are included in a malicious HTTP request, bypassing security functions meant to prevent malicious HTTP queries to the server by causing either the front-end or back-end server to incorrectly interpret the request. [6] HTTP request smuggling commonly takes the form of CL.TE, TE.CL, or TE.TE, although more complex attacks using HRS do exist. [6]
Types[edit]
CL.TE[edit]
In this type of HTTP request smuggling, the front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header.[2] The attack would be carried out with the first part of the request declaring a zero length chunk. [6] The front end server seeing this would only read the first part of the request and unintentionally pass the second part to the back end server. [6] Once passed through to the back end server, it would be treated as the next request and processed, carrying out the attackers hidden request. [6]
TE.CL[edit]
In this type of HTTP request smuggling, the front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header.[2] In this attack, a hacker would declare the valid length of the first chunk, which houses the malicious request and then declare a second chunk with a length of 0. [6] When the front end server sees the second chunk with a length of 0 it believes the request to be complete and passes it along to the back end server. [6] The back end server processes the request using the Content-Length header, however, and as a result the malicious request left in the first chunk go unprocessed until they are treating as being at the start of next request in the sequence and are carried out. [2]
TE.TE[edit]
In this type of HTTP request smuggling, the front end and backend both process the request using Transfer-Encoding header, but the header can be obfuscated in a way (for example by nonstandard whitespace formatting or duplicate headers) that makes one of the servers but not the other one ignore it.[2] Obscuring the header may take the form of adding in an incorrect character, such as Transfer-Encoding: xchunked, or an unusual new line character between 'Transfer-Encoding' and ': chunked'. [6] If one of the front of back end servers still processes these obfuscated HTTP requests, then the rest of the attack will be similar to how CL.TE or TE.CL attacks work. [6]
Prevention[edit]
The best prevention to these attacks would clearly be if front end and back end servers interpreted HTTP requests the same way. However, this is usually not an option as load balancers support backend servers run on distinct platforms, using different software. [6] Most variants[specify] of this attack can be prevented by using HTTP/2, as it uses a different method to determine the length of a request. Another method of avoiding the attack is for the frontend server to normalize HTTP requests before passing them to the backend, ensuring that they get interpreted in the same way. [2] Configuring a web application firewall is another good way to prevent HRS attacks as many feature technology that identify attack attempts and either blocks or sanitize the suspicious incoming requests.[6]
Grenfeldt et al. (2021) found that most front-end web servers (e.g. proxy servers) provided the parsing features for hindering in practice, all the known HRS attacks on the back-end web servers.[7] Huang et al. (2022) proposed a method using Flask so to implement suitable parsing features that prevent HRS attacks, from a front-end program or web server.[8]
References[edit]
- ^ "CWE - CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') (4.0)". cwe.mitre.org. Retrieved 2020-03-13.
- ^ a b c d e f "What is HTTP request smuggling? Tutorial & Examples | Web Security Academy". portswigger.net. Retrieved 2020-03-13.
- ^ Linhart, Chaim; Klein, Amit; Heled, Ronen; Orrin, Steve (2005). "HTTP request smuggling" (PDF).
- ^ a b "Transfer-Encoding". developer.mozilla.org. Retrieved 2022-12-15.
- ^ "Content-Length". developer.mozilla.org. Retrieved 2022-12-15.
- ^ a b c d e f g h i j k "HTTP Request Smuggling". imperva.com. Retrieved 2022-12-15.
- ^ Grenfeldt M, Olofsson A, Engström V, Lagerström R (2021). "Attacking websites using HTTP request smuggling: empirical testing of servers and proxies". 2021 IEEE 25th international enterprise distributed object computing conference (EDOC). Australia: IEEE. pp. 173–181. doi:10.1109/EDOC52215.2021.00028.
- ^ Huang Q, Chiu M, Chen Y, Sun H (2022). "Attacking websites: detecting and preventing HTTP request smuggling attacks". Security and Communication Networks. 2022: 1–14. doi:10.1155/2022/3121177.