Taiga-front: File attachments in Wiki for a secure project are publicly available

[apollolm]

Hello - Just discovered that file attachments in a private, secured Taiga Wiki are available to the public, if they have the correct URL.

It seems like access to resources inside of a private project should also be private.

This was tested by logging out of Taiga, and trying to hit an attachment's URL.
Also, tried using an incognito window to try the URL.

I'd assume that both ways should tell me that I don't have permissions to view the file. However, (to my surprise) I was able to download the requested resources. Also verified this by sending links to colleagues not part of my Taiga project. Same result.

Example of the URL structure (not an actual file):
https://media.taiga.io/attachments/2/9/6/b/9897dce234060800ec0c965a52fbf41c5d980104c6364f39dccd44c5b6b7/myfile.pdf

Is this by design? Thanks!

[superalex]

Hello @apollolm,

You are right, actually (by design), uploaded files are considered as media files served directly by the web server. Web server doesn't know about memberships and permissions from the app so if someone shares the url you can download the file (but these urls aren't predictable).

We will review it to see how it can be improved.

Regards!,

[abenrob]

If nothing else, this should be made explicit. Private implies private, and if that is not always the case, it should be very clear, as one may want to attach very sensitive documents to a private wiki.

[abenrob]

Possible path is django-private-files

[superalex]

Thanks @abenrob, I agree with you but have to review it and check how it fits in our current architecture.

[jespino]

Hi,

I want to explain the reasons behind this design decision. When you don't know the link, It's virtually the same than private file, because we prepend a random uuid before the file name, then have almost the same probability of get a valid file url than a valid user session. Then without knowing the link, the file is private.

The only lack of security is about having the link without rights to have the link. This can happen in various situations:

• If anybody share the link with an user without permissions. Anyway can share the file directly, then in this case there no security improvement.
• If anybody with permissions get the link, and after it, the permissions are revoked. If the user have downloaded the file, not imply a security improvement. But if the user hans't downloaded the file before, here is a small security improvement. (Anyway nothing ensure you that the user hasn't downloaded the file when he has the correct permissions).
• If accidentally filter the link for any reason. This can happen with the file too. In this case is a little bit error prone than a solution controlling the permissions.

Anyway the final decision was to use this model because is really simple, easy to implement, easy to deploy, and enough (IMHO) secure. We are open to rethink this model, but this approach is really common and is used by a lot of big and serious companies.

[apollolm]

Hi Jesus - thanks for responding. In our case, a developer uploaded a .pem file (credentials to SSH into an AMazon EC2 machine) to Taiga. Thinking it was secure, he added a hyperlink to it in a public Github Repo's Readme.md file.

Unfortunately, since it was publicly available, anybody could have downloaded it from the Readme. I think just letting users know that the files are available to anybody with the URL would be an improvement.

Thanks!
Ryan

On Aug 11, 2015, at 1:41 AM, Jesús Espino [email protected] wrote:

Hi,

I want to explain the reasons behind this design decision. When you don't know the link, It's virtually the same than private file, because we prepend a random uuid before the file name, then have almost the same probability of get a valid file url than a valid user session. Then without knowing the link, the file is private.

The only lack of security is about having the link without rights to have the link. This can happen in various situations:

If anybody share the link with an user without permissions. Anyway can share the file directly, then in this case there no security improvement.
If anybody with permissions get the link, and after it, the permissions are revoked. If the user have downloaded the file, not imply a security improvement. But if the user hans't downloaded the file before, here is a small security improvement. (Anyway nothing ensure you that the user hasn't downloaded the file when he has the correct permissions).
If accidentally filter the link for any reason. This can happen with the file too. In this case is a little bit error prone than a solution controlling the permissions.
Anyway the final decision was to use this model because is really simple, easy to implement, easy to deploy, and enough (IMHO) secure. We are open to rethink this model, but this approach is really common and is used by a lot of big and serious companies.

—
Reply to this email directly or view it on GitHub.

[pinpointgraphics]

Maybe this has been resolved long, but just chiming in: Another problem with this approach is that you can never predict that search engines are capable of finding links in log files or elsewhere and -since the files are public- index them for search results. this can be potentially be catastrophic if sensitive information is stored in these files.

[vlcinsky]

Tagging this issue "enhancement" sounds funny. It shall be "security".

Regardless of any explanation of design reasons, it is still a problem.

If the solution works the same way, clear warning to users, that any link from wiki page to attachment is not secured and must not be shared with other parties as they are publicly accessible is really necessary.

Think of:

• adding FAQ entry explaining the facts
• adding link to such entry whenever user can attach a file to a wiki page. E.g. at the wiki is "Drop attachments here!" could get additional text "shared by link" leading to given answer.

Leaving such sensitive issue unattended for so long time brings a question, what more (security related) surprises we can expect in Taiga.

[diacritica]

fixed in earlier releases