We have a security (level 3 so bug report allowed) issue to resolve
When you create a URL like - copy the line to your browser URL entry and see the result.
http://develop.twiki.org/~twiki4/cgi-bin/rename/Bugs/Item4333?template=moveattachment&attachment="<script>alert('BT%20INS%20XSS%20Test')</script>"
a small alert box comes up with is harmless but could have been a redirect to a phishing site that noone notice. This site could look like a TWiki and ask for authentication. But instead of authenticating it could steal your password.
The issue seems to be that OppsException allows anything from a URL to parse through to the generated HTML incl scripts.
We need to filter off or html entity encode certain characters so that you cannot plant scripts or anything that can redirect in a URL.
I am not talking about preventing putting scripts in a twiki topic as such.
We need to avoid that a person that does not have access to a TWiki can create a URL with a script which he sends to someone he knows has access. And when this person clicks the URL in the email he is fooled into giving his credentials.
So the bug report is about preventing anything in URLs that can redirect - and this includes scripts - to be planted in the resulting oops page.
Naturally we cannot prevent the traditional phising method of evil guys sending emails with URLs that are not at all a TWiki URL. But these things are now caught by many email clients such as thunderbird. But if the URL to a TWiki site is indeed the displayed URL the email client cannot see that it is a phishing attempt.
I am sure there are also many other good reasons to filter off garbage passed to oops templates so let us fix this.
First - before I try to implement some quick fixes. What can we filter off safely?
--
TWiki:Main/KennethLavrsen - 05 Jul 2007
I have been looking at this one.
The actual example is simple to resolve. There is even a smell in the code that points to the problem.
But I am sure there are many more of these since we have many situations where people can give funny stuff in a URL that gets displayed or goofs up either an oops page or any topic via URLPARAM.
So the generic question is: what features today are depending on allowing special characters to slip through?
Which characters could we filter off? Some of the dangerous ones are > and < and %. But on the other hand we may not want to limit the ability to pass a value like "10%" to a form value for example.
I would like to get some oppinions from some of the developers that knows the practical use of the templeates. Especially the oops templates.
--
TWiki:Main.KennethLavrsen - 09 Jul 2007
Filtering URL parameters would be a source of many, many bugs. Instead, the Oops pages should take care to encode their output so that URL parameters displayed on to the oops page cannot be misinterpreted as active HTML.
i have difficulty seeing this as urgent.
--
TWiki:Main.CrawfordCurrie - 14 Jul 2007
It is urgent because we promissed the reporter that reported this on the security mailing list that we would fix this in 4.2 - and I think this is important enough.
I agree on your evaluation of the URL filtering. I have looked at the code for many hours now - and filtering at URL entry breaks too many things or put unwanted limitations.
The question is - can we safely alter all > and < to html entities on the
OppsException handling?
Or does anyone know that we use the %PARAM.. to also pass html and similar.
A softer version would be to remove anything that fits with a script regex but it is difficult to get safe.
--
TWiki:Main.KennethLavrsen - 14 Jul 2007
I think you are looking in the wrong place. No error message should ever generate an output that includes active HTML, unless it is deliberate on the part of the reporter. You should be reviewing where the error messages are
thrown, not where they are processed, and ensuring that no error message can carry a payload from an uncontrolled source. in the specific example above, the filename should be reported only after it has been safety-filtered.
--
TWiki:Main.CrawfordCurrie - 16 Jul 2007
At the 16/7/07 release meeting we discussed this and agreed that while filter-in is the correct long-term approach, then filter-out is an adequate elastoplast.
Added the filter, and added unit tests for the exception classes, one of which ensures HTML cannot be accidentally output. All messages need to be reviewed to find those that pre-encode entities when generating the message; i already found one.
CC