Symphony.

Within the next two weeks I'll be throwing another Symphony site live and I'm looking deeper into security this time around.

So I'm wondering if anyone has any tips or tricks to help keep my sites safe from hackers and spammers. I'm really interesting in hearing what people use for file permissions and if they do something specific for each section, such as extensions and so forth.

Also, what steps do you take to make sure your website doesn't get hijacked or your comments sections flooded with spam.

All tips and tricks would be great! I figure we could also turn this thread in to a bit of a repository for new users.

This is a great idea, dougoftheabici. When there is a more structured repository for documentation this would be a good sub-section.

A few things thoughts:

• make sure your /symphony/ username and passwords are strong (mixed-case and alpha-numeric)
• don't use the "remote log in" from a URL functionality, which is a point of weakness
• upgrade to the JIT Image Manipulation field for thumbnailing (replaced in Symphony 2.0.2). It provides a whitelist in the System > Preferences to prevent the thumbnailing script being used to load external images
• add spam filters to comment forms
• use a 404 page to gracefully catch 404 errors
• use the "redirect to 404" option of Data Sources to ensure pages are viewed as intended (and aren't displayed with blank data on them if URL params are manually changed)
• watch your query count and page load times on every page (through the Profile debugger). If any pages are slow or run many queries they are potential vulnerabilities if targeted (repeat refreshes and heavy load would put highest strain on your server)
• if you use events to update entries (passing "id" as a hidden form field) be aware that a user can simply change this value and submit, updating another entry

Regarding passing entry ids in event form submissions; I generally do some manual POST array manipulation in the event.*.php file to make sure the 'id' field isn't present.

Make sure when you're installing to set the file permissions to 0644 (or 0664 if you need group write). There is nothing you're uploading to a Symphony install that should require execute bits to be set (0755/0775).

Actually, after all the hoo-ha about the hacks late last year, why does the default installer still try to set the execute bit on files? Baaaaad...

@tonyarnold: On my webspaces the execute bit must be set in order to access files via FTP(S).

@tonyarnold: Some of my webspaces require the execute bit to be set to edit files through the Symphony administration panel. Furthermore, I have to set the execute bit at the cache directory to use the image cropping functions.

So what would the recommended file permissions be for each section?

@michael-e and @carsten - what host requires that? SFTP should be the only way you're accessing things these days (FTP is dead - let it die), and requiring an execute bit for file access just sounds backward.

@tonyarnold: On standard hosting accounts you won't find SFTP (nor SSH), but maybe FTPS. The latter is what I use normally.

There have been discussions about file permissions in the past, like this one. According to Scott's explanation in this thread, permissions are not the only security concern, nor the biggest. (He also mentions FTP not being secure, and I totally agree with that. I wouldn't choose a host nowadays who does not offer FTPS or SFTP.)

Of course a good solution could be to have PHP running in the same group (or even as the same user?) as FTP -- something like "www-data". In this case you could try and set permissions more restrictive. But I have never found this construction on shared hosting accounts.

if you use events to update entries (passing “id” as a hidden form field) be aware that a user can simply change this value and submit, updating another entry

is this something that might get changed soon?

Most likely not. Maybe in Symphony 3, but it would require fundamental changes to the way events work and “get” variables. How would you anticipate this working without sending the ID itself in the POST?

i’m not sure, but it’s something i will be rolling around the next few days. thankfully, most of the sites i work on are pretty low-risk, but many of them do use some kind of front end entry modification, typically a ‘change password’ page. they are mostly sites where i’ve integrated my fork of front end authentication.

my brain is pretty cooked after a long day, but at the moment i can’t think of any uses for entry updating through events where the lack of security would be something that could be overlooked.

i’m going to think on it. if i can come up with anything that might help, even if it’s something as simple and hacky as ‘throw this line into all of your events’, i’ll be sure and share it.

if you use events to update entries (passing “id” as a hidden form field) be aware that a user can simply change this value and submit, updating another entry

Is this really an issue? Hopefully there’s a server-side authorization check anyways so nobody can update entries from another user.

Or am I getting things totally wrong here?

By default there’s no concept of “user”. If you’re using user management then you’ll want this, yes. The forthcoming Members extension should solve this problem.

Maybe in Symphony 3

Yes, Symphony 3’s events allow you to specify overrides for any user-submitted fields.

By default there’s no concept of “user”. […] The forthcoming Members extension should solve this problem.

So the real security issue at the moment are insecure extensions, right?

How is this forum working then? I manually changed the id of my own comment while editing and it changed that comment, but would this also work if I knew (or guessed) the id of one of your comments?

Have a updated checklist about security improvements?
Something like move core folders out of the public dir, like some frameworks. It's possible? Necessary?
A list of chmod for main folders?

Thanks.