• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4523: You can add all sorts of scripting via URL and get it shown on any topic with URLPARAM

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Normal Closed   minor 4.2.0

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


URLPARAM and a lot of other stuff that displays input given via the query string seems to worry many admins as a security issue

We had a similar bug recently related to what is shown in the oops screen.

Now it is what is shown in the TagMeSearch topic from the Tag plugin.

But it is a generic issue.

I have made a simple Item4523Test topic that demonstrates.


You will see a picture of Droopy there which is because the odd URL adds an image tag <img src=http://philfree.1.googlepages.com/droopy.gif>

Now the question is: Is this such a big problem? Do we want to block > and <? or html entity encode them?

The real issue is that you can fire off scripts.


If we address this by manipulating the input already at the URL entry but it will then mean that would never be able to pass the characters > and <.

Unless we can find a better way. Note that none of this compromize the server or the content in the TWiki. It just enables sending URLs that redirect you to somewhere else. And this could be a site that looks like TWiki but asks for username and password, and the attacker then snaps that and abuse it later.

-- TWiki:Main/KennethLavrsen - 30 Aug 2007

I blocked the obvious infinite loop. Leaving open while we debate the merits of further processing. My personal view is that filtering the values of URL parameters is inappropriate. URL parameters are expanded in text, where the standard text filtering should deal with them.


I agree. I see no issue that you can add a Droopy picture in a web page. I see that as a nice feature.

it is just the scripting insertion via URL that we should try and avoid.

-- TWiki:Main.KennethLavrsen - 30 Aug 2007

If scripting is disabled on the site, it is disabled for URLs - unless you can demonstrate otherwise....

-- TWiki:Main.CrawfordCurrie - 30 Aug 2007

It seems that some also have concern about injecting dirty pictures and the like.

But I really do not want to miss the possibility to pass a search criteria with greater than or less than. So just removing > and < is not a nice solution. A reference for inspiration is http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-2423

-- TWiki:Main.KennethLavrsen - 30 Aug 2007

I repeat: If scripting is disabled on the site, it is disabled for URLPARAMs. I do not believe we need to do anything else specific to URLPARAM.

-- TWiki:Main.CrawfordCurrie - 31 Aug 2007

But injecting an image is not disabled. And that concerns the reporter.

Turning off scripting totally to prevent scripts being entered via the URL is not a solution.

-- TWiki:Main.KennethLavrsen - 02 Sep 2007

This bug has been discussed extensively on IRC tonight in the freetown beta release meeting.

The main problem is that URLPARAM can be used in an unsafe way. Although it should be the responsibilty of the people that use URLPARAM (TWiki app devs) to use it safely, the current modus operandi is 'unsafe by default'. This should be changed to 'safe by default'.

'Safe by default' means: urlencode < and >. This behaviour should be overrideable, with for example an unsafe="on" parameter to URLPARAM, like so:

