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

Collapse
10: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 1)
Posted by Tom Jackson on 05/28/04 08:03 PM

Okay, it is all coming back to me now. This is a problem with OpenACS, not the src attribute. If I was smart, I would just send a tempting email to all the admins: 

Hey X,

Check out this link on XSS: http://example.com/XSS.html

Then construct my unchecked src attriute on XSS.html

It seems the agreed upon solution is to require a tie between the form and the form processing script, and to require POST. I would add an 'I'm a human' test to certain actions as well.

Jeff, you once provided great links to open source tools for generating images to read, but I wasn't sure if the intent was to point out they are easily broken?? The nonce idea (or any tying method) would mostly eliminate simple attacks since it would require more than one request, but I'm starting to think that you could do something like 

 src="http://example.com/get-nonce"
 src="http://example.com/use-nonce"

That is, two images loaded in sequence. At the very least I have noticed that Mozilla serializes frame source loading.

Collapse
12: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 10)
Posted by Jeff Davis on 05/28/04 08:28 PM
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.

Collapse
14: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 12)
Posted by Tom Jackson on 05/28/04 10:48 PM

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.