Image for post
Image for post
Uploading image files…

Assembla security exploit: session take over

Yvo Schaap
Mar 14, 2017 · 3 min read

Why you shouldn’t trust SVG images (hint: it supports <script>)

I reported a security exploit in Assembla, a project management tool similar to Jira, last week. The tool is used by thousands of software development teams, contains development roadmaps, internal ticketing, (private) documentation and (git) code repositories.

Below I’ll share my exploit write-up:

  • Assembla allows users to upload files. The uploaded file is then hosted on a separate subdomain (, but by replacing the subdomain in the file url with the file is coincidently accessible from the main app domain. I found something similar with Facebook as well in ‘12.
  • Hence somebody could upload a exploit file, serve it from which would circumvent default cross-domain browser protections, exposing a user’s session (cookie), hence hijacking an complete account.
  • I reported this issue a while back using a POC javascript exploit, and was awarded 99 dollars in Assembla credits as thank you. I wasn’t asked any details, beyond my initial report.
  • A few days later, they changed a setting in the response header (Content-Disposition: attachment) forcing all uploaded files to trigger a download in the browser, instead of allowing it to execute/run inline. So the attack (e.g. my javascript exploit) would only trigger a file download for a target user, instead of the browser running it within the security scope.
  • Still the subdomain of uploaded user files was still accessible from any subdomain (including app. or www.).
  • Note: It is a minimal security practice to always serve user content away from the main domain name ( in this case). Think of, or

Fast forward to last week:

  • I noticed images uploaded by users would still render inline instead a forced download. This might indicate there is a way to trigger inline serving of uploaded files, although possibly restricted to images.
  • And that hypothesis was correct, I found images and plaintext files to be not forced as a download.
  • Unfortunately, that includes SVG image files, which can contain javascript (!!). And browsers run that javascript in the browser’s window, and within the security scope of of the domain.
  • So I created an POC exploit SVG image, which did a XHR request to a interesting endpoint (e.g. /user/edit).
  • The uploaded SVG ended up on, but I could still replace the domain in the url with, from there anyone with an active Assembla session that would access the SVG, the javascript would execute, and be able to execute any action using the user’s session. Including even silently passing back any details of the complete workspace to a roque endpoint.

In the POC exploit above, I show the SVG executes my javascript within the app’s domain. If you are logged in, it shows you your username.

What we can learn from this:

  • Make sure security issues raised by researchers are dealt with in a proper way (Hackerone?)
  • Make sure security issues are completely resolved, and stay resolved. Check with the researcher, his time spend on the exploit makes him an expert.
  • Never rely on whitelisting certain file types for security. This will never be fool proof.

7 march: reported exploit.
14 march: confirmed exploit is resolved by forcing download of SVG.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store