Full Read Server-Side Request Forgery (SSRF) in kareadita/kavita
Aug 6th 2022
/api/upload/upload-by-url endpoint is possible to upload an image via an URL provided by the user. The function that handles this upload, doesn't verify or validate the provided URL, allowing to fetch internal services.
Furthermore, after the resource is fetched, there is no MIME type validation, which would ensure that the resource is indeed an image. Then, the file is saved to a temporary directory, that can be retrieved via the
/api/image/cover-upload API endpoint.
Finally, an attacker can manipulate the extension of the saved file, by adding the the hash sign
# to the end of the URL and then an extension of its choice, for example
.png .This in important because it doesn't modify the internal fetched resource, but allows to save the response to a valid file, that can be successfully retrieved via the
Proof of Concept
For testing purposes, I started an internal-only HTTP server, listening at port
8000, along side the application.
1 - Login in the application.
2 - Send the following request, where the
url attribute is the target resource, in this case will be the HTTP server at port
3 - Visit the
/api/image/cover-upload?filename=<filename> URL, where the
filename contains the above response filename.
An attacker can get sensitive information of any internal-only services running. For example, if the application is hosted on Amazon Web Services (AWS) plataform, its possible to fetch the AWS API endpoint,
https://169.254.169.254, which returns API keys and other sensitive metadata.