0

I've run a security scan at my server and got some CRLF exploitation warning.

So, as recommended, I've sanitized all my query parameter inputs like below.

var encodedStringSafeFromCRLF = Server.UrlDecode(Request.QueryString["address"])
                         .Replace("\r", string.Empty)
                         .Replace("%0d", string.Empty)
                         .Replace("%0D", string.Empty)
                         .Replace("\n", string.Empty)
                         .Replace("%0a", string.Empty)
                         .Replace("%0A", string.Empty);

Let's say, a genuine user is sending an address to me via "address" query parameter.

Example -

https://mywebsite.com/details?instId=151711&address=24%20House%20Road%0aSomePlace%0aCountry

Since "%0A" will be stripped from the above string, the address would now become '24HouseRoadSomePlaceCountry' which was not my expectation.

How should I handle this ? If I make code changes for CRLF this changes how the input is intrepreted. If input string is not sanitized, then it would open my server for CRLF attack.

Any suggestions here ?

  • 1
    If your strings have a *legitimate* need for newline characters, then obviously they should not be replaced -- instead you need to put in the actual work of ensuring the value can't end up being used for an attack (because there are no scenarios where the newline is output in such a way that it could break anything), and then the sanitizer needs to be configured to not warn on this particular instance since things have been verified. – Jeroen Mostert Feb 14 '22 at 15:39
  • @JeroenMostert - Can you please explain with examples kindly ? any code samples may help – now he who must not be named. Feb 14 '22 at 16:02
  • 1
    That's the point -- it's not about code, "write this and you're safe". You need to read up on what CRLF attacks are, and how an attacker might go about it. Only then can you determine what kind of code you should write -- this may vary from changing some output when logs are written, to even not having to do anything at all because nothing in your setup is vulnerable. There is plenty of material online, but only you can determine which of it is relevant by looking at where your strings actually end up. ASP.NET itself nor your code will have any intrinsic trouble processing newlines. – Jeroen Mostert Feb 14 '22 at 16:39

1 Answers1

1

If you really need the user to supply data with CRLF sequences, then I would not filter those. As always, never trust user-supplied data in any way: do not use it to generate HTTP headers, responses or write to log files.

In general, it's safer to filter the other way around: specify all the characters you are willing to accept, and filter out everything else.

If you need to write the data to a log, you could for example URL encode the data first, so that "naked" CR LF are never written there.

I might internally specify that I use just \n as the newline, and convert all \r, \n, and \r\n into just one representation \n internally. So the rest of the code does not have to handle all versions.