Advertisement:
Anonymous Login
11-24-2017 07:03 PM

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000863SMF 3.0 "Saguaro"public2014-01-22 12:47
Reportervbgamer45 
PrioritynoneSeveritytweakReproducibilityalways
StatusresolvedResolutionfixed 
Summary0000863: Uploaded Avatars to specific directory by default
DescriptionUploaded Avatars to specific directory by default

Instead of going to though the index page
http://www.yoursite.com/index.php?action=dlattach;attach=1;type=avatar

Helps speed up the forum and uses lesses resouces.

From Ben_S
http://www.simplemachines.org/community/index.php?topic=109552.0
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

bugnote:0012920

Mark Rose (Beta Tester)

Last edited: 2010-09-09 19:22

View 2 revisions

Considering this is the #1 thing that can be done to speed up SMF, I strongly suggest this should be done for 2.0. It's a trivial change, too. All it involves is another directory created in the installation and a setting.

When I did some analysis a while back, I found enabling this saved 75 PERCENT CPU usage. For the work involved, it's totally worth doing.

bugnote:0012925

Mark Rose (Beta Tester)

http://www.simplemachines.org/community/index.php?topic=197938.0

bugnote:0012927

Brett Flannigan (Viewer)

Agreed. I see no good reason uploaded avatars should be passed through PHP by default, particularly with the number of them which may be loaded with every topic view. It makes sense for regular uploaded images to track views or whatever, but not avatars.

bugnote:0012956

Norv (SMF Friend)

Well, if we do that by default, then the hashing of filenames, as it is done currently by default (post SMF 1.1.9/RC1-1), with practically the effect of making the filenames impossible to guess, doesn't happen anymore, obviously. It was done to introduce a little new layer of protection against a malicious avatar/attachment.

bugnote:0013011

IncognitoMuse (Viewer)

The whole point of the change was, indeed, against a malicious avatar; the idea being that you could upload a malicious PHP or similar file and if you know its location, execute it.

Avatars are not those, however. They are image files, pure and simple. If it's not an image file, prevent it from being uploaded, simple as that.

Btw, it isn't actually possible to disable filename hashing from the admin UI after those versions (though you could theoretically do so via the settings table directly).

Question: if it was that much of an issue for security, why wouldn't this forum do it the same way?

Question: what security benefits do you actually get serving what you should *know* to be an image through an obfuscation layer? There are, of course, benefits to serving a potentially non-image file through such (to minimise/prevent server execution) but I can't see any you would gain from applying the same to image files being served as images.

bugnote:0013013

Norv (SMF Friend)

>> Avatars are not those, however. They are image files, pure and simple. If it's not an image file, prevent it from being uploaded, simple as that.

That's not true, unfortunately. Valid image files can have malicious code inserted.

>> Btw, it isn't actually possible to disable filename hashing from the admin UI after those versions (though you could theoretically do so via the settings table directly).

Can you please tell what setting you refer to?

bugnote:0013014

Norv (SMF Friend)

Last edited: 2010-09-18 16:54

View 3 revisions

>> Question: if it was that much of an issue for security, why wouldn't this forum do it the same way?

It isn't much of an issue for security.
It is IMHO, however, a stronger setting, than the opposite. None is a problem though, otherwise it wouldn't be even a setting in SMF.
The issue here is not that any setting is a security problem, because NONE is. BOTH are fine.
It's whether a little extra-layer of protection should be the default setting or not.

>> Question: what security benefits do you actually get serving what you should *know* to be an image through an obfuscation layer? There are, of course, benefits to serving a potentially non-image file through such (to minimise/prevent server execution) but I can't see any you would gain from applying the same to image files being served as images.
You don't necessarily know. They are not necessarily image files being served as images.

bugnote:0013020

Norv (SMF Friend)

On the other hand, I wonder what exactly takes that much processing power, in the current implementation of avatars retrieving. We already gave up theme loading during avatars loading, as I remember.

bugnote:0013021

Brett Flannigan (Viewer)

Well, consider this. Let's assume we have a topic page with a default of 15 posts, each by a different user, and every user has uploaded an avatar. With the default uploaded avatar handling, that's 15 more instances of PHP which have to be loaded to handle displaying all of the avatar images for that single page. Ouch.

You do have a point that the current default handling is slightly more secure, to prevent fake images with PHP content from being executed on server setups which are vulnerable to such an attack. It's just a matter of weighing that against the major performance hit which it can cause.

bugnote:0013022

Norv (SMF Friend)

Ah well. I was thinking that (perhaps) making the current implementation even lighter could have some benefit that would matter.

bugnote:0013024

Mark Rose (Beta Tester)

Yeah, the killer isn't so much the SMF PHP scripts, but the compiling and parallel execution of said scripts, especially when not running an opcode cache. The recent changes have made loading an attachment about twice as fast. But with a brain dead web server like Apache that spawns a new thread/process for every request, not having a custom avatar directory multiplies the number of threads/processes required to serve SMF.

bugnote:0014933

arrowtotheknee (SMF Friend)

2.1 does this by default now
+Notes
MantisBT (Modified for SMF Intergration)[^] Copyright © 2000 - 2010 Mantis Group