Security in gwt application.

2012-11-08 Thread Anuradha bhat
Hi , We have developed a gwt application. We foundDOM based cross site scripting issue in our .nocahe.js file. Here is the part of the code mentioned in .js file which is vulnerable. Can any body help me in finding , which type of java code will generate this code? Is there any way to do rev

Re: Security in gwt application.

2012-11-09 Thread Joseph Lust
Set the compiler *style* to *PRETTY* as it will be much easier to understand what is doing this if the code is not being obfuscated. However, what is the apparent issue with this code. It appears it appends the DOM and is looking at the current location of that page. As long as you use the Saf

Re: Security in gwt application.

2012-11-09 Thread Matthew Dempsky
It looks like that code comes from dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js or computeScriptBaseOld.js. On Thu, Nov 8, 2012 at 10:37 PM, Anuradha bhat wrote: > Hi , >We have developed a gwt application. We foundDOM based cross site > scripting issue in our .nocah

Re: Security in gwt application.

2012-11-09 Thread Joseph Lust
But the only doc.write in either version of computeScriptBase is clearly a string literal, not an injection worry. Perhaps tha was generated by something else. // If the user renamed their script tag, we'll use a fancier method to find // it. Note that this will not work in the Late Loading

Re: Security in gwt application.

2013-04-16 Thread Shashank Raj Holavanalli
I know exactly what is happening here. The variable "r" has everything that is present in the browser address bar. So a hacker can inject some html in the URL like this http://domain.com/. When variable "r" is written to document using document.write(lc + r + uc) the script injected gets writt

Re: Security in gwt application.

2013-04-16 Thread Shashank Raj Holavanalli
I am facing the same issue as well. So are you telling us this is a false XSS vulnerability detection ? On Friday, November 9, 2012 2:31:34 PM UTC-5, Joseph Lust wrote: > > But the only doc.write in either version of computeScriptBase is clearly > a string literal, not an injection worry. Perhap

Re: Security in gwt application.

2013-04-16 Thread Thomas Broyer
The question is: have you found where this script is coming from? 'cause I can't. On Tuesday, April 16, 2013 5:46:34 PM UTC+2, Shashank Raj Holavanalli wrote: > > I know exactly what is happening here. The variable "r" has everything > that is present in the browser address bar. So a hacker can

Re: Security in gwt application.

2013-04-17 Thread Shashank Raj Holavanalli
Thomas, I am using GWT 2.0.3 and this is being generated in the *.nocache.js. Is there any solution to this ? This clearly seems like an XSS vulnerability to me. Have you fixed this in the later version ? If yes then which one ? On Tuesday, April 16, 2013 6:49:29 PM UTC-4, Thomas Broyer wrote:

Re: Security in gwt application.

2013-04-17 Thread Thomas Broyer
On Wednesday, April 17, 2013 3:20:09 PM UTC+2, Shashank Raj Holavanalli wrote: > > Thomas, > > I am using GWT 2.0.3 and this is being generated in the *.nocache.js. > Come on, 2.0.3 is 3 damn years old! > Is there any solution to this ? This clearly seems like an XSS > vulnerability to me.

Re: Security in gwt application.

2013-04-18 Thread Shashank Raj Holavanalli
Thomas, This piece of code is in nocache.js *function getDirectoryOfFile(path){* * var hashIndex = path.lastIndexOf('#');* * if (hashIndex == -1) {* *hashIndex = path.length;* * }* * var queryIndex = path.indexOf('?');* * if (queryIndex == -1) {* *q

Re: Security in gwt application.

2013-04-18 Thread Thomas Broyer
That's more or less what I said: the odds that getDirectoryOfFile($doc.location.href) is actually called are a) very low b) dependent on how you call the *.nocache.js more than the runtime environment. Starting with 2.1.0, you can "set" the 'base' using (have a look how Google Groups uses it,