You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1276: File upload interface

Kind feature request
Product wincent.dev
When Created , updated
Status open
Reporter Greg Hurrell
Tags no tags

Description

At the moment uploading new files (images, for example) to the "shared" resources directory on the server (the one that persists across Capistrano deployments) is a bit of a pain because it's a three-step process:

  1. Relax security with cap deploy:unlock (without this it's not even possible to log in to the server).
  2. Upload the files.
  3. Tighten security with cap deploy:lockdown.

It would be much nicer if I provided an admin-only web interface for uploading stuff to the "shared" resources dir. Evidently various layers of protection would be incorporated, such as requiring a valid admin login, and only allowing a very limited set of file types (PNG and the like).

Comments

  1. Greg Hurrell

    Status changed:

    • From: New
    • To: Open
  2. Greg Hurrell

    Not to be confused with ticket #1193, which is about accepting file attachments for tickets in the issue tracker (and possibly elsewhere too).

  3. Greg Hurrell

    Hmm. Although I said, "not to be confused with ticket #1193", the truth is that that ticket might actually make this one redundant.

    For example, instead of uploading to /system/images/, one could conceivably just use the attachments#new (which would be admin-only) to upload new images. Then, to link to them you could use links like [/attachments/abcd0124 see this].

    To actually embed such images rather than just linking to them might be another story though. The way the wikitext module works is upon seeing markup like {{foo.png}} it generates an img tag with src set to /system/images/foo.png. I suppose I'd have to modify it to behave specially on seeing "absolute" paths like {{/attachments/abcd0124}}. Will need to think about the security implications of doing that...

  4. Greg Hurrell

    The other issue is that such uploaded attachments would be "parent-less" and there's nothing to stop a malicious user form trying to assign them to an existing ticket. So still need to think about the security implications a little more.

  5. Greg Hurrell

    I see that {{../../attachments/abcd0124}} works, but it is ugly.

    Seeing as I effectively already allow (almost) arbitrary linking, I guess there would be no harm in implementing a special case for "absolute" paths, especially if it were an opt-in option on the parser.

  6. Greg Hurrell

    Actually, looking at the wikitext parser, I feel like it is a little too liberal in what it accepts inside image tags:

    • PRINTABLE tokens
    • ALNUM tokens
    • PATH tokens
    • SPECIAL_URI_CHARS tokens

    Most input with a slash will be tokenized as a PATH token:

    • /foo.jpg
    • a/b

    But input like this:

    • a.png

    Will be tokenized as ALNUM, SPECIAL_URI_CHARS, ALNUM.

    Input like:

    • foo

    Will just be tokenized as ALNUM.

    Not sure why I originally included PRINTABLE in the list. That will catch things like $, %, +, -, /, @, \, ^, _ and ~ whenever they're not caught by the other rules; but note that:

    • / on its own will be tokenized as PATH

    So:

    • a-b.jpg

    Will be tokenized as ALNUM, PRINTABLE, ALNUM, SPECIAL_URI_CHARS, ALNUM.

    The SPECIAL_URI_CHARS rule itself lets quite a bit of stuff through:

    • :, !, (, ), ,, ;, . and ?

    So it will accept such absurd input as {{foo:bar(really!?);baz}}.

    Not really sure how I could tighten it up without breaking existing tags (with names like foo-bar.jpg, a fairly common pattern).

  7. Greg Hurrell

    With respect to the security concerns of:

    • hijacking of "parent-less" attachments
    • uploading arbitrary "parent-less" attachments and abusing the server as a file distribution hub

    I'm thinking of having one or more simple rules:

    • normal moderation rules will apply (that is, anonymous and unverified users will have uploads held for moderation)
    • use hard-to-predict random hashes instead of predictable auto-incrementing ids (this was already mentioned on ticket #1193)
    • the user creating the attachment must be the one who assigns it to a parent (admittedly, this doesn't help much in the case of anonymous users)
    • time limit: must assign an attachment to an issue within a certain time frame otherwise not allowed; most likely will use 24 hours as the time limit, which matches the current default session lifespan (this, combined with the use of random hashes should largely deal with the problem of anonymous users trying to hijack attachments from other anonymous users)
    • only admins can create "parent-less" attachments which are accessible: in this way, an anonymous (or any other) user won't be able to hijack attachments which an admin has set up for direct access (for example product release downloads and the like)

    And finally, a measure that I don't think is necessary:

    • use an association table so that it doesn't matter how many times an attachment gets attached to something

    Basically, the system is probably secure enough even without the time-limit constraint as the obscurity defense is probably enough to stop one anonymous user from discovering an "orphaned" attachment anyway. In most cases, the upload will be shortly followed by issue submission (within seconds or minutes), so it's not like the window of opportunity for hijacking is very large anyway. Even if an "orphaned" attachment is "hijacked", what's the big deal?

Add a comment

Comments are now closed for this issue.

Menu