Issue F. Tip Files Can Be Downloaded Without Authenticating #826

fpietrosanti opened this Issue Mar 3, 2014 · 6 comments


None yet

3 participants


Synopsis: GlobaLeaks does not check if the user is authenticated when downloading files. The files are
protected only with a string generated by uuid4(), which might be predictable (see Issue K: Secrets
Generated with Non-CSPRNG), or vulnerable to side-channel attacks (see Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks).
Impact: An attacker can access the files associated with a Tip.

@fpietrosanti fpietrosanti added this to the LeastAuthorityPentest milestone Mar 3, 2014
@evilaliv3 evilaliv3 changed the title from Issue F. Confidential to Issue F. Tip Files Can Be Downloaded Without Authenticating Apr 16, 2014

@defuse : globaleaks/GLBackend-outdated@8069794

with this commit we removed entirely the concept of the download token and we implemented simply a POST authentication.

as you can see at line 501 of that commit, the post authentication works exactly as the HEADER based authentication already audited, but instead of handling X-Session header we handle x-session POST variable.

can this ticket be considered closed?

defuse commented Apr 16, 2014


It looks like the code is checking that the one sending the POST request is logged in as a receiver, which is an improvement, but I don't see it check anywhere that they are the correct receiver. In other words, it looks like a receiver who is not supposed to have access to the tip can download the files as long as they know the file id.

Is that the case, or did I overlook an authentication check somewhere?


allright ok i'm going to add also this check :)


@defuse: here you are

now a strict auth validation is done so that the download for single files or file collection is granted only to the precise logged user and nor a whatever user logged and apart of the link.


defuse commented Apr 17, 2014

@evilaliv3 I think there is a problem with the download_file() one:

From the POST request, the user provides the tip_id and rfile_id variables. Inside download_file() these become tip_id and file_id. Now, there's an access check with access_tip() on the user_id and tip_id, which ensures that the user has access to the Tip. However, it is not checked that the file_id file is actually part of that Tip -- they could give the file_id from a file in a different Tip and it would still download.

So there needs to be an additional check to make sure the file_id is actually a file for that tip_id.


yep, right comment.

applied the fix suggested:

@evilaliv3 evilaliv3 closed this Apr 20, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment