1. Følg med
  2. Blog
  3. 2011
  • Publisert
  • 7 min

Possible security issues when caching

I ran into this problem while I was working on an EPiServer solution at work some time ago. The website had a control that generated links for different language branches in the solution. The control read a query string parameter from the current url to generate the links. It also cached all the links when done. All well so far. When a user visited the site, the control checked if the list of links where in the cache, and if so, served them out to the user.

 

The big problem with this solution is if I am an Evil Hacker and want to do something to the next visitor on the site, I can just inject whatever script I want into the website (!), and that script will run when the next user visits the page. Here is how it works:
1. A regular user goes to the website on http://www.mywebpage.com/param=no
2. The list generating control generates all the links from the current url. Usually the list will look something like this:
<a href="http://www.mywebpage.no/">Norge</a>
<a href="http://www.mywebpage.se/">Sverige</a>
<a href="http://www.mywebpage.dk/">Danmark</a>
<a href="http://www.mywebpage.de/">Tyskland</a>
This could of course be any kind of list, the important thing is that it uses the url to generate the list.
3. The Evil Hacker however does a little trick. Instead of going to http://www.mywebpage.com, he types in something like http://www.mywebpage.com/param=no<script>alert(‘This is an XSS attack’)</script>
4. Since the values in the current url is no longer the same as before, the cache will be invalidated and the list will be generated once more. The thing is that now the list will look like this instead:
<a href="http://www.mywebpage.no/">Norge
<script>alert(‘This is an XSS attack’)</script>
</a>
<a href="http://www.mywebpage.se/">Sverige
<script>alert(‘This is an XSS attack’)</script>
</a>
<a href="http://www.mywebpage.dk/">Danmark
<script>alert(‘This is an XSS attack’)</script>
</a>
<a href="http://www.mywebpage.de/">Tyskland
<script>alert(‘This is an XSS attack’)</script>
</a>
5. Ok, so the Evil Hacker will get a lot of popups when surfing the site, no big deal right?
6. The problem is that since this list is cached, the injected script is actually PERSISTED on the site and will run when the next user visits the site. The new user does not have to click any suspect links from the Evil Hacker or anything like that, he can surf the site on the sites real url, and the scripts will still run. If the Evil Hacker has a little imagination he can probably do something more dangerous than just pop up a window like in this example, for instance hijack the user’s session, steal the user’s usernames and passwords if he logs into another site while on the infected site and a lot more. This could do some real damage.
7. So what can you do to prevent this? One important thing to do is certainly too always check the input whether it is from a form, the url, a query string parameter and so forth (remember all input is potentially unsafe input). It is actually better to check that the input is legal rather than checking for illegal input. That is because it is always lots of different ways to write a character (i.e.  <, &#60, &#x3C, &lt;, u003c is all ways of writing the same character under different encodings) . Also you should be very careful if you are tempted to use string.replace() to remove illegal characters, because it is a technic that is very easy to trick. (What will myString.Replace(“SCRIPT”, “”) become if myString contains SCRSCRIPTIPT?).
Ok, that is just one small tip in the art of protecting once website. It exist lots of ways for a hacker to do damage, so always be careful when reading input and writing output to your site that you do not have full control over. To learn more about this topic you can search for XSS or Cross Site Scripting. 

The big problem with this solution is if I am an Evil Hacker and want to do something to the next visitor on the site, I can just inject whatever script I want into the website, and that script will run when the next user visits the page(!).

Here is how it works:

1. A regular user goes to the website on http://www.mywebpage.com/param=no

2. The list generating control generates all the links from the current url. Usually the list will look something like this:

<a href="http://www.mywebpage.no/">Norge</a>
<a href="http://www.mywebpage.se/">Sverige</a>
<a href="http://www.mywebpage.dk/">Danmark</a>
<a href="http://www.mywebpage.de/">Tyskland</a>

This could of course be any kind of list, the important thing is that it uses the url to generate the list.

3. The Evil Hacker however does a little trick. Instead of going to http://www.mywebpage.com, he types in something like

http://www.mywebpage.com/param=no<script>alert(‘This is an XSS attack’)</script>

4. Since the values in the current url is no longer the same as before, the cache will be invalidated and the list will be generated once more. The thing is that now the list will look like this instead:

<a href="http://www.mywebpage.no/">Norge<script>alert(‘This is an XSS attack’)</script></a>
<a href="http://www.mywebpage.se/">Sverige<script>alert(‘This is an XSS attack’)</script></a>
<a href="http://www.mywebpage.dk/">Danmark<script>alert(‘This is an XSS attack’)</script></a>
<a href="http://www.mywebpage.de/">Tyskland<script>alert(‘This is an XSS attack’)</script></a>

5. Ok, so the Evil Hacker will get a lot of popups when surfing the site, no big deal right?

6. The problem is that since this list is cached, the injected script is actually PERSISTED on the site and will run when the next user visits the site. The new user does not have to click any suspect links from the Evil Hacker or anything like that, he can surf the site on the sites real url, and the scripts will still run. If the Evil Hacker has a little imagination he can probably do something more dangerous than just pop up a window like in this example, for instance hijack the user’s session, steal the user’s usernames and passwords if he logs into another site while on the infected site and a lot more. This could do some real damage.

7. So what can you do to prevent this? One important thing to do is certainly too always check the input whether it is from a form, the url, a query string parameter and so forth (remember all input is potentially unsafe input). It is actually better to check that the input is legal rather than checking for illegal input. This is because it is always lots of different ways to write a character (i.e.  <, &#60, &#x3C, &lt;, u003c is all ways of writing the same character under different encodings), so it is just to easy to miss one variant. Also you should be very careful if you are tempted to use string.replace() to remove illegal characters, because it is a technic that is very easy get around. What will myString.Replace(“SCRIPT”, “”) become if myString contains SCRSCRIPTIPT?.


Ok, that is just one small tip in the art of protecting once website. It exist lots of ways for a hacker to do damage, so always be careful when reading input and writing output that you do not have full control over to your site. To learn more about this topic you can search for XSS or Cross Site Scripting. 

 

Happy Coding!