Hello all,
I have a question regarding the security of my new web zine. The
idea is that I have editors that can log into the site, and then upload
comics in the form of a jpg. The way that I have this set up right now
is that the jpg is submitted through a form and then placed into the
authors sub directory in public/comics/. The record of the jpg is
stored in a pendingcomics table in the database. The administrator has
to come in and authorize the comic, which moves the record from the
pendingcomics table over to the public_comics table so that it can be
viewed by the rest of the world.
Now the problem. Is this secure enough? What if one of my editors
forgets to log out and someone hi-jacks the account and posts a ton of
pron. Now its true that these are not immediately available to the
public, however, if someone knows the name of the files that were
uploaded, can they be retreived directly from the public/comics/id/
directory?
One possible solution I thought of was to rename the file uploaded
with random jibberish, and simply hide the image from the author untill
it is authorized. Please give your thoughts on this.
Thanks for any help.
--
Posted via http://www.ruby-forum.com/.
On 5/11/06, Dorian Lance <loridand@netscape.net> wrote:> Hello all, > > I have a question regarding the security of my new web zine. The > idea is that I have editors that can log into the site, and then upload > comics in the form of a jpg. The way that I have this set up right now > is that the jpg is submitted through a form and then placed into the > authors sub directory in public/comics/. The record of the jpg is > stored in a pendingcomics table in the database. The administrator has > to come in and authorize the comic, which moves the record from the > pendingcomics table over to the public_comics table so that it can be > viewed by the rest of the world. > Now the problem. Is this secure enough? What if one of my editors > forgets to log out and someone hi-jacks the account and posts a ton of > pron. Now its true that these are not immediately available to the > public, however, if someone knows the name of the files that were > uploaded, can they be retreived directly from the public/comics/id/ > directory? > One possible solution I thought of was to rename the file uploaded > with random jibberish, and simply hide the image from the author untill > it is authorized. Please give your thoughts on this. > > Thanks for any help.Just a thought, but couldn''t you store them outside /public/ until approved? If you are moving them anyway, do you have any perticular reason to store them under /public/? Cheers, Mathias.
Mathias Wittlock wrote:> On 5/11/06, Dorian Lance <loridand@netscape.net> wrote: >> viewed by the rest of the world. >> Thanks for any help. > Just a thought, but couldn''t you store them outside /public/ until > approved? If you are moving them anyway, do you have any perticular > reason to store them under /public/? > > Cheers, > Mathias.I thought about that, but then the editor cannot view his pending images through the web interface. Do you know a way around this? Maybe another folder with a different set of rights so that they can post into it but somehow not download? But then they cant view the images still right? Thanks, Dorian -- Posted via http://www.ruby-forum.com/.
>>>>> "Dorian" == Dorian Lance <loridand@netscape.net> writes:> I thought about that, but then the editor cannot view his pending images > through the web interface. Do you know a way around this?A plain ordinary controller that sets the right content-type and uses send_file. Not the most efficient way to send static content (since it passes through Rails), but I guess you''re not going to have that many editors looking at the same picture. -- Calle Dybedahl <calle@cyberpomo.com> http://www.livejournal.com/users/cdybedahl/ "Facts are for people with weak opinions." -- Lars Willf?r, I]M
> > however, if someone knows the name of the files that were > uploaded, can they be retreived directly from the public/comics/id/ > directory?Yes. The solution of "random gibberish" is the same one that Flickr uses for all of its photos. However, if you know the direct URL to a photo that is deemed "private" you can still see it. Because, in the end, it is still a file on a server. Your obfascuation of the URL would simply be there to prevent the person from remembering it. But, if they got a hold of it, it wouldn''t matter what your authentication system did to try to stop them. If you are really worred, stress the importance of the security on your site. Make the users accountable for what happens to their accounts. If you are super worried, setup an aduit trail for all actions that you deem worthy of tracking. But, one thing that you have going for you is this moderation process. As long as a user can''t moderate their own entries, you''ll be in better shape in that regard since you can filter this bad stuff out. However, it really comes down to people doing stupid stuff on your sustem... and that''s what you''re trying to prevent. Best, Ryan On 5/11/06, Calle Dybedahl <rails@cyberpomo.com> wrote:> > >>>>> "Dorian" == Dorian Lance <loridand@netscape.net> writes: > > > I thought about that, but then the editor cannot view his pending images > > through the web interface. Do you know a way around this? > > A plain ordinary controller that sets the right content-type and uses > send_file. Not the most efficient way to send static content (since it > passes through Rails), but I guess you''re not going to have that many > editors looking at the same picture. > -- > Calle Dybedahl <calle@cyberpomo.com> > http://www.livejournal.com/users/cdybedahl/ > "Facts are for people with weak opinions." -- Lars Willf?r, I]M > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ryan Prins rprins@gmail.com http://www.lazyi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060512/c73f4f61/attachment.html