Symphony.

Hey guys,

I'm working the Members extension, and it's becoming apparent that DOM hacking is a problem.

For example, if I want a user to post a new message, they have a form field much like the ones on this site. In that form is a hidden field with the user's ID so that I know which user posted it. What happens if the user DOM hacks the number to something else? Well, on getsymphony.com, this happens:

http://getsymphony.com/discuss/thread/65565/10/#position-187

(also see attached screenshot, because hopefully an admin will remove those posts.) I just changed my user ID in the DOM, and Symphony goes along on it's merry way. Where it should say "Alax" it says numbers instead; though not as big of a problem as it could be, it's still a problem, and can probably be exploited further.

It could be much worse, and probably is; how do we fix this?

This is an example of the DOM hacking I'm talking about.

Please never post security issues in the forum. Contact the team instead.

Security measures for frontend publishing are not within the scope of the Members extension. This extension is built to manage member data, login, logout etc.

One solution to your issue is to build an event filter which secures/manipulates the POST data.

It's not a security issue in this case (getsymphony.com); just an annoyance. You can't cross-post here, that much is evident.

However, it is a security issue for the rest of the community who hasn't properly secured their sites, and contacting the team directly will not make anyone but them aware of this problem.

Slow down. :-) Members has not even been released officially. So there is enough time to add a warning to the README and/or provide example code.

contacting the team directly will not make anyone but them aware of this problem

That is not true. Usually they are very fast when it comes to security fixes and informing the public. (And these steps should be taken in this order.)

Okay, understood. :)

However, the only reason I posted this here is because I was under the impression that somebody probably caught this before me, and it was a non-issue. I'm fully aware of responsible disclosure, I just didn't see the point because, like I said, I assumed there was something I was missing somewhere. I'll contact the team and link them this post.

It isn't a security issue for the core/members like Michael says. Front-end security is more to do with how the developer builds the site. If you have front-end submission, it's the developer's responsibility to ensure that all submissions are checked for XSS (with the XSS filter) and that any ID's are correct and pointing to the right places with Symphony events.

There should be documentation to state this, with best practices, which myself and the other members of the documentation working group will be working on when it turns up on the schedule. We have a lot to get through, and a very small team at present.

If you have any suggestions for documentation, then please feel free to add them to this thread, don't worry if it is already on there and you haven't spotted it.

There are also a few threads on the forum relating to securing front-end submissions. I'm sure you can have a look for them...

As for this site, there is a project under way to update it with more features and security, although it is already very secure ;o)

First, a couple points of clarification:

• The members extension that runs this website and the official members extension to be released as a final build June 1st are different extensions. The one that is used by this website is almost two years old.
• Both members extensions do not provide native DOM hacking prevention and as John and Michael has mentioned, the current best practise is to modify your event scripts to ensure correct and legitimate POST are enforced.

Brendan has written a tutorial on events which touches on the concept of POST overriding. I recommend everyone to check it out.

The next version of Symphony will have native functionality to define event value defaults and overrides.

We are working on a new Symphony website that runs on the new members extension and will be updating the security protocols accordingly. In the meantime, we view DOM hacking user IDs as an annoyance but it's not severe enough to put our time into--not while we are working on a completely new backend infrastructure for the upcoming website.

Attachments:

sym3-event-override.png

Am I missing something here, or is this still an issue with the new members extension?

I'm implementing a simple commenting system right now and actually managed to post as another member by simply changing the member-id in the comment form.

Already checked member's readme and wiki, but didn't find any clues how to properly implement and secure something like this.

@designermonkey's comment is the best thing to quote here:

It isn't a security issue for the core/members like Michael says. Front-end security is more to do with how the developer builds the site. If you have front-end submission, it's the developer's responsibility to ensure that all submissions are checked for XSS (with the XSS filter) and that any ID's are correct and pointing to the right places with Symphony events.

The Default/Override value that Allen has shown the screenshot for can be achieved now in Symphony 2 with the Default Event Values extension. You can then force the id (or whatever your field may be) to be {$member-id}.

Hope that helps, I'll update the Members wiki to include this tidbit.

Thanks for pointing me in the right direction, that's exactly what I was looking for.

Also good to know this feature is considered "core-relevant" for the future.