%URLPARAM{"foo" unsafe="on"%

Which disables the filtering on foo. So you are explicitly adding the paremeter, named 'unsafe', which is an indication that you need to think about what you are doing.

One argument against this solution might be: "but what if twikiguest edits the page and puts in an URLPARAM with unsafe="on"? The answer would be that when you allow editting, you can already insert scripts/images.

Another important argument against the above proposed solution: it could/will break backward compatibility. I am unsure as to the actual impact, some think it is low, some think it will be high. I'd appreciate thoughts on this. I suspect it is actually quite low, but that is just a guess.

One last note: be aware that there is no 'trusted' context (eg: 'we are behind a firewall so we are safe'). The point is that someone may craft an email, with a link to the internal intranet twiki, but an URLPARAM abuse that puts a fake login screen on the employees screens. This would allow to harvest employee passwords.

-- TWiki:Main.KoenMartens - 02 Sep 2007

Looking at VarURLPARAM we already have more or less what is needed

URLPARAM as an encode option which per default is off.

We can add a new value "none". And let "entity" be default.

If someone needs to change a TWiki app because of this then I am sure that are happy to learn that their current approach is unsecure and that the change will be safe.

This seems pretty easy to implement.

Still needs to look at the other values for encode. Maybe people still want to use those AND be safe.

-- KennethLavrsen - 02 Sep 2007

Wikipedia has a good description of the problem.


-- TWiki:Main.KennethLavrsen - 02 Sep 2007

Two things.

Read some of those links in the Wikipedia articke. You really learn something new and you learn that indeed we should do something.

Then do a simple text search in the TWiki web. Then you learn two things

  • We have many URLPARAMs in the default topics that attackers will know are there and can abuse.
  • Some of them are used so the application is broken if we simply encode > and <.
So we need to do some thinking. The easy solution is not the right one. -- TWiki:Main.KennethLavrsen - 03 Sep 2007

Here is an example of broken twiki app.


Entity encoding the password would mean that certain characters could not be used in the password. But then again - could the twiki application actually work anyway the way it is written if you used < and > and "

-- TWiki:Main.KennethLavrsen - 03 Sep 2007

We have decided to implement the encoding and see if we can break it. Best idea on the table. Leave as urgent (potential release blocker)


Kenneth's example shows that ecode=entity won't be a solution - and as any exceptions are implementable by hackers,

I've implemented a dumb, and non-optional filter for all < > ' and " chars. Lets find out how many TWikiApps die, and then see if its proportional to the risks.

(change password does not use URLPARAM.) ... unit test fix to follow

-- TWiki:Main.SvenDowideit - 15 Sep 2007

There is very little difference between

<verbatim> http://develop.twiki.org/~twiki4/cgi-bin/view/LitterTray/Item4523Test?parameter=%3Cscript%3Ealert(%27BT%20INS%20XSS%20Test%27)%3C/script%3E </verbatim>

from above (disabled with this patch)

<verbatim> http://develop.twiki.org/~twiki4/cgi-bin/save/LitterTray/Item4523Test?text=%3Cscript%3Ealert(%27BT%20INS%20XSS%20Test%27)%3C/script%3E </verbatim>

(which still works fine) when it comes to intranet sites.

Imho it would be good to have this kind of crippling functionality depend on a "I can not take responsibility for my own http actions" option.

-- TWiki:Main.SteffenPoulsen - 15 Sep 2007

Wondering about the <verbatim>? First TWikiApp dead with the new patch ( %COMMENT%).

-- TWiki:Main.SteffenPoulsen - 15 Sep 2007

um, can you elaborate? I have no idea what you%27re saying

-- TWiki:Main.SvenDowideit - 15 Sep 2007

The <verbatim> comes though as >verbatim<, not <verbatim> - and therefore loses its intended effect.

The apostrophe are currently url-encoded, better to use a HTML entity like '.

-- TWiki:Main.SteffenPoulsen - 15 Sep 2007

Steffen is right.

You cannot type <verbatim> any more in the comment. The > and < gets entity encoded.

I am surprised that comments use URLPARAM this way.

What was the exact change you did Sven.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

Another question. Does the text in comment come from GET or POST?

I could accept less protection via POST than GET.

This will be a tough nut to crack.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

no, we can%27t aford to open up some places to hackers - I%27ll take a look at comment plugin - to make sure that it has reason to use URLPARAM.

Love the fact that in my reply to Steffen, I even showed the problem smile

-- TWiki:Main.SvenDowideit - 15 Sep 2007

URLPARAM is used in quite many COMMENT templates. And therefore also in the many self made COMMENT templates out there.

This means that we simply cannot encode characters unconditionally in URLPARAM. That is total destruction.

This unfortunately means that we have to find a different strategy to get rid of the problem. Because I agree we need to close the XSS issue.

But my own proposal - encoding > < and " in URLPARAM is too destructive to even simple twiki applications.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

This is a braindump. Feel free to totally flame me.

The issue is people sending emails or creating websites with URLs or Forms containing images or scripts. The URLs I found on Wikipedia shows how difficult it is to filter out scripts etc because you can embed your crap in all sort of HTML tags without even using the word script.

And our problem with encoding URLPARAMs is that it breaks our TWiki applications. TWiki applications normally have the thing in common that the topic with the URLPARAM is called from within TWiki.

Is there a way we can make the encoding of < and > and " based on referral? Ie. not encoding when the topic is reached from another TWiki topic on the same server?

Putting on my asbestos suit. Flame me.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

it may be %27too destructive%27 , but it may also be the only option?

-- TWiki:Main.SvenDowideit - 15 Sep 2007

Sven, if you were really serious that we can%27t afford it - I would expect you to instantly open up urgent bugs for save and all the other "attack vectors" we are currently leaving wide open (save is demonstrated above).

More brainstorm: Other means of tackling this issue could include:

  • Only react to URLPARAM in already existing sessions, not newly created ones (avoid "first click" attacks)
  • Send out magic bit with every page view - only do actions if magic bit is sent back correctly (avoid "first click" attacks)
  • Look at easier ones like only reacting to http posts or checking that the referrer is trusted (not sure how much point there are to the form one as there is of course no problem in having forms in e-mails).

I would accept a solution where you could set an option in configure that would make "first clicks" "read only" and only when "trust" is established full interaction could occur (as the real problem as I understand it are related to unfortunate "single clicks"). But that we even consider crippling the platform in a generic way like this patch does is making me feel very, very uncomfortable.

-- TWiki:Main.SteffenPoulsen - 15 Sep 2007

mmm, I;m not going to start on the other issues, cos we can't even find a good resolution to this one frown

Don't bother attacking me, this is not my problem, its TWiki's.

I'm not sure that session based first click does anything - I'm running my browser, I'm logged in, then I receive a hacking email - when I click on it, I'm already in the session.

last time I looked at magic bits, I thought they were also not a secure thing, just a hope no one finds a pattern and tricks it.

so - keep trying - I think Kenneth's referer is more interesting - but I thought I recalled that spoofing that is easy too.

The core issue that I've grappled with every time I've involved myself in TWiki security issues, is the constant barrage of responses that insist that TWiki is much more important than security. I've even been guilty of it - but in the end, I think its just lazyness. We, as a group, are too lazy to find the secure alternatives to the mess we have.

So, for now, until I get worn down by all the nay sayers smile I'm going to try just to solve the URLPARAM problem. COMMENT plugin is one place where work will be needed, but IF its the only thing that you can come up with, there's not much of a problem, just some work.

BTW, I don't consider COMMENT a TWikiApp, its just a simple Plugin, and even better.... one I seem to have the source to.

-- TWiki:Main.SvenDowideit - 15 Sep 2007

We need to revert this URLPARAM change. Nothing done with Comment Plugin works anymore.

It was my proposal and I admit it was a bad one now we see the result.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

I did the reversion.

Please note that when we later reapply the code with additional fixes it is SVN 14873 that does the code and 14874, 14875 that adds good unit tests both for URLPARAM and XSS attack vector. I also reverted those to prevent unit test errors.

Let us continue with the ideas and reapply a better fix within the next days. I agree with Sven 100% that this needs to get fixed some way or the other.

And we will.

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

Bad use of URLPARAM

  • People clicking on a link in an HTML email that contains scripts that can do evil.
    • Question: Can an email contain an HTML form? Can you POST data as XSS attack?
    • Question: How many of the default distributed topics could we secure by using current encode="entity" for the URLPARAMs. The default TWiki topics are the obvious attack vectors. Secret twiki apps behind a firewall may not be such a big risk.

Good use of URLPARAM

  • People submitting HTML forms from TWiki topics containing either GET or POST type data. Data can contain > as well as <. And it can contain HTML and TML. We do not want to prevent this
  • People submitting HTML forms with Comment Plugin.
  • Question - will people need to be able to submit forms from outside TWiki to TWiki?
    • Question - if above is a yes - is there any reason not to allow unsafe use of URLPARAM if it is documented well. For a TWiki application to be a attack point it has to be known. The main problem today is that TWiki ships with maybe 40-50 default known topics that can be used as attack point for XSS. All you need to know is the internal URL for TWiki
    • Question: Can we encode < and > and " when the GET or POST comes from external links? Is it too easy to spoof? Can we avoid spoofing. Or minimize it?

-- TWiki:Main.KennethLavrsen - 15 Sep 2007

I'm bothered by the attempt to create some set of exceptions to the securing of URLPARAM - just reading the Wikipedia link about XSS should help you understand why.

As soon as you try to open up some of the attack vector, someone who spends an awful lot more time thinking about this than any of us, will find a way to exploit the exceptions.

While we continue to consider TWiki as more important than security, there's little we're goin to acheive.

-- TWiki:Main.SvenDowideit - 16 Sep 2007

Perhaps we should use some energy on agreeing on assumptions first - my suggestion would be:

  • save, URLPARAM, rest, upload, etc etc should be handled in a generic way as possible - I currently have trouble understanding how one is more important than the other
  • We can't rely on any "tricks" to figure out whether a request is "XSS-safe" or not (no referrer-checking, no get/post magic, no magic bits, no session check etc etc)
If we can agree to assumptions like this, perhaps a solution that does something like this would work:

  • If a request comes in, and the URL (GET/POST) contains any parameters at all - what you are going to get is
  • Users with a "certified XSS license" can disable functionality by having a "* Set TRUSTMYURLPARAMS = always / existing sessions / never" in their homepage (admins trusting their users can set it in TWikiPreferences).

Bottom line is that people should have in their face what they are sending to our platform - until they actively confirm they are able to handle it. It comes down to responsibility and in this way the responsibility can go from being TWikis to being something a user can actively choose to take on to himself.

In short: We aren't to globally choose how flexible our platform should be in an arbitrary context - the user (or local admin) is.

(Probably some would call this a CMA ("Cover My Ass") approach - I think they would be right smile )

-- TWiki:Main.SteffenPoulsen - 16 Sep 2007

We will find a safe solution to this problem. And anyone reading the log from the last two release meetings will see that I more or less said the same as Sven.

It is just that the proposed fix of always entity encoding < and > and " is not the right solution because it makes TWiki stop being TWiki.

But I am not giving up.

Remember that this security issue does not run code on the server.

What we try to achieve is preventing attackers to send emails with HTML that a TWiki user will be fooled into clicking on - and which typically redirects him to an alternative site where he will enter his username and password.

This is why I am looking at the GET vs POST parameters. Not the method of http (GET vs POST) but whether parameters are given via the query string or POST parameters. PHP used to not care but triggered by safety issues they changed this in PHP 4.2.0 and on so you can choose to only accept POST type parameters and not parameters in the URL string. ( $_GET() and $_POST() ).

I would think that PART OF a solution could be to always entiry encode the dangerous characters when passed in the URL string. And somehow protect the POST type variables when a page is viewed and it is not the result of submitting a link from the same TWiki.

Most XSS attacks are simple URL query strings that look harmless and normal to the user and people receive them in emails.

You would not be on some porn site and expect a link back to your intranet TWiki inside the firewall of your TWiki - so this is not the kind of attack we are protecting the business TWiki against. It is email attacks targetted at a company that are the most dangerous kind of attacks.

-- TWiki:Main.KennethLavrsen - 16 Sep 2007

I am unsure if it isn't just an arms race. I.e.: If we block GET, XSS'ers will just use POST. I think the #2 assumption above holds true - we should forget about trying to figure out "safe" ways - as Sven says, if they work for us, they will just be abused by black hats also.

-- TWiki:Main.SteffenPoulsen - 16 Sep 2007

I am testing the POST method by making email attacks on my own server at the moment. Simply to gather data.

-- TWiki:Main.KennethLavrsen - 16 Sep 2007

You can send a POST form which works - by email.

Thunderbird will not submit the parameters in the form but I am sure other email programs will.

Next crazy proposal.

This proposal could give pretty good protection in practical.

Let us assume that

  • We always want to entity encode < and > and " when TWiki is reached from externally
  • We feel safe to not encode them if the form is submitted from TWiki.
  • We could assume that a form is submitted within a certain time since the topic holding the form was submitted. Let us say 8 hours = one normal working day.

If ALL Twiki topics always contained a hidden parameter in its form used for edit links etc which is the timestamp of the topic. Then we could let ANY input given through the CGI param hash be entity encoded for the < and > and "

First reaction will be - it is easy to Javascript the timestamp.

But not if it is encrypted by a key which is unique to each TWiki. The key can be generated by configure and changed by the tick script. If we put two keys and retire the oldest and add a new each time we run the tick - making both valid keys - noone will get caught by viewing a topic before the tick and clicking a submit button after.

This way an attacker will need to get a complete twiki topic from the victim to get a valid key and only have 8 hours to make his attack.

And even if he manages to crack the key - he only has maybe 24 hours - then the key is updated by the tick (if the tick is run)

If additionally the encrypted timestamp is encrypted by a cipher which is the key + the IP address of the user - then it will be quite hard to setup an attack.

I was also thinking about using the referring topic as part of the encryption key. The user name is no good because the user may not be authenticated when he views the form.

When I talk about the tick - it can also be the internal TWiki tick depending on the $TWiki::cfg{Sessions}{ExpireAfter} setting.

The encryption method can be one of the simple ones that are available in Perl.

-- TWiki:Main.KennethLavrsen - 16 Sep 2007

3 things.

  1. I'm shocked at how quickly you guys have given up on fixing the root cause - no-one even bothered to look into if the broblem was solveable
  2. adding a checksum / validation key does not help - all I need to get around that, is a simple piggy in the middle (apache ProxyPass with a little sugar)
  3. I agree with Steffen, we should fix save and all the other vectors, but personally, I find it easier to reduce my scope, so that I can focus on the root cause, and then expand it applicability.

So - I'd go back to escaping everything, then looking at what we do about the things it breaks... one at a time.

-- TWiki:Main.SvenDowideit - 17 Sep 2007

I haven't found the root cause of this problem, so I would like you to share it if you have.

I am not sure we can define the problem until we agree on the assumptions.

-- TWiki:Main.SteffenPoulsen - 17 Sep 2007

The root cause is simple. We have a feature in TWiki which is a full flexible ability to pass any text to any topic or template using URLPARAM. This is a very useful feature that we do not want to loose. But also a wide open gate to XSS.

So the exercise now is to

  • Understand how XSS attacks occur and what the attacker can do.
  • Implement a fix that prevents these attacks but still enable us to create HTML forms and submit text to twiki topics including the special characters.

We have already come far.

  • We understand now that attackers can use both GET and POST.
  • I think we agree that attacks mainly come via emails and documents attached to emails (could be an HTML file)

Sven. The "piggy" with ProxyPass - can you explain that?

-- TWiki:Main.KennethLavrsen - 17 Sep 2007

piggy -- middleman exploit - and looking at how apache ProxyPass works, there's not a massive customisation needed to let you use it to sit in between the server and client.

Root cause of this, and other security issues:

  • TWiki currently does not filter user inputs either at the input stage, nor at the output stage.

When I put it like this, and consider the MACRO-ness of TWiki, its rather clear, that we don't need to do to much filtering on the input side - as its circumventable by seperating the 'dangerous' bits into 2 TWiki VARIABLES that are then concatinated cleverly (ie, non-obviously)

Instead, we need to look at filtering before we output everything. For Javascript, that may mean refusing any inline javascript, and setting secure whitelist of javascript files that can be loaded into the page.

Thus removing the risks of insecure javascript in topic text, hacker provided attachments, and from external sources.

Similarly, post processing the html to prevent html forms from specifying action url's outside of either the twiki, or some whitelist, etc.

By being able to 'know' that the html sent to the browser has been stripped of non-whitelist javascripts, we can thus allow things like URLPARAM to contain all characters.

-- TWiki:Main.SvenDowideit - 18 Sep 2007

As I understand it we have no way of telling a middleman from a client, so it is a scenario of little interest. Even SSH needs a previous key exchange/knowledge to tell the two cases apart.

As I see it the root cause of this is that we are giving an arbitrary user a lot of power (and unfortunately, that's a whole lot more than he can handle in some cases).

That's at least three shots at a definition of the root cause for this problem.

-- TWiki:Main.SteffenPoulsen - 18 Sep 2007

It seems to me we describe the same root cause so let us leave it at that.

I do not think we should consider the man in the middle case. Once you have a machine in the middle - there is not much protection anyway. If you want a rock solid security - you would not start with a Wiki anyway. You would serve static webpages and very limited web based applications.

What we need to prevent is the classic XSS where a user thinks he is looking at his local well known TWiki site - but some scripting is injected via parameters passed to the twiki topic.

And the most common way this happens is that a user receives an email encouraging him to go to an internal website and view a specific page and maybe submit some information. The XSS script makes a redirect to an outside page or injects an HTML form asking for user name and password. But instead of posting the username and password to the local TWiki - it is sent to an external IP address that snaps the information.

If the attacker already have write access to the TWiki then we are way passed what is an XSS attack. The XSS attack against TWiki that we need to address is an attack on a TWiki which may even be inside a firewall out of reach of the attacker. And all the attacker want is the users username and password so he can gain access to other resources. The common attack method is that the attacker sends an email where the XSS is either HTML in the email or HTML in an attachment. And this is why I think PART OF the solution is to implement a very hard input filter when a topic is reached with URL or form parameters and the submission did not happen from a local TWiki topic.

But my idea of an encrypted timestamp requires that we inject a hidden parameter on all forms in a topic.

Sven outlines some output filtering and that I also think should be part of the solution. But it is hard. Can we filter off inline scripting of the output of URLPARAM? This must be possible. But I am not sure it is easy.

-- TWiki:Main.KennethLavrsen - 18 Sep 2007

I promissed Crawford I would make some examples of XSS attack vectors.

I actually made an entire XSS setup including a bogus login page that actually also stores usernames and passwords.

If you try the URL below please do not use your real password! Unless you want to share it with me


This vector takes advantage of a URLPARAM in an input field of a default TWiki topic in the TWiki web. The URL has been encoded so the user that clicks it does not easily see where it leads to.

I will try and see if I can sneak a script out of a URLPARAM inside a SEARCH or an IF. We have quite many of those.

-- TWiki:Main.KennethLavrsen - 18 Sep 2007

It is clear that there is not one single solution to this. And the solution package is going to be a process requiring solid testing.

I propose to defer the solution to 4.2.1 with a clear statement in the release note that the issue is known and is being addressed.

Meanwhile what we can do is walk through all the default topics in TWiki web and change the encoding from the defauly none to a more secure - where possible. At least this gives less attack vectors and we may end up with 2-3 topics that people should pay attention to only.

This does not protect users own topics but for an XSS attack to be launched against such for a non public site - the attacker needs to know much more than you normally do.

The problem with the default topics is that all the attacker needs to know to attack is the URL of any topic - maybe picked from a trashcan or seen in a presentation - and then he will know the exact URL for all the default distributed topics. If we can close just those holes I think we have done a good enough job for 4.2.0.

I think this approach is better than risking injecting some major bugs into TWiki with a rush implementation. I am 100% sure other bugs will require a 4.2.1 within 1-2 months and then we have time to do a better solution and think carefully about it - experimenting only on the MAIN branch etc etc.

-- TWiki:Main.KennethLavrsen - 19 Sep 2007

I have a functional solution, but it requires the handler described in Item4675.

-- TWiki:Main.CrawfordCurrie - 19 Sep 2007

Please share your thoughts. There is no reason to keep this secret.

XSS is a security level 3 thing and per our police we can treat this as normal bug report.

In fact since our XSS sensitivity is designed into TWiki as a feature and not a bad programming bug, we can and should be totally open about how we - as a community - will address this - to make the TWiki experience a better and safer thing.

-- TWiki:Main.KennethLavrsen - 19 Sep 2007

I'm also leaning towards 4.2.1, especially because my proposal requires re-working of skins and plugins that expect to be able to use inline javacript.

-- TWiki:Main.SvenDowideit - 20 Sep 2007

I have often said that output filtering is near impossible to do so it is safe if the filtering is to remove specific unwanted script elements simply because there are so incredibly many ways active content can be added to an HTML page.

This resource is an incredible inspiration - both for hackers - and for security auditors - and for us - for what kind of XSS attacks you can use. It lists a very long list of exploits and most of them would work on TWiki - with little extra effort is adding the characters that makes the active code breaks out of the content in which URLPARAM is used.

At least I said many times "I did not know you could do that".


-- TWiki:Main.KennethLavrsen - 20 Sep 2007

I contend that output filtering is near impossible to do so is incorrect - we are able to filter out all inline javascript. One of the happy side effects, is that instead of there being many ways to add active content, we reduce it to one. That way we are able to secure it, manage it, and optimise it. And Crawford has pretty much proven that it works.

-- TWiki:Main.SvenDowideit - 20 Sep 2007

Some new info I read on What Ruby on Rails Can Learn from ASP.NET:
Ideally we want a shared secret between the HTML that contains the form and the rails code in the action. We don't want this to be accessible to third parties so serving as JavaScript isn't an option. The way other platforms like Drupal achieve this is by inserting a hidden form field into every form that's generated that contains a secret token, either unique to the current user's current session or (for the more paranoid) also unique to the action. The action then has to check that the hidden token is correct before allowing processing to continue.

-- TWiki:Main.ArthurClemens - 25 Sep 2007

I checked in the SafeWikiPlugin, which I believe answers the requirements raised by this topic - or at the very least it provides the tools a site needs to be able to make their site unusable for cross-scripting. Performance needs to be assessed.

-- TWiki:Main.CrawfordCurrie - 02 Oct 2007

Could some kind soul please wrap this long discussion up,preferably in a Codev topic? It looks as if there are design issues being discussed in a bug report, which is a bad habit. For me it is impossible to guess

  1. What the problem actually is (the full attack vector, not just the "there's inline script" bit on which the SafeWikiPlugin is focussing)
  2. Which effect the fixes, or the plugin, will have on my existing installation,
  3. What TWiki authors can do to write %URLPARAM% correctly. The current SVN VarURLPARAM.txt just says "There's a risk" which is plain FUD.

-- TWiki:Main.HaraldJoerg - 02 Oct 2007

Dropping from Urgent to Normal with the availability of SafeWikiPlugin.


OK, the lack of feedback suggests that everyone is happy with the SafeWikiPlugin as a solution, so I'm releasing it.

-- CrawfordCurrie - 06 Aug 2008

Released to http://twiki.org/cgi-bin/view/Plugins/SafeWikiPlugin. I consider this issue closed.

-- CrawfordCurrie - 06 Aug 2008

Cleaned "WaitingFor" field.

-- TWiki:Main.GilmarSantosJr - 10 Aug 2008

Summary You can add all sorts of scripting via URL and get it shown on any topic with URLPARAM
ReportedBy TWiki:Main.KennethLavrsen
Codebase 4.1.2, ~twiki4
SVN Range TWiki-4.2.0, Mon, 27 Aug 2007, build 14639
AppliesTo Engine

Priority Normal
CurrentState Closed

Checkins TWikirev:14664 TWikirev:14873 TWikirev:14874 TWikirev:14875 TWikirev:14883 TWikirev:14971 TWikirev:15108 TWikirev:15130 TWikirev:15150 TWikirev:15174 TWikirev:15175 TWikirev:16318 TWikirev:16319 TWikirev:16320 TWikirev:17345
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r71 < r70 < r69 < r68 < r67 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r71 - 2008-08-10 - GilmarSantosJr
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback