Forum OpenACS Q&A: Re: Security issues with HREF?

Posted by Staffan Hansson on
Thanks Jeff, I've decided to take my chances and allow HREF. Malicious HREFs don't seem quite as deceptive as their SRC counterparts - if they don't contain javascript, that is, in which case they can be disguised into looking harmless in the browser. So no javascript allowed.

I've read through the interesting pages you linked to, and think I've gotten the general picture. Now, since the various articles specifically refer to Apache, PHP, and just about everything except the OpenACS environment, I was wondering how vulnerable our particular toolkit is to dirty tricks like XSS (cross site scripting), cookie theft, etc. What are our strengths and weaknesses in this respect? Apart from security being constantly in mind during development, has some überhacker in the community done a comprehensive analysis of the code base specifically looking for security holes? What's the perceived security status?

Posted by Tom Jackson on

A lot of issues would go away if you only allowed POSTed data for form submission. Clickable links which allow for drastic action easily allow abuse.

Another issue is the permission context of a user. It is built up permission by permission, and admins can do everything without question. Allowing admins to browse the site, or read their email with their admin account makes it difficult to protect against XSS.

Most if not all these attacks could be eliminated by requiring some type of human acknowledgement of insert/update/delete actions, such as reading an image. It may annoy your users, but they are starting getting used to it. Personally I think it is quite drastic to nullify many of the benefits of the web and community collaboration by disallowing image links, although I think we will live without frame/iframe/object tags.