Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)

Collapse
53: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 51)
Posted by Tom Ayles on 06/04/04 11:23 AM

It's probably worth pointing out that this is by no means limited to OpenACS; someone brought up a similar point with PhpNuke in a posting to bugtraq about three months ago, and made the point that most web applications are affected by similar attacks. Unfortunately, there weren't any responses to it, let alone anything smart :). IMO, the sudo-style approach is the way to go (not necessarily with referer checks), as you can still send out emails to administrators with links to perform actions, e.g. approving requests etc. The super-paranoid could always set the time between reauthentication to 0.

Collapse
54: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 53)
Posted by Bill Katz on 06/04/04 05:12 PM
In looking around for XSS handling under various platforms, I was surprised how little the visiting-evil-website version of the hack was mentioned. Most people are implementing input validation. As of the 1.1 version of ASP.NET, Microsoft turned on validation by default. ASP.NET Request Validation and Cross-Site Scripting There were lots of complaints from their user-base, but it makes sense to be more secure out of the box, then allow savvy administrators to relax security. I'm still trying to get my head wrapped around the whole thing, but from my simplistic viewpoint, would the following work for a given website: (1) input validation everywhere, (2) administrator education that you don't wander with your browser, i.e. open/close whenever in admin role. #2 wouldn't protect against a teacher getting her class area hacked, but social engineering would help prevent OpenACS admin accounts from being misused.