Security concern

Started by arewetoast?, August 22, 2007, 01:57:44 PM

Previous topic - Next topic

arewetoast?

While I certainly appreciate the value of user profiles being visible within a forum I was dismayed to find that the individual user:  profile summary, last posts, and  "general statistics" are wide-open to the public.  Horizontally, a simple Google query on "username" "profile" and "smf", will provide links to  every smf board upon which an individual has registered.  Vertically, altering the numeric user ID value in the url string www.simplemachines.org/community/index.php?action=profile;u=64 will vacuum up the user information of each of your ~ 117K registered users.  Obviously this works on all SMF boards.  The user information obtained by such measures could be invaluable to data miners, profilers, spammers and others.

I feel that users have a reasonable expectation that board administrators will protect such information, and that we as administrators have the responsibility to our users to do so.  I also feel that if this security defect were known, it would/should prevent deployment of smf in a number of environments.

I will appreciate your consideration of this matter.

Grudge

All the administrator needs to do is remove the permission for guests to view profiles to stop this from occuring.

Admin -> Manage Permissions -> Guests -> View Profiles (Disable)
I'm only a half geek really...

arewetoast?

Thank you for your prompt reply! In my view there is a vast difference between permissions for individual users and site visitors, vs. having user profiles and activity statistics wide open to automated scanning.  While I can not see it, I will concede that some may see value in allowing unregistered guest to access registered user profiles,  but I cannot  think of any justification for providing such access to data miners, search engines and other bots.  People  tend to be very conservative in their user names (and unfortunately passwords), making it a easy and lucrative task to assemble a profile.  I do believe that it is a responsibility of a system administrator to make a reasonable effort to protect user data from such misuse.

I would suggest that you consider changing the default guest permission to "disabled", and strengthen the "help" information to more fully explain this full extent of this permission. 



elfishtroll

Quote from: arewetoast? on August 23, 2007, 08:41:07 PM
Thank you for your prompt reply! In my view there is a vast difference between permissions for individual users and site visitors, vs. having user profiles and activity statistics wide open to automated scanning.  While I can not see it, I will concede that some may see value in allowing unregistered guest to access registered user profiles,  but I cannot  think of any justification for providing such access to data miners, search engines and other bots.  People  tend to be very conservative in their user names (and unfortunately passwords), making it a easy and lucrative task to assemble a profile.  I do believe that it is a responsibility of a system administrator to make a reasonable effort to protect user data from such misuse.

I would suggest that you consider changing the default guest permission to "disabled", and strengthen the "help" information to more fully explain this full extent of this permission. 




I AGREE!

This is perhaps a big security area where SMF has been lacking, in so far as even recognizing that the exposure exists, i.e. You have a forum and it has no obvious security holes, but still allows your members to be violated.

This goes into the Operational issues of running a board, rather than performance/simple implementation so perhaps that is why this has been overlooked.

On the flip side, a public profile by default may well be a boon for those social networking/relationship/self promotion  sites. There members may WANT to have as much exposure as possible, especially if their profile carries links to their own site.

A restructuring of the Profile and Admin menu to have an explicit PRIVACY TAB may be the right step.

Thank you for your most provocative input!
-regards

karlbenson

For these sorts of things I always post the internet mantra
"Don't post anything on the internet you don't want EVERYONE to see".

There should never be a complete expectation of privacy (and/or security).
Never use real D.O.B's, or mothers maiden names etc. (only post your address when its absolutely needed eg amazon.com).
And of course always check the private email setting.
(all that information CAN be used for identity theft including obtaining birth certificates, passports, driving licences, bank loans)

For 99% of forums there is no reason to protect profiles.  You can't just decide to allow some guests and disallow data miners. (because they don't always identify themselves).  Its not 100% effective.

elfishtroll

I agree, but as the internet becomes more accessible (remember when you had to manually determine and configure PPP and DNS settings just to connect with dial up?) more and more relative neophytes are accessing the internet and even more -SETTING UP WEB COMMUNITIES.

With point and click installation, you dont even have to think about ANYTHING to have a working website and forum.

I believe that more attention to some of the aforementioned issues should be in order. While there is no panacea, we cant throw our hands up in the air and say its a user responsibility..

If you have a can opener that, when improperly used, causes 'finger loss' then we need to revisit the design.

I think software (and designers) have to take the lead.

Based on arewetoast's comments, I have modified my sign up pages to inform users that they may have no privacy if they make public their email addresses or profiles and have given them the ability to turn it off when desired or make them available only to those on their buddy lists.

I have also made it possible for some tracking information to be withheld as well.


I think RUNNING a forum is seriously the area where SMF will need to direct /focus its development efforts.

The code is fine from a structural standpoint, but internally/architecturally, there are some deficiencies that make it harder for an admin to properly RUN the forum and maintain a community.

I note that even in the current version,IT IS STILL POSSIBLE TO SPOOF THE IP ADDRESS THAT THE SOFTWARE WILL RECORD ON EACH POST, AND THAT SMF IMPROPERLY OVERWRITES THE GLOBAL VARIABLE SERVER['REMOTE_ADDR'] LEADING TO DATA INVALIDITY IN OTHER ROUTINES.

Granted, you would need to have a particularly determined pest who would look up the code to do that, but it is surprisingly easy to do, and causes a LOT of problems in your log files.

