It works well as it is, and reimplementing it could introduce new, unknown bugs. But if it becomes much cleaner, it may well worth the risk.
Another issues: - will this change introduce a new depency on a third-party JSON library, like jackson or json-lib, or will Wicket roll its own JSON parser/generator? - will JSON be more or less readable than XML in the AJAX debug panel? As it is now, the html and javascript sections are escaped only with <![CDATA[]]>, leaving the contents intact. As I understand, the JSON output would be full of backslash escapes for quotes, making it quite unreadable (unless enhance the panel to display it properly, of course). Tetsuo On Tue, Jan 10, 2012 at 1:47 PM, Bertrand Guay-Paquet <[email protected]> wrote: > >> I don't fully understand the blog post about the security problems. From >> what >> I can see, you need to be able to render a mallicious script tag to be >> able to >> intercept the JSON data. But if you are able to do that, there are much >> bigger >> problems. > > Indeed. If a malicious script can be injected, the DOM can be completely > controlled and intercepted no matter what kind of encoding is used for the > ajax response. However, the technique described in the blog means that raw > components of a JSON response which are not added to the DOM can be > intercepted by a malicious script by overloading array methods. > > I am unconvinced that using xml responses solves this problem though. Can't > the javascript functions processing an xml response be overloaded just as > well to capture it? >
