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
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
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
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
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
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
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
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:
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.
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
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,
11 matches
Mail list logo