Monthly Archives: September 2013

Simple Security Tip: window.location = window.location.pathname can cause Open-Redirect issue!

I found this issue in a website and I thought it would be nice to share the info.

If you search “window.location = window.location.pathname” in Google, you will see some people are using this method for redirection purposes. This can make a website vulnerable to Open Redirect issue though. In fact, if there is any sensitive value in the URL, it can be sent to the attacker as well.

Quick reference: when you are in “” page, “window.location.pathname” in Javascript will return “/something/file.ext” as the value.

Now if you use this “pathname” value for redirection without having any validation, it can lead to Open-Redirect vulnerability. This happens when “pathname” starts with two slash characters “//” instead of a single slash character with a valid domain-name afterward. However, it is not easy to start the URL path with two slash characters and a domain-name and point to the vulnerable page at the same time!

Here is a vulnerable sample page:

It contains the following vulnerable JS code:

window.location = window.location.pathname + '?Secrets=SecretValue1#MoreSecrets=SecretValue2!';

Now I like to redirect the user to my fake logger which is located at:

First solution?

I was thinking to use directory traversal method to have my target domain in the URL and also point to the vulnerable page:

However, when I open this page in any browser, it strips out my logger URL before it sends the request to the server, and it becomes like this:

Note: It still keeps two slash characters, and this fails the redirection as http://tips/ is not available. This behaviour can be used as a detection technique for this issue though!

Anyway, this method does not work and I failed!

Second try:

My vulnerable page has been hosted in a Windows host with IIS. This means, there is no difference between a slash and a backslash and their encoded values in the path! As a result I found this solution to keep my logger URL and also open the target page:\..\..\../tips/js-location-pathname.html

However, this only works in Firefox and I have to use encoding for IE and Google Chrome:

Job done! Success!

Now I can redirect the user to my dangerous page and hijack the secrets in any browsers!


This issue is exploitable if the website with a vulnerable page

1- has been hosted in a Windows host with IIS!

2- has a URL-rewrite rule that still serve a page that contains the vulnerable JS.

3- has an error handling page (404 page?) that contains the vulnerable JS.

Destroy your addiction to CandyCrush and secure your sweet future!

It’s too little too late for me to overcome my addiction to this simple game! I am going to show how easy it is to cheat in a game like CandyCrush by using a proxy such as Fiddler; and I want to discuss some simple techniques for the developers to make this cheating process in flash games/applications harder! By the way, I am not talking about advanced games such as GTA-V here!

First of all, download Fiddler from the following link:

Now, download the following script for fiddler:

Make sure you can decrypt HTTPS requests in Fiddler by installing its certificate (you can remove it later) [more help:].

Now insert the downloaded script in Fiddler custom rules section [more help:].

If you start playing CandyCrush in a browser that has Fiddler as its proxy, you will see the difference. Although I have not added some of the features/cheats, it is enough to kill your joy and addiction by doing whatever you want in the game!

What is going on here? I don’t like cheating!

The answer is simple; CandyCrush relies on the responses from its server without verifying their integrity. As a result, you can change the server responses to say I have 100 lives.

At the same time, the server does not have any way to verify whether something has been manipulated or not! In fact, it has a token but it is possible for you to make that token yourself.

I should say that this problem is not specific to CandyCrush; this is a common problem for offline and client-side games/applications that need to talk to their servers. Their code is available on the client-side and it is possible for a curious user to use some reverse engineering techniques to figure out how it works and even change the game flow for his/her own benefit.

In this example, CandyCrush uses Flash technology and it is possible to decompile it by using a SWF file decompiler. Somebody has already done that in this link: (who says in the security field we do not give reference to each other?! ;) ). Basically, the algorithm that the server uses to verify if something has been manipulated has already been included in the binary file and you can find it to forge your own request. And that’s what we have in the provided Fiddler script to give you a happy ending everytime! Your score also starts with 777 to be as lucky as possible (I am thinking about seven 7s now! Oh well, you can change it yourself!).

Addressing the common problems – Make the target harder:

This is a controversial subject and everybody has their own ideas. I think at the moment it is impossible to completely solve all the problems as anyone can manipulate the binary files directly. I recommend the following methods to decrease the attack surface and make the manipulation and interception harder (only true rich warriors with a lot of free time will stand!).

A) How a client-side application can trust its server responses and stored values?

1- Use Certificate Pining and encrypt the channel. Ignore the responses if the certificate is invalid! Sign every single response from the server and verify the signatures.

2- Obfuscate the code when you are compiling the application. It can make it more complicated for someone to look at your code and an attacker will probably lose his/her interest when they do not have a strong motivation!

3- Encrypt sensitive values such as score, remaining moves, level number, and so on in storages and in memory to stop applications like Cheat Engine. It is also possible to generate a dynamic random string when you open the application (flash file) and XORing the values with them for read and write (initial values can still be vulnerable though).

4- Communicate under TCP to make the interception more difficult. If it is feasible, use a new protocol instead of HTTP to make the interception harder!

B) How can the main server trust the requests?

1- When using Certificate Pining in the client-side, verify the certificate by encrypting the messages in the request. Although the parameter values can be modified inside the application just before the encryption, this method can stop external proxies from intercepting the messages.

2- Replay attack is also important in this scenario. Each request must be dependent on the user specific parameters such as userid, username, location, level, IP address, and so on. In other words, Bob should not be able to send Alice’s request to the server without being detected and blocked. We can also use cryptographic nonce key here as well (; whenever a client-side application has access to Internet and wants to send some data to its server, it should use a nonce key that has been received previously from the server in the last transaction. This nonce value should be sent to the server in the next request (or a known shared word can be encrypted by this nonce to be sent to the server) and server can always keep records of these nonce values and deactivate the used ones.

3- Collect the game state and statistical data in order to send them to the server in a secure way to be processed. This can be done in the middle of the game as well. Imagine if you could send the user’s moves and all the game data to the server; then, you could really predict if the user was a winner or not; you could tell what their score is by having that information and replaying the game; you can see how long it took for the user to finish those levels and so on. Collected statistical data can be used to detect the cheaters. Although it is possible to forge this data as well, it can be quite difficult to figure out its format and the correct values especially if you use a compressed and an encrypted algorithm. Unfortunately, this will increase the work load on the server.

By the way, you are more than welcome to add your recommendation as a comment if you want to help the developers.

Note: CandyCrush had a typical security issue in accepting negative numbers. I think you can guess what it was: you could increase your items by sending negative numbers to the server! This issue has been patched now by ignoring the negative and zero values (I think they should not even send a numerical value in this request. They could deduct 1 from the resources in the server-side as soon as they see a used-item request). They do not have any blog or forum to give anybody any credits though.