Security functions suggested to be turned off by default - guess why

Slideshare.net provides a service that enables you to upload your presentations and share it with the public. Just like at YouTube or vimeo you cannot only watch the shared content directly at the slideshare.net website, but you can also use an "embed"-feature and incorporate presentation contents into your own web presence.

For each presentation slideshare offers a convenient HTML-code snippet that is ready to copy&paste it into your site. Here a shortened example:

<object id="__sse763783" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=grant-presentation-1227010891051378-9&stripped_title=welcome-to-ip-surveillance-101-presentation&userName=grantsupplies"><param name="allowFullScreen" value="true"><param name="allowScriptAccess" value="always"></object>
As you can see, the embedded code loads a flash player that in turn shows the desired presentation contents. By default, the privileges of a flash file are restricted if it is loaded from a different domain than the surrounding web site. That means that the flash file cannot access the DOM of the site, nor make JavaScript calls or similar things.

However, the code snippet above loads with the "allowScriptAccess=always" parameter. That means that these security functions are actively turned off: the embedded content has full access to and control over the the embedding site. Altering the DOM or stealing cookies are just two possible scenarios.

Here what slideshare does with its - through the suggested embed code quasi self-given - privileges: it actively integrates "web analytics functions" (other people would call this "user tracking") into the embedding web site. Just take the HTML snippet shown above and integrate it into an otherwise completely empty web page. Here is what you will end up with:


The HTML view shows that you unknowingly just integrated "analytics functions" from Google Analytics and Scorecardresearch. Central tracking of which IP adress accessed which contents at what time made easy. Given that you have absolutely no control over what these scripts do with your site, nor what information they collect about your users, you may have a problem if your site is located in a German-speaking area. Whether the use of Google Analytics is legal here is still a source of controversal discussions.

If you decide to use the default flash security mechanisms ("allowScriptAccess=samedomain") the shown scripts disappear, as the slideshare content is not allowed to alter the page - just give it a try yourself.

Security functions leading to the attackers goal

Sometimes a security function just does not work like intended by its designers or developers. Suppose you run a website that offers a file download mechanism implemented in PHP. Nowadays, many programmers are aware of the security problems that might arise from flawed implementations in that area. They might easily lead to the disclosure of arbitrary files of the web server.

Always keeping the user experience in mind, people often tend to sanitize user input (e.g. removing unwanted content and then continue) rather than failing gracefully and confront the user with an error message. Just as in the following code:

$dlfile = $_GET["file"];
...
// Prevent directory traversal attack
$dlfile = preg_replace("/\.\.\//", "", $dlfile);
...

What the developer tries to do is removing "../" sequences in order to prevent attackers from reading other files than those available in a specific directory. In the following example, the first request should lead to a normal file download, while the second one should be prevented:

/download.php?file=funnycat.jpg
/download.php?file=../../../../etc/passwd

What has not been kept in mind is that the parameter can be chosen in order that it uses the regular expression to construct the desired outcome. Just consider the following input (without the parenthesis):

/download.php?file=.(../)./.(../)./.(../)./.(../)./etc/passwd

Those parts highlighted with parenthesis are removed by the "security function". The rest stays. This leads to:

../../../../etc/passwd

In order to prevent that pitfall there are many possible solutions. The easiest would be to simply abort processing when an error is encountered, instead of applying sanitization. Others include performing the sanitization repeatedly, whitelist allowed file names or character ranges, or (in this case) link to the files directly instead of using a PHP indirection. Of course, contents could also be stored in a database instead, but SQL injections are a different topic ;-)