CRLF injection also known as HTTP response spliting is a simple web attack but very powerful. Hackers activily exploit this web application vulnerability to perform a large variety of some serious attacks. This was also founed in Google Adwords some years ago.
The term CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. These two represent the END OF LINE for various internet protocols. When programmers write code for web applications they split headers based on where the CRLF is found. If a malicious user is able to inject his own CRLF sequence into an HTTP stream, he is able to maliciously control the way a web application functions.
Example:
suppose you got a link from a malicious user
http://www.yoursite.com/page.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3Ethis is the Hacker's Content%3C/html%3E
You will get a page saying
this is the Hacker's Content
But this page is generated by the server in which hacker has injected HTML code. More sophisticated variations of this example can lead to poisioning of the client's web-cache, cookies, XSS, temporary or permanent defacement of web pages and even information theft.
Preventing CRLF
The best protection is filtering user input
properly sanitize URLs that point to web pages on your site containing any server re-direction code.
The term CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). They're used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows both a CR and LF are required to note the end of a line, whereas in Linux/UNIX a LF is only required. These two represent the END OF LINE for various internet protocols. When programmers write code for web applications they split headers based on where the CRLF is found. If a malicious user is able to inject his own CRLF sequence into an HTTP stream, he is able to maliciously control the way a web application functions.
Example:
suppose you got a link from a malicious user
http://www.yoursite.com/page.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3Ethis is the Hacker's Content%3C/html%3E
You will get a page saying
this is the Hacker's Content
But this page is generated by the server in which hacker has injected HTML code. More sophisticated variations of this example can lead to poisioning of the client's web-cache, cookies, XSS, temporary or permanent defacement of web pages and even information theft.
Preventing CRLF
The best protection is filtering user input
properly sanitize URLs that point to web pages on your site containing any server re-direction code.
0 comments:
Post a Comment