Re: Security in gwt application.

[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 SafeHtml functions and let GWT autoescape via element.setInnerText() rather than element.setInnerHTML(), you should be safe.

Sincerely,

Joseph

[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 <anuradh...@gmail.com> 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 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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[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 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;
    }
  }

[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 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. 

[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 ?

[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. 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).

[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) {

        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=<script>MALICIOUS_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=<script>MALICIOUS_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.

 

--
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-tool...@googlegroups.com.

To post to this group, send email to google-we...@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

[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 <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)

To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

To post to this group, send email to google-we...@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.