Home
The Toolkit for Online Communities
17464 Community Members, 0 members online, 1898 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : What a forking mess: noquote hell. : One Message

Forum OpenACS Development: Re: What a forking mess: noquote hell.

Collapse
Posted by Jeff Davis on
there is a place where you could turn it off (there was an exception for dotlrn for a while), although better might be to change 4.6.3 so ;noquote would be a noop. To be honest I don't think anyone has considered trying to maintain a single package to work on 4.6.3 and 5.0.

As for the security holes it fixes, I think XSS is reasonably important to guard against and noquote is the right way to fix it so I don't think we have made a mistake in making these changes.

Collapse
Posted by Tom Jackson on

It was my understanding that XSS was a large measure of social engineering, and a highly targeted exploit. Has anyone actually been a victum of XSS through OpenACS? But the problem with XSS is that it is so easy to dream up a way around any barriers. For instance on OpenACS.org, we know, or could guess who has admin rights for the site. If we try to post an exploit, the system will record the ip address where the data originated. Instead, a hacker could send an email, something like spam, which might be opened. If an image link src contained the request the hacker wanted to processed, an email application configured to load images might run the request with the user's privileges. I don't think XSS can be stopped unless you control the behavior of the users of your site (including the software they use and its configuration).

I'm interested in how you would disable noquote, but making it a noop in 4.6.3 might be good too.

Collapse
Posted by Dirk Gomez on
Tom, take a look here http://openacs.org/forums/message-view?message_id=154003

Should give you the idea.

As to has anyone been exploited through XSS? I wouldn't know, but do we want to wait?

It is the most frequently posted bug on any webappsecurity (or whatever) mailing list - has even surpassed SQL injection it seems - and doesn't require social engineering. It requires you to find a place where you can smuggle in mailicious HTML/JavaScript then you are set. Search around for XSS and see how the exploit works.

Collapse
Posted by Tom Jackson on

Dirk you may be interested to know that the X stands for 'cross'. That means the bad javascript or whatever could reside 'anywhere', like on another site or in an email. You just posted a 'link' above (which is a link to this page, so if you have another one going somewhere else, please post it), but what if, on that linked page, which is off site, I have constructed an image tag which does some work back here at OpenACS.org? I'm not sure how the patch affects this problem, which still exists, and is more likely.

Also, from what I can tell, we still spit out html entered by users, otherwise forums woundn't work very well. How is that safe? Because we filter _on the way in_. Just add 'nohtml' to variables that shouldn't contain html, where the database wouldn't otherwise barf on that type of input.

I've read, several times, the reasoning for using noquote. Mostly it was a rush job to get some new code out to a single client. There was no history, no legacy code to deal with. There were no other users to consider. But several other things were stated in the discussion: unquoted user strings work 95% of the time, and using noquote as a fix, breaks existing code. Instead of tracking down the 5% of the remaining problem, a quick fix was introduced, that would produce more visible errors.

Of course the main problem is that the noquote fix introduces its own version of a hard to find problem: over-quoting.

This whole problem is caused by sloppy development. Creating a list of how to avoid this under/over quote issue would be a good start. But XSS isn't going away any time soon, until a new HTML standard is drafted, and until all current browsers are removed from use.

Here's a simple example. I'm running 5.0.0b1a at 127.0.0.1:8000. In my home directory I create an html file which contains, among other things:


<img src="http://127.0.0.1:8000/admin/">

I haven't logged in in a while, so my session is expired on that server. When I load file:///home/tom/test.html, the access log gets two new entries:

127.0.0.1 - - [24/Dec/2003:09:56:03 -0800] "GET /admin/ HTTP/1.1" 302 364 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830"
127.0.0.1 - - [24/Dec/2003:09:56:11 -0800] "GET /register/?return%5furl=http%3a%2f%2f127%2e0%2e0%2e1%3a8000%2fadmin%2f HTTP/1.1" 200 5964 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830"

No javascript was used. The html page wasn't on the website, yet /admin/ was tried, and Mozilla even followed a redirect to login. Nice.

Now I login to the website using my browser, and reload the file, in another browser window here is the result:

127.0.0.1 - - [24/Dec/2003:10:02:08 -0800] "GET /admin/ HTTP/1.1" 200 3185 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830"

Huh? I'm using the noquote patch, and yet I just fell victim to XSS. This is why I say it is social engineering. All you have to do is figure out how to get your victim to follow a link, or maybe just read your email, if they allow their email client to load images.