Evaluating user input on the client side and checking for "<script>", etc. tags is a good practice, however, there are ways to bypass such input validation. So the next best line of defense is to validate/re- validate on the server side where the GWT RPC call terminates. I am wondering what solutions exists at that end. -- Thomas
On Jun 11, 5:20 pm, Jeff Chimene <jchim...@gmail.com> wrote: > On 06/11/2009 04:18 PM, tamsler wrote: > > > I am trying to figure out what the best way is to handle JavaScript > > injection cases. Since any client side input validation handling > > doesn't truly prevent one from injecting JS such as using tools like > > Firebug to re-post RPC calls etc. > > > I am wondering if anybody has attempted to intercept JS injection on > > the server side by "scanning" RPC calls . I could imagine using a > > servlet filter to do this or or some other way. > > > Any ideas/feeback is greatly appreciated. > > It's a good question, but it's not really GWT related. > You're talking about server-side code. The JS code generated by GWT > executes in the browser. > I may be completely missing your point, but perhaps these articles may > be > apropos:http://code.google.com/webtoolkit/articles/using_gwt_for_json_mashups... > andhttp://code.google.com/webtoolkit/articles/put_your_gwt_app_on_facebo... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
