mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-07 11:19:38 +03:00
Security Issues with Attachments #5203
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @samysilva on GitHub (Feb 28, 2025).
Describe the feature you'd like
Security Issues with Attachments
I use the function (Enable higher security image uploads) so that the names of the images are random, which I really like.
This way the images are stored inside the folders with random strings.
https://my-public-bookstack.com/uploads/images/gallery/2025-02/4keCDo6cC8bFKCgc-image.png
Attachments
Any malicious user can download all attached files by simply entering a number after /attachments
For example:
https://my-public-bookstack.com/attachments/1
https://my-public-bookstack.com/attachments/2
https://my-public-bookstack.com/attachments/3
https://my-public-bookstack.com/attachments/N
Suggestion
Currently, attachments are already saved with random names on disk.
ls -la /var/www/bookstack/storage/uploads/files/2025-02-Feb
-rw-r--r-- 1 www-data www-data 1006323 Feb 28 20:20 4Oh2irB9HfJNg3Np-zip
-rw-r--r-- 1 www-data www-data 822 Feb 28 20:20 kN6ufsdslHEH9Iyv-csv
-rw-r--r-- 1 www-data www-data 220801 Feb 28 20:20 uCNy77Gjo4GXDKOW-zip
It would be possible to change the links to access attachments to a more secure format?
If we use the ID of the stored files themselves, this would solve all security problems.
For example:
https://my-publicbook-stack.com/attachments/4Oh2irB9HfJNg3Np-zip
https://my-publicbook-stack.com/attachments/kN6ufsdslHEH9Iyv-csv
https://my-publicbook-stack.com/attachments/uCNy77Gjo4GXDKOW-zip
Describe the benefits this would bring to existing BookStack users
Protect attached files
Can the goal of this request already be achieved via other means?
No
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
3 months to 1 year
Additional context
No response
@ssddanbrown commented on GitHub (Mar 1, 2025):
Hi @samysilva,
Unlike images (by default), Attachment downloads/links are served via the application which will perform an access permission check on the attachment file (based upon the page it's attached to) before providing the attachment in response.
Therefore, users should only be able to download attachments that they already have access to.
@samysilva commented on GitHub (Mar 1, 2025):
Hi Dan,
Our platform is public, but we don't want to leave it open for anyone to try to download files by number.
We have a Web Application Filter in front of the servers. We identified 3 bots constantly accessing the URI of the attachments, which discover new files by their sequential number and download them.
The bots don't do the same with the images, because the images have URIs with randomized names.
This direct access to the attachments without knowing the file names leaves the platform vulnerable, Dan. Is it possible to consider implementing access to the attachments without using the sequential number?
If it is possible to make the links available through the names of the files saved on the disk, it would solve the problem.
From: Dan Brown @.>
Sent: Friday, February 28, 2025 19:16
To: BookStackApp/BookStack @.>
Cc: samysilva @.>; Mention @.>
Subject: Re: [BookStackApp/BookStack] Security Issues with Attachments (Issue #5512)
Hi @samysilvahttps://github.com/samysilva,
Unlike images (by default), Attachment downloads/links are served via the application which will perform an access permission check on the attachment file (based upon the page it's attached to) before providing the attachment in response.
Therefore, users should only be able to download attachments that they already have access to.
—
Reply to this email directly, view it on GitHubhttps://github.com/BookStackApp/BookStack/issues/5512#issuecomment-2691637897, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEXPEKAMIEJ4DSG2ZKTZ7D2SDN2ZAVCNFSM6AAAAABYDESYX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJRGYZTOOBZG4.
You are receiving this because you were mentioned.Message ID: @.***>
[ssddanbrown]ssddanbrown left a comment (BookStackApp/BookStack#5512)https://github.com/BookStackApp/BookStack/issues/5512#issuecomment-2691637897
Hi @samysilvahttps://github.com/samysilva,
Unlike images (by default), Attachment downloads/links are served via the application which will perform an access permission check on the attachment file (based upon the page it's attached to) before providing the attachment in response.
Therefore, users should only be able to download attachments that they already have access to.
—
Reply to this email directly, view it on GitHubhttps://github.com/BookStackApp/BookStack/issues/5512#issuecomment-2691637897, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEXPEKAMIEJ4DSG2ZKTZ7D2SDN2ZAVCNFSM6AAAAABYDESYX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJRGYZTOOBZG4.
You are receiving this because you were mentioned.Message ID: @.***>
@ssddanbrown commented on GitHub (Mar 1, 2025):
I don't really understand why it would be considered vulnerable if that content is already public, and I don't see just a name scheme change affecting anything in regards to security other than a thin layer of extra obscurity.
Even if attachments were referenced by name, I could still download your whole public instance, with attachments, via a single wget command.
@samysilva commented on GitHub (Mar 1, 2025):
The way access is provided leaves the platform vulnerable to DDoS.
A simple batch with a loop can download all attachments from the platform. If you have enough files attached to the platform, it is possible to make it unavailable with a simple batch by curling the attachment URL.
With 3 batches we can make the server unavailable. Example of a university that recently had its website taken down because of this issue. Unfortunately, they are deleting all attachments so that new attackers cannot easily gain access.
$ curl -I https://manuais.ouropreto.ifmg.edu.br/attachments/3 2>/dev/null | grep attachment
Content-Disposition: attachment; filename="img_zoiper5622.png"
$ curl https://manuais.ouropreto.ifmg.edu.br/attachments/3 -o img_zoiper5622.png
At the university, we have a large amount of attached material, unfortunately we need to delete everything so that our website remains online.
These materials are for public use, to benefit the development of students.
The WAF platform in front cannot distinguish between a normal user and a bot, because the data streaming pipeline is not analyzed.
This is generally the case.
We would really like to remove this direct access and leave access to the files nominal. This way, the attacker no longer has direct access, as he needs to access the page to read the content.
In this case, we can identify the number of accesses and block them.
@ssddanbrown commented on GitHub (Mar 1, 2025):
But even if named, the same level of DDOS is achievable, either through just focusing on one attachment or via scanning across the instance to find many attachments.
Can't you just rate-limit across attachment URLs? Seems like a more direct approach to the core concern.
@samysilva commented on GitHub (Mar 1, 2025):
Not really.
The images are served directly by Apache. If they were numbered, we wouldn't have any problems, because Apache does this part well.
Attachments, on the other hand, are delivered via streaming by PHP, which consumes much more resources. And we have to mitigate this.
We use VMware Advanced Load Balancer with WAF. The platform can identify DDoS attempts by analyzing the behavior of accesses. URLs accessed, etc., but it cannot analyze binary streaming; it would be necessary to do a main-in-the-middle with SSL-Offloading.
We have an open ticket at Broadcom about this, the engineering explained that the WAF's L7 does not handle direct traffic, when it is a download.
It can very efficiently block users trying to scan the platform, but when the access is to binary/streaming, this traffic is bypassed.
Masked URLs would solve the problem, because the malicious user would not be able to start streaming. If they try to access the URL and it returns a not-found, the WAF will identify it,
Since almost every get that is made results in streaming, this results in high memory consumption and generates unavailability.
Masking will also help companies that don't have the resources or WAF, Dan.
We recently ran parallel tests on some sites that use BookStack, I won't post the full code because we don't want to encourage people to attack the sites.
But as a demonstration, if you run something similar to the one below with parallelism, you'll be able to get the DDoS.
Many of the requests will result in 404, but some will get large files once identified. Just repeat and exhaust the apache/php memory.
for att in $(seq 1 10000); do curl https://bookstack.clarkson.edu/attachments/$att -o $i-$att.dat; done