I imagine that what this means is that POST params, can be substituted with GET params to make this exploit work - which I agree isn't ideal.
However, this is only of concern IF the data can be changed through IWP. If the data is read only, the vunerability cannot be exploited as no "transaction" can occur, which is what CSRF relies on. Thus, if you can make the accessed data read only, you should be ok, because data can only be viewed by the individual allowed and the data cannot be corrupted by CSRF as it's read only. I'd discuss this option with your IT department as it's possibly the simplest solution, and the data is probably read only anyway, or any changes that can be made are unimportant.
Filemaker Pacific have come back and said they are unable to assist with this one - at this point in time... Unfortunately ITS will not let me leave a site running with vunerabilites so it looks like I will be rebuilding this IWP site using CWP when I can find some spare time
There's another option. As IWP utilises a web server, which could remove the GET params (if any), before it hits Filemaker. Both IIS (Win) and Apache (Mac), support Mod-Rewrite, so you would ask the server admin to add a rewrite regular expression, that removes anything after the ? from the url.
This would eliminate the vulnerablity, however, if any GET params are needed for the operation of IWP, it will stop working. I hope this is not the case, but I don't have an IWP running to confirm.