in reply to (OT) Perk script help

I would guess (and that is all that it is) that the web server is running as a user ID that does not have permissions to write to wherever the cgi script wants to write.

That being said, if the application cannot be configured to write to a location outside of the HTMLROOT, run, don't walk, away from the application and find something else that meets your needs.

The web server, as a 'best practice' (take that as you will), should never be allowed to write to any location directly accessible from web-space (in your HTMLROOT). Allowing the web server to write to an area directly [update: perhaps this should be "publically"] available via web-space likely allows for hijacking of your web server and other security or reputation related attacks.

Note that denying this avenue of attack does not make your server 'secure', it just removes one avenue of attack.

--MidLifeXis

Replies are listed 'Best First'.
Re^2: (OT) Perk script help
by Anonymous Monk on Nov 12, 2014 at 01:55 UTC

    ... Allowing the web server to write to an area directly available via web-space likely allows for hijacking of your web server and other security or reputation related attacks. ...

    And if the whole purpose is to allow uploads what then? Or update a database?

    There are such things as permissions, neither uploads nor a database need to be an attack vector

      The key part of that phrase is "directly available via web-space". Unsanitized uploads into your web space are a problem. Period. Whether that sanitization comes from an application taking out the nasty bits, requiring a human to vet them, or trusted users being the only people with access to the upload, they need to be sanitized.

      Let's take one simple application of your example: an open upload server that accepts image files and presents them directly to web space. Let's suppose that $anonymous_user finds this service. Let's also say that this $anonymous_user has a taste for images outside of the social norm, and even outside of legal boundaries. Let's now say that $anonymous_user uploads some of these images so that they can be shared with other users with the same tastes. The server owner is now in a position of helping to distribute these images. Lucky guy.

      You are correct when you say that neither uploads or databases need to be an attack vector. Making them directly accessible into public web-space, however, falls on the "is an attack vector" side of the line. Is your quibble with the missing "public" from my statement? [note: added to original]

      --MidLifeXis