Re: Security in gwt application.
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) {*
*queryIndex = path.length;*
* }*
* var slashIndex = path.lastIndexOf('/', Math.min(queryIndex,
hashIndex));*
* return slashIndex = 0?path.substring(0, slashIndex + 1):'';*
*}*
*
*
The “path” parameter to this function comes from
*document.location.href*attribute.
This function is basically finding the last index of “/” in the browser
address bar ignoring what is there after “?” and “#”.
From what I know DOM based XSS can occur by injecting scripts after “?” or
“#” like this
Server can sanitize this script because the value of the name attribute is
sent to the server
*http://domain.com/index.html?name=scriptMALICIOUS_CODE/script *
OR
Server cannot sanitize this script because the fragment after “#” is never
sent to the server and runs on the browser itself
*http://domain.com/index.html#name=scriptMALICIOUS_CODE/script*
*
*
nochache.js also has the following code
*base = getDirectoryOfFile(document.location.href);*
*document.write('script language=javascript src=' + base +
'scripts/xyz.js\/script');*
* *Our security analysis tool complains that this is an XSS issue since *base
*is not a compile time constant.
On Wed, Apr 17, 2013 at 6:08 PM, Thomas Broyer t.bro...@gmail.com 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. Have you fixed this in the later version ? If yes then
which one ?
There's been a few security fixes in latest versions (though not related
to this one).
AFAICT, assuming this is from computeBaseUrl(), this code will almost
never be called (it depends how you load the nocache.js), so there should
be no vulnerability in practice.
It'd help if you could give more info as to which code exactly you're
talking about (compile with -style PRETTY so the JS won't be obfuscated).
--
You received this message because you are subscribed to a topic in the
Google Groups Google Web Toolkit group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/WKcB-pDtfgA/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
*Shashank Raj Holavanalli*
Software Engineer
NetApp New England
*www.crackeasily.com* http://www.crackeasily.com
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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 meta
name=gwt:property value=baseUrl=foo/ (have a look how Google Groups
uses it, scoped only to the 'standalone' module so it's
name=standalone::gwt:property rather than name=gwt:property).
Starting with 2.1.0 you can also more easily replace that code altogether
with a custom linker (this was possible in 2.0.3 too but required copying
the whole IFrameTemplate.js whereas 2.1.0 made it more modular)
On Thursday, April 18, 2013 8:56:15 PM UTC+2, Shashank Raj Holavanalli
wrote:
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) {*
*queryIndex = path.length;*
* }*
* var slashIndex = path.lastIndexOf('/', Math.min(queryIndex,
hashIndex));*
* return slashIndex = 0?path.substring(0, slashIndex + 1):'';*
*}*
*
*
The “path” parameter to this function comes from
*document.location.href*attribute.
This function is basically finding the last index of “/” in the browser
address bar ignoring what is there after “?” and “#”.
From what I know DOM based XSS can occur by injecting scripts after “?” or
“#” like this
Server can sanitize this script because the value of the name attribute is
sent to the server
*http://domain.com/index.html?name=scriptMALICIOUS_CODE/script *
OR
Server cannot sanitize this script because the fragment after “#” is never
sent to the server and runs on the browser itself
*http://domain.com/index.html#name=scriptMALICIOUS_CODE/script*
*
*
nochache.js also has the following code
*base = getDirectoryOfFile(document.location.href);*
*document.write('script language=javascript src=' + base +
'scripts/xyz.js\/script');*
* *Our security analysis tool complains that this is an XSS issue since *base
*is not a compile time constant.
On Wed, Apr 17, 2013 at 6:08 PM, Thomas Broyer t.br...@gmail.comjavascript:
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. Have you fixed this in the later version ? If yes then
which one ?
There's been a few security fixes in latest versions (though not related
to this one).
AFAICT, assuming this is from computeBaseUrl(), this code will almost
never be called (it depends how you load the nocache.js), so there should
be no vulnerability in practice.
It'd help if you could give more info as to which code exactly you're
talking about (compile with -style PRETTY so the JS won't be obfuscated).
--
You received this message because you are subscribed to a topic in the
Google Groups Google Web Toolkit group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/WKcB-pDtfgA/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit+unsubscr...@googlegroups.com javascript:.
To post to this group, send email to
google-we...@googlegroups.comjavascript:
.
Visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
*Shashank Raj Holavanalli*
Software Engineer
NetApp New England
*www.crackeasily.com* http://www.crackeasily.com
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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:
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 inject some
html in the URL like this http://domain.com/script/script. When
variable r is written to document using document.write(lc + r + uc) the
script injected gets written into the HTML document. This is a perfect
example of dom based cross site scripting issue. i think GWT has to provide
developers a way to avoid this kind of vulnerabilities.
On Friday, November 9, 2012 1:37:38 AM UTC-5, Anuradha bhat wrote:
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
reverse engineering
r = h(l.location.href)
function h(a) {
return d = 0 ? a.substring(0, d + 1) : M
r = h(l.location.href)
if (y()) {
document.write(lc + r + uc)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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. Have you fixed this in the later version ? If yes then which one ? There's been a few security fixes in latest versions (though not related to this one). AFAICT, assuming this is from computeBaseUrl(), this code will almost never be called (it depends how you load the nocache.js), so there should be no vulnerability in practice. It'd help if you could give more info as to which code exactly you're talking about (compile with -style PRETTY so the JS won't be obfuscated). -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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/script/script. When
variable r is written to document using document.write(lc + r + uc) the
script injected gets written into the HTML document. This is a perfect
example of dom based cross site scripting issue. i think GWT has to provide
developers a way to avoid this kind of vulnerabilities.
On Friday, November 9, 2012 1:37:38 AM UTC-5, Anuradha bhat wrote:
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
reverse engineering
r = h(l.location.href)
function h(a) {
return d = 0 ? a.substring(0, d + 1) : M
r = h(l.location.href)
if (y()) {
document.write(lc + r + uc)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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. 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 case due to the
// document.write call.
if (!thisScript) {
// Put in a marker script element which should be the first script tag
after
// the tag we're looking for. To find it, we start at the marker and walk
// backwards until we find a script.
var markerId = __gwt_marker___MODULE_NAME__;
var markerScript;
$doc.write('script id=' + markerId + '/script');
markerScript = $doc.getElementById(markerId);
thisScript = markerScript markerScript.previousSibling;
while (thisScript thisScript.tagName != 'SCRIPT') {
thisScript = thisScript.previousSibling;
}
}
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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 inject some
html in the URL like this http://domain.com/script/script. When
variable r is written to document using document.write(lc + r + uc) the
script injected gets written into the HTML document. This is a perfect
example of dom based cross site scripting issue. i think GWT has to provide
developers a way to avoid this kind of vulnerabilities.
On Friday, November 9, 2012 1:37:38 AM UTC-5, Anuradha bhat wrote:
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
reverse engineering
r = h(l.location.href)
function h(a) {
return d = 0 ? a.substring(0, d + 1) : M
r = h(l.location.href)
if (y()) {
document.write(lc + r + uc)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Security in gwt application.
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 SafeHtml functions and let GWT autoescape via element.setInnerText() rather than element.setInnerHTML(), you should be safe. Sincerely, Joseph -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/a36SSbOQAlAJ. 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.
Re: Security in gwt application.
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 anuradhalnb...@gmail.comwrote:
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
reverse engineering
r = h(l.location.href)
function h(a) {
return d = 0 ? a.substring(0, d + 1) : M
r = h(l.location.href)
if (y()) {
document.write(lc + r + uc)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/CX2-nuHcMr0J.
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.
--
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.
Re: Security in gwt application.
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 case due to the
// document.write call.
if (!thisScript) {
// Put in a marker script element which should be the first script tag after
// the tag we're looking for. To find it, we start at the marker and walk
// backwards until we find a script.
var markerId = __gwt_marker___MODULE_NAME__;
var markerScript;
$doc.write('script id=' + markerId + '/script');
markerScript = $doc.getElementById(markerId);
thisScript = markerScript markerScript.previousSibling;
while (thisScript thisScript.tagName != 'SCRIPT') {
thisScript = thisScript.previousSibling;
}
}
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/xMGMfQPgRFoJ.
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.
