I've just discovered what I consider to be a security risk with the WebSpellChecker control. Our web app uses the WebSpellChecker control with the U.K version of the dictionary. We therefore have to set the dictionary in code as follows:
When viewing the source of the rendered page I was shocked to find that the Javascript ig_CreateWebSpellChecker function generated by the control contains the full physical path to the .dict file e.g. E:\MyWebApp\WebApp1\_dictionary\uk-english-v2-whole.dict
This sucks. Any potential hacker can simply navigate to one of the web pages that contains a spell checker control, examine the Javascript on the rendered page source, and hey presto they now know the physical path of the web app.
Why does the full physical path of the .dict file need to be included in a client side function?
M.Johnson
Can I ask if this issue is fixed in the current version of this web control?
This is certainly something we'll want to take care of - I definitely understand why you wouldn't want to tell hackers anything about your site/server that they couldn't find out themselves!
I believe the value is sent down with the ASPX page so that it can be sent back up to the server when the secondary webspellcheckerdialog window is displayed. The problem is that the two pages are distinct and they need to be able to pass information between them. The solution is to find a state medium, either through session or in this case through the client. However, that's no reason to broadcast your physical environment, and there should be ways to correct this, even if it comes down to garbling the string.
It's best if you go directly through our support department with this incident so that a formal ticket can be created and we can give you a case number for reference. The support options are listed at http://www.infragsitics.com/gethelp, or you can go directly to the online incident reporting page @ http://devcenter.infragistics.com/Protected/SubmitSupportIssue.Aspx
Thanks again for taking the time to report this,
-Tony