There are less than a dozen HTTP headers that are related to CORS but I'll try to explain a few commonly used CORS headers:

A pre-flight request is just a normal HTTP request that happens before the actual cross-domain communication. The logic behind this is to ensure the client and server are fully compatible (protocol, security, and so on) with each other before the data is actually exchanged. If they are not, then the relevant error is raised.

Please keep that in mind that a pre-flight request only triggers if:

The following is a typical pre-flight request-response pair:

Request:

OPTIONS / HTTP/1.1
Origin: http://api.user.com
Access-Control-Request-Method: PUT
Host: api.example.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Browser

Response:

HTTP/1.1 204 No Content 
Access-Control-Allow-Origin: http://api.user.com
Access-Control-Allow-Methods: GET, POST, PUT
Content-Type: text/html; charset=utf-8

A simple CORS request is similar to a pre-flight request without the initial capability exchange sequence occurring. In a typical simple CORS request, the following sequence happens:

Request: http://example.com – Origin A

Response: http://cdn.prakharprasad.com – Origin B

The following characters are not encoded as part of the URL encoding technique:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

The following characters are encoded as part of the URL encoding technique:

!	*	'	(	)	;	:	@	&	=	+	$	,	/	?	#	[	]

The following is a list of characters with their encoded form:

Although the percent encoding technique typically encodes restricted characters, it is also possible to encode unrestricted characters by providing an equivalent ASCII hexadecimal code for the character, preceded by %.

For example, if we had to encode A into percent encoding, we can simply provide %41; here, 41 is the hexadecimal for 65, which, in turn, is the ASCII code for capital A.

A web-based URL encoder/decoder can be found here:

http://meyerweb.com/eric/tools/dencoder/

In percent encoding, if we had %3C as our percent-encoded character then it gets decoded into <. In double encoding, the percent-encoded character is again encoded, which means that the % prefixed hex-character gets encoded again to %25 plus the hex-character of the original character. So if I had to encode < using double encoding, I'll first encode it into its percent-encoded format, which is %3c and then again percent encode the % character. The result of this will be %253c. Normally, this should be decoded only once but there are scenarios where the developer makes the mistake of decoding it multiple times or situations in which this happens by design. This effectively results in bypasses of filters depending on the scenario:

In 2001, a directory traversal vulnerability in Microsoft's popular IIS 5.0 web server appeared. The vulnerability was critical because it was a zero authentication code execution vulnerability. The vulnerability was due to double decoding of a URL passed into the request.

Microsoft issued security bulletin MS01-026 to address this flaw and also described the vulnerability in their own words. I'll quote the technical advisory published at Microsoft's website:

This excerpt mentions specifically that a vulnerability results because a second, superfluous decoding pass is performed after the security checks are completed. This clearly speaks by itself that double decoding is done by mistake in the IIS server that allows someone to traverse path names and execute commands by communicating with the cmd.exe parser; the code gets executed under the rights of the IIS webserver account.

Whenever IIS was asked to serve a CGI page with ../../ in the path which goes outside the root directory then the request would have got blocked as it is a clear path traversal outside of the root directory.

Assuming that the root directory is a Windows folder, if we send the following request, it will be blocked as it contains ../../ for directory traversal inside the path name.

Normal URL:

http://example.com/scripts/../../winnt/system32/cmd.exe?/c+dir+c:\

Then using the superfluous second decoding, as Microsoft likes to call it. We can perform path traversal and execute commands by hitting the command-line parser of Windows.

So the following double-encoded URL will bypass and execute code under the context of IIS server account name.

Double-encoded URL:

http://example.com/scripts/%252E%252E%252F%252E%252E%252Fwinnt/system32/cmd.exe?/c+dir+c:\

We have covered a directory traversal security check bypass through the double encoding technique. In this section, I'll cover how we can evade some XSS filters or checks that perform double decoding of the input.

Assuming that we've an XSS filter that detects <, >, /, or their percent-encoded forms, we can apply the double encoding technique to our XSS payload, if our input gets recursively decoded.

Original request with XSS payload (blocked): http://www.example.com/search.php?q=<script>alert(0)</script>

Percent-encoded XSS payload (blocked):

http://www.example.com/search.php?q=%3Cscript%3Ealert(0)%3C%2Fscript%3E

Double-percent-encoded payload (allowed): http://www.example.com/search.php?q=%253Cscript%253Ealert(0)%253C%252Fscript%253E

Basically, we can tabulate the encodings that we've just done:

Before I end this topic, I must say the double encoding technique to bypass countermeasures is very powerful provided that our requirements (such as recursive decoding). It can be applied to other attack techniques such as SQL injections.

Double encoding can be further extrapolated into triple encoding and so on. For triple encoding, all we need to is prefix %25 then append 25 then the hex code; the triple encoding for < will be %25253C.

Base64 encoding contains a character set of 64 printable ASCII characters. The following set of characters is used to encode binary to text:

The following table is used for indexing the values to their respective Base64 encoding alternatives:

The encoding process is as follows:

Example:

Let us take the word God. We'll make a table to demonstrate the process more easily:

Therefore, the Base64 equivalent for God becomes R29k.

However, a problem arises when the character groups are do not exactly form the 24-bit pattern. Let me illustrate this. Consider the word PACKT. We cannot divide this word into 24-bit groups equally. Hypothetically speaking, the first 24-bit group is PAC and second group KT?, where ? signifies a missing 8-bit character. This is the place where the padding mechanism of Base64 kicks in. I'll explain that in the next section.

Wherever there is a missing character (8-bit) in forming the 24-bit groups then for every missing character (8-bit), = is appended in place of that. So, for one missing character, = is used; for every two missing characters == is used: