Input Validation Attacks | Canonicalization Attacks — Exploitbyte

Input validation attacks occur in much the same way buffer overflows do. Effectively, a programmer has not sufficiently reviewed the input from a user (or attacker, remember!) before passing it onto the application code.

In other words, the program will choke on the input or, worse, allow something through that shouldn’t get through. The results can be devastating, including denial of service, identity spoofing, and outright compromise of the system, as is the case with buffer overruns. In this section, we take a look at a few input validation attacks and discuss how programmers can resolve the fundamental issues.

Canonicalization Attacks

In the web world, few other attacks have given so much pause to so many developers. When the first expression of this vulnerability was unearthed, people thought it was another simple “breaking web root” exercise. this attack manifested itself in the Unicode (ISO 10646) and Double Decode attacks in 2001–2002.

Canonicalization is the process for determining how various forms or characters of a word are resolved to a single name or character, otherwise called the canonical form. For example, the backslash character is / in ASCII and %2f in hex. When represented in UTF-8 (the ACSII preserving encoding method for Unicode), it is also %2f, because UTF-8 requires characters be represented in the smallest number of legal bytes.

Input Validation Attacks

However, the backslash character can also be represented as %c0%af, which is the 2-byte UTF-8 escape. You could also use 3-byte and 4-byte representations. Technically, these multibyte variations are invalid, but some applications don’t treat them as invalid. And if a web server canonicalizes that character after the rules for directory traversal are checked, you could have a mess on your hands.

For example, the following URL would normally be blocked at the web server URL parser and not allowed because it includes dot-dot characters and backslashes,

http://192.160.0.154/scripts/../../../../winnt/system32/cmd.exe?/c+dir

This attempt is to break web root, crawl up the drive’s directory, and then go down the /winnt/system32 directory to execute the cmd.exe command. The command shell then would execute the dir command, which is an internal DOS command within cmd .exe. Now, if we were to change out the backslash characters (/) for the overlong UTF-8 representation of that character (%c0%af) or any of a number of similar representations, the vulnerable version of IIS4 would not spot the backslash characters and allow the directory traversal:

http://192.168.0.154/scripts/..%c0%af..%c0%af..%c0%af../winnt/system32/ cmd.exe?/c+dir

There are other kinds of canonical-form defects, including double-escapes and Unicode escapes. Again, this type of attack takes advantage of the lack of proper translation of characters into their normalized form before being handled. This attack can take many forms and must be thoroughly addressed in all your running applications.

In recent years, there have been numerous canonicalization issues with web servers, such as IIS and Apache and their technologies, including PHP and ASP.NET.

Canonicalization Countermeasures

The best way to mitigate canonicalization attacks is to address the problem with the language you are writing in. For example, for ASP.NET applications, Microsoft recommends that you insert the following in the global.asax file, which mitigates some forms of path canonicalization:

<script language=”vb” runat=”server”>

Sub Application_BeginRequest (Sender as Object, E as EvenArgs)

If (Request.Path.IndexOf(chr(92) ) >= 0 OR _

System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.

PhysicalPath) then

Throw new HttpException(404, “Not Found”)

End If

End Sub

</script>

Effectively, this event handler in global.asax prevents invalid characters and malformed URLs by performing path verifications.

You can also mitigate these threats by being very hardcore about what data your application will accept. You can use a tool such as URLScan in front of your IIS5 web server to mitigate many of these issues. Note that URLScan can also help prevent your application sitting on top of IIS from being attacked through vulnerabilities in your code. Also note that IIS6 has the URLScan-like capability built right in.

Web Application and Database Attacks

there are many ways to bypass web application security. From identity spoofing to variable stuffing, each technique can allow an attacker to either assume someone’s online identity, overflow an application, or get around some controls on that application.

Web Application/Database Attack Countermeasures

The fundamental problem here, as with almost every attack discussed in this chapter, is a lack of proper input sanitization performed by the programmer. If every input data element (form fields, network packets, and so on) accepted by all network-connected software (such as browsers, database servers, and web servers) was properly validated and sanitized, most of these problems would simply disappear.

If you got any problem or need some more information you can comment below we will help you soon. To learn more about Hacking you can check more.

Originally published at https://exploitbyte.com on March 30, 2020.