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

The reading images thing is CAPTCHA, and it's not trivial to break (although the simple ones you see on yahoo can be broken something like 80 or 90% of the time by a program and the hard ones people will get wrong some substantial fraction of the time).

The nonce would not be a cookie, it would be encoded in the url or in the form data so that two gets in a row would not matter.

It's also not accurate to say it's a "problem with OpenACS", at least not in the sense that it is somehow unique to openacs. You see similiar problems in IIS, analog, bug trackers, mailing list software, basically anything that takes user input and puts it into html at any point.

Jeff, let me clarify: the problem is with handling form input, not the src attribute. You can't clean the entire internet of malicious src attributes, that is just a 'feature' of HTML/HTTP. But OpenACS doesn't yet have a general method of handling the issue. Blocking usage of the src attribute will not fix the issue, it only limits it usage on a particular server. If you set your browser up to not accept images except from the same server as the web page, this will help a lot. But you need admins to do this always and in every browser they use, but this only works for images, probably not for frame/iframe/object tags. Admins also shouldn't load images in email messages by default.

This doesn't mean that these attributes couldn't be used for other badness. If a site like a slashdot allowed something like this, it could be used to spam another site with lots of hits, shutting down the site with a DOS type attack. So limiting the use of these attributes is still important in general.

So OpenACS didn't cause the root of the problem, and it can't really be solved by disallowing usage of certain attributes. But OpenACS can be fixed to make this kind of attack very difficult if not impossible.