A way to protect inline images delivered to authenticated users?
Within the app, my users can create documents with inline images / files / text, etc. Viewing and editing this content requires the user to log in. Currently, images and files are passed as permalinks, so if those links are available to any unauthenticated user, forever access them.
I would like to make these files safe. My initial thought was to use a login token and user id to check if they have access, and only deliver files if they do. But then I started working on it, and it seems that the most practical solution would be to create a link that will expire at some point in the future. This does not eliminate the exposure to unauthorized access, but it may reduce it.
The questions that come to mind are the following:
-
Is there a general approach or multiple options for how this should be implemented?
- I have seen urls returning with used expiration dates
- The google docs seem to do something a little more complicated for inline images, but I can't tell you that
- Others?
-
Key design points?
- The pros / cons of each?
source to share
Yes, it reduces authenticated access to a fixed time, but in theory it provides unauthenticated access. Therefore, the security specialist will declare that he has no authentication. This tick expiration time synchronization is usually used to protect against one-time access without authentication, such as password reset (along with a time-independent expiring token).
What is your goal? Who are you trying to protect your data from? Are users who already have access to the files and want to limit the expiration time? From this question, you need to provide access to files / documents that have text and inline images. You are correct about the expiration dates. It doesn't guarantee the authentication and integrity of the document, and if it sits on top of insecure HTTP, it won't even give you document integrity from a potential adversary.
you can use cookies (secure cookies) over HTTPS. As long as the user has an expired cookie, allow access to files / documents. The cookie approach requires distributed cookie management if you want to host the solution in multiple boxes with a reverse proxy in front. Although cross-site scripting is a threat, most major web application providers use cookie-based solutions. Please note: cookies violate the REST nature of the web application.
Another approach (similar to a cookie) is to create authenticated tokens tied to a user / documents that has access to N number of attempts in a given period of time while generating the token. This method should be used over HTTPS to avoid unwanted listeners.
An always changing link is very expensive to manage and does not scale over time, because too much state to manage and crash the application makes it even more costly. Re-redirecting to authenticate is a safe bet for you if you already have cookie management or have one instance of the app to take care of.
Or you can authenticate the HTTP digest , assuming your infrastructure supports it, so you don't have to worry about cookie-hell. Please note that you may need to write multiple client-side java script based on your usage.
source to share