CRLF Examples

A CRLF is about as simple as vulnerabilities get!  CRLF stands for Carriage Return Line Feed, which is a term applied to new-line characters.  The attack involves injecting new-line characters in user-submitted data.

Very often web information is sent/received/stored in line-delimited format.  For example:

GET /spec.html HTTP/1.1
Cookie: name=value
Accept: */*

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value

Return-Path: <>
Received: from [] (
      by with esmtp
      id 15a5m1-0003z3-00
      for; Fri, 24 Aug 2001 01:28:38 +0000
Received: from ( [])
      by with ESMTP id f7O1Sci13128
      for <>; Thu, 23 Aug 2001 21:28:39 -0400
Errors-to: <>
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 21:27:04 -0400
From: Frederick M Avolio <>
Sender: <>
In-Reply-To: <>
Subject: test

CRLF and Email
Server-side code must be careful when generating output in line-delimited format.  For example, if your server-side code sets cookies or sends emails based on user-submitted data, it is possible that the data contains new-lines.  For example, if the string:

"This is a subject \nCC:" used as the Subject in an email, an attacker could cause your server to send spam.

Or, maybe your website allows visitors to order t-shirts online.  Every time someone orders a t-shirt, a little PHP script sends you an email.  A malicious user could get your script to send him a copy of the order, which might include sensitive information.  Worse, if a hacker knows what these order emails look like, he could then forge orders and maybe get free t-shirts.


Cleverly formed URLs can also cause problems if the web server or browser doesn't remove new-lines.  For example, the following URL can be typed into a browser and sent to a vulnerable web server:

" HTTP/1.0\015\012Cookie: name=value"

The web server might interpret it like this:

GET /page.php HTTP/1.0
Cookie: name=value

...which means a seemingly harmless link (in an email or forum, for example) could change the cookies seen by the server.  Likewise, a server which echoes back cookies may be tricked into sending extra cookies.  For example, if your server is implemented like this:

print ("HTTP/1.1 200 OK")
for k,v in cookies do
    print ("Cookie:", k, " = ", v)

... then a client could send you a cookie with the value "blah \nCookie: loggedin=true".

Using safe libraries will help mitigate this problem.  For example, the PHP setcookie function URL-encodes the cookie value.  However, it is still possible to set HTML headers, email headers, etc manually through PHP or any other server-side language.

CRLF and Access Logs

Very often a web server will be configured to log all traffic for various reasons.  Some companies are required to log access and may be subpoenaed for them.  By sending a CRLF-injected GET request to a vulnerability web server, it may be possible to add fake entries to the access log (or any other log-like file):

"\015\01211.20.09 GET /fakepage.php"

This might cause the following two log entries:

11.20.09 GET /page.php
11.20.09 GET /fakepage.php

While seemingly harmless, keep in mind that access logs have been used in criminal court as evidence.