I think that SMF probably should have more people that actually RUN forums (as opposed to developers) working with the code/design process or at least give them more say/clout/leeway.

The issue is probably more about disclosure than anything else tho, so as long as we can make it very clear to our forum community, they should be fine.

karlbenson

Quotenote that even in the current version,IT IS STILL POSSIBLE TO SPOOF THE IP ADDRESS THAT THE SOFTWARE WILL RECORD ON EACH POST, AND THAT SMF IMPROPERLY OVERWRITES THE GLOBAL VARIABLE SERVER['REMOTE_ADDR'] LEADING TO DATA INVALIDITY IN OTHER ROUTINES.

How would SMF resolve the issue?  Have you some code to fix it?

elfishtroll

As you may know, the ACTUAL IP ADDRESS of the connection made to your site is store id environment variable REMOTE_ADDR which the PHP runtime copies into the global server variable SERVE['remote_addr'].

No the user's browser or ISP may also send additional headers.
An internet gateway system may have people connect to it, and then IT connects to the internet at large.
These systems since they forward your connection, may forward your (original connection IP) address to the destination, adding a NEW header variable X_FORWARDED_FOR. (for example. there is not a clear standard, and some providers may use a different variable or none at all)
Indeed, the X_forwarded variable may even contain multiple comma delimited IP addresses which makes dealing with it more interesting :)

Now, since these additional variables CAN BE SENT BY THE CLIENT (which is totally untrustworthy,obviously) THEY CAN BE SPOOFED.
Furthermore, they can be loaded to contain POISONOUS DATA or XSS Scripting.

THE BIG ONGOING (for years) problem is the way handles all the different possibilities for the IP address. :(

basically what the code does is this:
QuoteI got the TRUE IP variable of the actual connection!

Is there other Information sent?

Can I resolve it to an IP address? i.e. numbers in the format 999.999.999.999?

Ok then!

I WILL OVERWRITE THE GLOBAL VARIABLE THAT OTHER CODE MAY USE WITH THIS INFO!

From then on, ALL CODE THAT LOOKS AT SERVER['remote_addr'] will have the WRONG VALUE and WILL NEVER KNOW WHY :(

This was reported  a year or so ago by some chick and as a proof of concept she actually made a post in the forum which the admins could verify was made by somebody else. (she spoofed the variable which SMF dutifully picked up to use as the correct IP)

Now, as an admin or mod, you may verify member registrations by looking up the IP!

(You will be looking up crap as the IP is spoofed)

Regardless of how SMF crazily 'derives' the IP address, it is incredibly poor practice to then OVERWRITE a global variable with rubbish.

Now the 'fix' was to store two IP addresses IP1 and IP2 but that is very poor and obviously not even a fix at all.

This problem, and the non-fix applied to it highlight the problems when you have Programmers who write Forum software but do not themselves run a Forum. The forum system is dependent on trust, not just code functionality.


The real fix is to NOT abuse a global variable ( Remote_addr) and store ALL the other  IP metadata sent by the browser: For example, sent as well could be HTTP_CLIENT, HTTP_CLIENT_IP, HTTP_VIA_IP and all manner of combos.


My solution to the user authentication problem is to discard all the other IP's and just use REMOTE_ADDR since I would block at the .HTACCESS level not the SMF level.

Grudge

As of 1.1.1 (I think) SMF does not overwrite REMOTE_ADDR unless the value is invalid to begin with.

Clearly as a developer I do operate a forum as I operate this very community here.

The original reason why REMOTE_ADDR was overwritten was actually to help forum admins not hinder. REMOTE_ADDR is often not the end users IP if they are behind a proxy (For example at a University) and hence banning against this could result in banning more than just the user. Instead SMF used considerable logic to work out what the most likely IP address was to make banning more efficient.

The old way only failed due to people being able to spoof their IP (Something we clearly had not catered for although I still argue that if someone is determined enough to do this they should ban at server level). Hence the decision was made to make the REMOTE_ADDR (Not always correct but at least unspoofable - hence secure) the "logged" IP and also calculate the most likely actual IP and store this as well to further improve security.

I'm sorry if you don't agree with the idea of overwriting server variables but we do this in SMF as it is our first security measure - all variables coming into the script get ripped apart and put back together with the relevant slashing (etc) to reduce the liklihood of injections and the like (You need to remember to unprotect a variable if you don't want to insert it into the database rather than the other way around). Remember that SMF is only a script not a whole operating system so what it does on an execution doesn't affect anything else on the server. What SMF does is well documented and visible so whenever bridges (etc) are created they simply need to reverse what SMF does coming out of the script if it doesn't fit what they want done with the variables.

We've never hit any problems doing things the way we do them for the last four years (The general idea of overwriting $_GET, $_SERVER etc) and in fact if you look at the security statistics for SMF it seems to have stood us in good stead.

Note clearly this has gone miles off-topic. In response to the original posters statement it is something I shall look into.
I'm only a half geek really...

johncoths

I guess just take it off the guests permission to view others profile to stop occurring things like that. Set some limitation for viewers about those private information.

:)

Aleksi "Lex" Kilpinen

Quote from: johncoths on October 20, 2009, 12:11:46 PM
I guess just take it off the guests permission to view others profile to stop occurring things like that. Set some limitation for viewers about those private information.

:)
Unless you really have something to add, please avoid bumping old topics like this.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Advertisement: