dwr 501 errors with debug set to false

[gebuh]

I've inherited an application that is deployed on JBoss 5.1, fronted by Apache 2.2.  It uses DWR, I have zero experience with it.  I'm not sure what version, though the MANIFEST.MF in the dwr.jar says 1.5.0_13-119.
We have a directory in the app war called dwr, it contains some .js files.  We have a dwr.xml for configuration.  In our webapp web.xml I have debug set to false.  
When are application is scanned for security purposes the dwr directory returns 501 errors.  If I attempt to access the directory via url:
http://myApp/dwr
The url changes to
http://myApp/dwr/index.html 
a 501 error page is generated.= and I get a:
 Failed attempt to access test pages outside of debug mode. Set the debug init-parameter to true to enable.
message in my jboss server log.
If I try
http://myApp/dwr/engine.js 
Or one of the actual pages in this directory, it downloads the javascript.
Users shouldn't be able to discover the dwr directory (any other directory in my app war returns a 404 error) and they certainly shouldn't be able to download the javascript.
Is there a way to configure dwr to do this?   If I lockdown the directory through jboss or apache will that break dwr?

Inside the dwr.jar there is a version property file, you should be able to find the version there.

"Users shouldn't be able to discover the dwr directory (any other directory in my app war returns a 404 error)"

dwr is not a directory.  /dwr should be mapped to the dwr servlet.

"and they certainly shouldn't be able to download the javascript."
If a user can't download the DWR JavaScript files than how do you expect to use DWR?





On 12/12/2011 03:54 PM, gebuh wrote:
> Users shouldn't be able to discover the dwr directory (any other directory
> in my app war returns a 404 error) and they certainly shouldn't be able to
> download the javascript.

[gebuh]

Thanx for the reply.
dwr version is 2.0.5
The war structure is:
myApp.war
  -admin
  -css
  -dwr
        -interface
             -someMenu.js
        -engine.js
        -util.js
   -WEB-INF
       -classes
       -lib
              -dwr.jar

So dwr/ is a directory in the war.

Users accessing javascript files could be something I can control elsewhere, but I didn't think a user could just type in the url ending with a javascript file and have direct access to that file, that can't be done in the other app I deploy to the same server.
     

[e-mail] wrote

Inside the dwr.jar there is a version property file, you should be able to find the version there.

"Users shouldn't be able to discover the dwr directory (any other directory in my app war returns a 404 error)"

dwr is not a directory.  /dwr should be mapped to the dwr servlet.

"and they certainly shouldn't be able to download the javascript."
If a user can't download the DWR JavaScript files than how do you expect to use DWR?





On 12/12/2011 03:54 PM, gebuh wrote:
> Users shouldn't be able to discover the dwr directory (any other directory
> in my app war returns a 404 error) and they certainly shouldn't be able to
> download the javascript.

JavaScript (in this case) is executed on the client in the browser.  If a user can't access the file than the JavaScript obviously can't run and would serve no purpose.  The JavaScript has to have a way to make it to the client so what you are saying makes no sense to me. 

It looks like the user has saved off the JS files normally generated by DWR into a directory.  This is not standard.  The fact that these files are accessible has nothing to do with DWR.

On Tue, Dec 13, 2011 at 7:23 AM, gebuh <[hidden email]> wrote:

Thanx for the reply.
dwr version is 2.0.5
The war structure is:
myApp.war
 -admin
 -css
 -dwr
       -interface
            -someMenu.js
       -engine.js
       -util.js
  -WEB-INF
      -classes
      -lib
             -dwr.jar

So dwr/ is a directory in the war.

Users accessing javascript files could be something I can control elsewhere,
but I didn't think a user could just type in the url ending with a
javascript file and have direct access to that file, that can't be done in
the other app I deploy to the same server.


[hidden email] wrote
>
> Inside the dwr.jar there is a version property file, you should be able to
> find the version there.
>
> "Users shouldn't be able to discover the dwr directory (any other
> directory in my app war returns a 404 error)"
>
> dwr is not a directory.  /dwr should be mapped to the dwr servlet.
>
> "and they certainly shouldn't be able to download the javascript."
> If a user can't download the DWR JavaScript files than how do you expect
> to use DWR?
>
>
>
>
>
> On 12/12/2011 03:54 PM, gebuh wrote:
>> Users shouldn't be able to discover the dwr directory (any other
>> directory
>> in my app war returns a 404 error) and they certainly shouldn't be able
>> to
>> download the javascript.
>


--
View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090089.html
Sent from the DWR - Users mailing list archive at Nabble.com.

[Randy Jones]

I would suspect that the user is never actually able to get to those files as your web.xml likely has an entry to map /dwr to the DWR servlet. I agree with David that that it makes no sense about accessing javascript files. In your other application are you restricting access to javascript files based on referrer maybe? That’s the only thing that makes even a little sense to me with restricting access to javascript.

 

Randy

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of David Marginian
Sent: Tuesday, December 13, 2011 9:39 AM
To: [hidden email]
Subject: [dwr-users] Re: dwr 501 errors with debug set to false

 

JavaScript (in this case) is executed on the client in the browser.  If a user can't access the file than the JavaScript obviously can't run and would serve no purpose.  The JavaScript has to have a way to make it to the client so what you are saying makes no sense to me. 

It looks like the user has saved off the JS files normally generated by DWR into a directory.  This is not standard.  The fact that these files are accessible has nothing to do with DWR.

On Tue, Dec 13, 2011 at 7:23 AM, gebuh <[hidden email]> wrote:

Thanx for the reply.
dwr version is 2.0.5
The war structure is:
myApp.war
 -admin
 -css
 -dwr
       -interface
            -someMenu.js
       -engine.js
       -util.js
  -WEB-INF
      -classes
      -lib
             -dwr.jar

So dwr/ is a directory in the war.

Users accessing javascript files could be something I can control elsewhere,
but I didn't think a user could just type in the url ending with a
javascript file and have direct access to that file, that can't be done in
the other app I deploy to the same server.


[hidden email] wrote

>
> Inside the dwr.jar there is a version property file, you should be able to
> find the version there.
>
> "Users shouldn't be able to discover the dwr directory (any other
> directory in my app war returns a 404 error)"
>
> dwr is not a directory.  /dwr should be mapped to the dwr servlet.
>
> "and they certainly shouldn't be able to download the javascript."
> If a user can't download the DWR JavaScript files than how do you expect
> to use DWR?
>
>
>
>
>
> On 12/12/2011 03:54 PM, gebuh wrote:
>> Users shouldn't be able to discover the dwr directory (any other
>> directory
>> in my app war returns a 404 error) and they certainly shouldn't be able
>> to
>> download the javascript.
>

--
View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090089.html
Sent from the DWR - Users mailing list archive at Nabble.com.

 

[gebuh]

It's entirely possible I'm making no sense, javascript is not my area, I'm just comparing it to another application.
You were right about the directory, the engine.js and util.js are duplicates of files in the dwr.jar.  I moved the function in the dwr/interface directory to another .js file and deleted the dwr directory.  The application still works, but I still have the same problem.  
If a user enters http://myapp/dwr -(a resource they shouldn't have access to) a 501 error is generated and I get:

[DefaultDebugPageGenerator] Failed attempt to access test pages outside of debug mode. Set the debug init-parameter to true to enable.
[ExceptionHandler] Unhandled Exception
java.lang.SecurityException: Access to debug pages is denied.

In my server log.
It should generate a 404 error - resource not available or does not exist.
The dwr.xml has a couple of converters:
<convert match="501" converter="exception">
       
    </convert>   
     <convert match="java.lang.Exception" converter="exception">
       
    </convert>

But I get the same results whether I edit them or comment them out.

[e-mail] wrote

JavaScript (in this case) is executed on the client in the browser.  If a
user can't access the file than the JavaScript obviously can't run and
would serve no purpose.  The JavaScript has to have a way to make it to the
client so what you are saying makes no sense to me.

It looks like the user has saved off the JS files normally generated by DWR
into a directory.  This is not standard.  The fact that these files are
accessible has nothing to do with DWR.

On Tue, Dec 13, 2011 at 7:23 AM, gebuh <[hidden email]> wrote:

> Thanx for the reply.
> dwr version is 2.0.5
> The war structure is:
> myApp.war
>  -admin
>  -css
>  -dwr
>        -interface
>             -someMenu.js
>        -engine.js
>        -util.js
>   -WEB-INF
>       -classes
>       -lib
>              -dwr.jar
>
> So dwr/ is a directory in the war.
>
> Users accessing javascript files could be something I can control
> elsewhere,
> but I didn't think a user could just type in the url ending with a
> javascript file and have direct access to that file, that can't be done in
> the other app I deploy to the same server.
>
>
> [hidden email] wrote
> >
> > Inside the dwr.jar there is a version property file, you should be able
> to
> > find the version there.
> >
> > "Users shouldn't be able to discover the dwr directory (any other
> > directory in my app war returns a 404 error)"
> >
> > dwr is not a directory.  /dwr should be mapped to the dwr servlet.
> >
> > "and they certainly shouldn't be able to download the javascript."
> > If a user can't download the DWR JavaScript files than how do you expect
> > to use DWR?
> >
> >
> >
> >
> >
> > On 12/12/2011 03:54 PM, gebuh wrote:
> >> Users shouldn't be able to discover the dwr directory (any other
> >> directory
> >> in my app war returns a 404 error) and they certainly shouldn't be able
> >> to
> >> download the javascript.
> >
>
>
> --
> View this message in context:
> http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090089.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>

No, it should not generate a 404.  Look in your web.xml.  /dwr should be mapped to the DWR servlet.  So that path does exist and you should NOT be getting a 404. 

On Tue, Dec 13, 2011 at 8:48 AM, gebuh <[hidden email]> wrote:

It's entirely possible I'm making no sense, javascript is not my area, I'm
just comparing it to another application.
You were right about the directory, the engine.js and util.js are duplicates
of files in the dwr.jar.  I moved the function in the dwr/interface
directory to another .js file and deleted the dwr directory.  The
application still works, but I still have the same problem.
If a user enters http://myapp/dwr -(a resource they shouldn't have access
to) a 501 error is generated and I get:
[DefaultDebugPageGenerator] Failed attempt to access test pages outside of
debug mode. Set the debug init-parameter to true to enable.
[ExceptionHandler] Unhandled Exception
java.lang.SecurityException: Access to debug pages is denied.

In my server log.
It should generate a 404 error - resource not available or does not exist.
The dwr.xml has a couple of converters:
<convert match="501" converter="exception">

   </convert>
    <convert match="java.lang.Exception" converter="exception">

   </convert>

But I get the same results whether I edit them or comment them out.


[hidden email] wrote

>
> JavaScript (in this case) is executed on the client in the browser.  If a
> user can't access the file than the JavaScript obviously can't run and
> would serve no purpose.  The JavaScript has to have a way to make it to
> the
> client so what you are saying makes no sense to me.
>
> It looks like the user has saved off the JS files normally generated by
> DWR
> into a directory.  This is not standard.  The fact that these files are
> accessible has nothing to do with DWR.
>

> On Tue, Dec 13, 2011 at 7:23 AM, gebuh &lt;gebuh@&gt; wrote:
>
>> Thanx for the reply.
>> dwr version is 2.0.5
>> The war structure is:
>> myApp.war
>>  -admin
>>  -css
>>  -dwr
>>        -interface
>>             -someMenu.js
>>        -engine.js
>>        -util.js
>>   -WEB-INF
>>       -classes
>>       -lib
>>              -dwr.jar
>>
>> So dwr/ is a directory in the war.
>>
>> Users accessing javascript files could be something I can control
>> elsewhere,
>> but I didn't think a user could just type in the url ending with a
>> javascript file and have direct access to that file, that can't be done
>> in
>> the other app I deploy to the same server.
>>
>>

>> david@ wrote

>> >
>> > Inside the dwr.jar there is a version property file, you should be able
>> to
>> > find the version there.
>> >
>> > "Users shouldn't be able to discover the dwr directory (any other
>> > directory in my app war returns a 404 error)"
>> >
>> > dwr is not a directory.  /dwr should be mapped to the dwr servlet.
>> >
>> > "and they certainly shouldn't be able to download the javascript."
>> > If a user can't download the DWR JavaScript files than how do you
>> expect
>> > to use DWR?
>> >
>> >
>> >
>> >
>> >
>> > On 12/12/2011 03:54 PM, gebuh wrote:
>> >> Users shouldn't be able to discover the dwr directory (any other
>> >> directory
>> >> in my app war returns a 404 error) and they certainly shouldn't be
>> able
>> >> to
>> >> download the javascript.
>> >
>>
>>
>> --
>> View this message in context:
>> http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090089.html
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>


--

View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090380.html

Sent from the DWR - Users mailing list archive at Nabble.com.

[Amon, Tod T]

Gebuh,

 

It might help to take a step back and think about what DWR lets you do, from a user’s perspective.  In essence, the user’s browser is able to execute Javascript which can invoke methods on your server via DWR.  I think of this as service oriented architecture at the application level.  Those methods on the server *are* exposed for authorized clients… in a sense, one’s attitude becomes that an authorized user, should they have the desire, could probably refactor the user interface into some other interface of their choosing, while still relying on the exposed methods.  That’s my perspective anyway, perhaps David or Mike can let me know if I’m wrong! 

 

-Tod

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of David Marginian
Sent: Tuesday, December 13, 2011 9:00 AM
To: [hidden email]
Subject: [EXTERNAL] [dwr-users] Re: dwr 501 errors with debug set to false

 

No, it should not generate a 404.  Look in your web.xml.  /dwr should be mapped to the DWR servlet.  So that path does exist and you should NOT be getting a 404. 

On Tue, Dec 13, 2011 at 8:48 AM, gebuh <[hidden email]> wrote:

It's entirely possible I'm making no sense, javascript is not my area, I'm
just comparing it to another application.
You were right about the directory, the engine.js and util.js are duplicates
of files in the dwr.jar.  I moved the function in the dwr/interface
directory to another .js file and deleted the dwr directory.  The
application still works, but I still have the same problem.
If a user enters http://myapp/dwr -(a resource they shouldn't have access
to) a 501 error is generated and I get:
[DefaultDebugPageGenerator] Failed attempt to access test pages outside of
debug mode. Set the debug init-parameter to true to enable.
[ExceptionHandler] Unhandled Exception
java.lang.SecurityException: Access to debug pages is denied.

In my server log.
It should generate a 404 error - resource not available or does not exist.
The dwr.xml has a couple of converters:
<convert match="501" converter="exception">

   </convert>
    <convert match="java.lang.Exception" converter="exception">

   </convert>

But I get the same results whether I edit them or comment them out.


[hidden email] wrote

>
> JavaScript (in this case) is executed on the client in the browser.  If a
> user can't access the file than the JavaScript obviously can't run and
> would serve no purpose.  The JavaScript has to have a way to make it to
> the
> client so what you are saying makes no sense to me.
>
> It looks like the user has saved off the JS files normally generated by
> DWR
> into a directory.  This is not standard.  The fact that these files are
> accessible has nothing to do with DWR.
>

> On Tue, Dec 13, 2011 at 7:23 AM, gebuh &lt;gebuh@&gt; wrote:
>
>> Thanx for the reply.
>> dwr version is 2.0.5
>> The war structure is:
>> myApp.war
>>  -admin
>>  -css
>>  -dwr
>>        -interface
>>             -someMenu.js
>>        -engine.js
>>        -util.js
>>   -WEB-INF
>>       -classes
>>       -lib
>>              -dwr.jar
>>
>> So dwr/ is a directory in the war.
>>
>> Users accessing javascript files could be something I can control
>> elsewhere,
>> but I didn't think a user could just type in the url ending with a
>> javascript file and have direct access to that file, that can't be done
>> in
>> the other app I deploy to the same server.
>>
>>

>> david@ wrote

>> >
>> > Inside the dwr.jar there is a version property file, you should be able
>> to
>> > find the version there.
>> >
>> > "Users shouldn't be able to discover the dwr directory (any other
>> > directory in my app war returns a 404 error)"
>> >
>> > dwr is not a directory.  /dwr should be mapped to the dwr servlet.
>> >
>> > "and they certainly shouldn't be able to download the javascript."
>> > If a user can't download the DWR JavaScript files than how do you
>> expect
>> > to use DWR?
>> >
>> >
>> >
>> >
>> >
>> > On 12/12/2011 03:54 PM, gebuh wrote:
>> >> Users shouldn't be able to discover the dwr directory (any other
>> >> directory
>> >> in my app war returns a 404 error) and they certainly shouldn't be
>> able
>> >> to
>> >> download the javascript.
>> >
>>
>>
>> --
>> View this message in context:
>> http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090089.html
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>


--

View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7090380.html

Sent from the DWR - Users mailing list archive at Nabble.com.

 

[gebuh]

yes you are correct, but how do you control what a user sees when they're accessing something they're not supposed to access?  Or even something that actually doesn't exist.
No matter what I use as part of the url, if it contains dwr I end up with a 501 error - so this:
http://myapp/dwr 
and this
http://myapp/dwr/someMadeUpNameThatDoesntEvenExist 
generates the same error.
The 2nd url doesn't even exist, but because it's prepended with dwr it's generating a 501 error.
According to my overlords this is a security flaw, because it lets someone know there's something there to investigate.

Update
figured out a fix.  When someone tries to access dwr directly a java.lang.SecurityException is generated.
in web.xml I funnel this to an errorPage:

 <error-page>
  <exception-type>java.lang.SecurityException</exception-type>
  <location>/pagenotfound.jsp</location>
 </error-page>

 In the error page I set the response to 404:

<%
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
%>

Amon, Tod T wrote

Gebuh,

It might help to take a step back and think about what DWR lets you do, from a user’s perspective.  In essence, the user’s browser is able to execute Javascript which can invoke methods on your server via DWR.  I think of this as service oriented architecture at the application level.  Those methods on the server *are* exposed for authorized clients… in a sense, one’s attitude becomes that an authorized user, should they have the desire, could probably refactor the user interface into some other interface of their choosing, while still relying on the exposed methods.  That’s my perspective anyway, perhaps David or Mike can let me know if I’m wrong!

-Tod

You can secure access to the servlet via standard security measures so that unauthorized users cannot access it.  How you choose to lock down the access to the servlet has nothing to do with DWR. 

"Update figured out a fix.  When someone tries to access dwr directly a java.lang.SecurityException is generated. in web.xml I funnel this to an errorPage:"
I am curious how you are doing this without affecting normal dwr calls (which also hit the /dwr of course).

On Tue, Dec 13, 2011 at 12:27 PM, gebuh <[hidden email]> wrote:

yes you are correct, but how do you control what a user sees when they're
accessing something they're not supposed to access?  Or even something that
actually doesn't exist.
No matter what I use as part of the url, if it contains dwr I end up with a
501 error - so this:
http://myapp/dwr
and this
http://myapp/dwr/someMadeUpNameThatDoesntEvenExist
generates the same error.
The 2nd url doesn't even exist, but because it's prepended with dwr it's
generating a 501 error.
According to my overlords this is a security flaw, because it lets someone
know there's something there to investigate.

Update
figured out a fix.  When someone tries to access dwr directly a
java.lang.SecurityException is generated.
in web.xml I funnel this to an errorPage:
 <error-page>
 <exception-type>java.lang.SecurityException</exception-type>
 <location>/pagenotfound.jsp</location>
 </error-page>

 In the error page I set the response to 404:
<%
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
%>




Amon, Tod T wrote

>
> Gebuh,
>
> It might help to take a step back and think about what DWR lets you do,
> from a user’s perspective.  In essence, the user’s browser is able to
> execute Javascript which can invoke methods on your server via DWR.  I
> think of this as service oriented architecture at the application level.
> Those methods on the server *are* exposed for authorized clients… in a
> sense, one’s attitude becomes that an authorized user, should they have
> the desire, could probably refactor the user interface into some other
> interface of their choosing, while still relying on the exposed methods.
> That’s my perspective anyway, perhaps David or Mike can let me know if I’m
> wrong!
>
> -Tod
>

--
View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091116.html

Sent from the DWR - Users mailing list archive at Nabble.com.

[gebuh]

I'm going to guess that these are not normal dwr calls.  A normal dwr call would probably access a specific resource.  But what's happening is a user is just accessing dwr/
If a user types this in their browser:
http://myapp/dwr
it generates a security exception with the message I posted earlier.

[e-mail] wrote

I am curious how you are doing this without affecting normal dwr calls
(which also hit the /dwr of course).

"A normal dwr call would probably access a specific resource"

A DWR call may look something like this:
/dwr/call/plaincall/Demo.sayHello.dwr

I don't see how you are possibly weeding out what you call invalid requests.  You have likely broken any DWR calls your application may use. 

On Tue, Dec 13, 2011 at 1:25 PM, gebuh <[hidden email]> wrote:

I'm going to guess that these are not normal dwr calls.  A normal dwr call
would probably access a specific resource.  But what's happening is a user
is just accessing dwr/
If a user types this in their browser:
http://myapp/dwr
it generates a security exception with the message I posted earlier.

[hidden email] wrote

>
>
> I am curious how you are doing this without affecting normal dwr calls
> (which also hit the /dwr of course).
>

--
View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091310.html

Sent from the DWR - Users mailing list archive at Nabble.com.

I think it would be in your best interest to read about DWR and learn more about web applications before continuing to change things without completely understanding the consequences.  Downloading the DWR demo or going through the documentation on our site is a good place to start. 

On Tue, Dec 13, 2011 at 1:37 PM, David Marginian <[hidden email]> wrote:

"A normal dwr call would probably access a specific resource"

A DWR call may look something like this:
/dwr/call/plaincall/Demo.sayHello.dwr

I don't see how you are possibly weeding out what you call invalid requests.  You have likely broken any DWR calls your application may use. 

On Tue, Dec 13, 2011 at 1:25 PM, gebuh <[hidden email]> wrote:

I'm going to guess that these are not normal dwr calls.  A normal dwr call
would probably access a specific resource.  But what's happening is a user
is just accessing dwr/
If a user types this in their browser:
http://myapp/dwr
it generates a security exception with the message I posted earlier.

[hidden email] wrote

>
>
> I am curious how you are doing this without affecting normal dwr calls
> (which also hit the /dwr of course).
>

--
View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091310.html

Sent from the DWR - Users mailing list archive at Nabble.com.

[gebuh]

thanx, I will, this probably isn't the last I'll see of this.
This came about from a security webscan.  An application crawls our site looking for vulnerabilities.  It tries to access any folders it finds.  The dwr/ folder was one such folder.
So this is not a DWR call, it is someone typing dwr/ in the address bar.  Not dwr/someValidThing
just dwr/
Before I rerouted the exception to a 404 page, it would generate a stacktrace in the server log and reroute to a 501 page.  

[e-mail] wrote

I think it would be in your best interest to read about DWR and learn more
about web applications before continuing to change things without
completely understanding the consequences.  Downloading the DWR demo or
going through the documentation on our site is a good place to start.


On Tue, Dec 13, 2011 at 1:37 PM, David Marginian <[hidden email]>wrote:

> "A normal dwr call would probably access a specific resource"
>
> A DWR call may look something like this:
> /dwr/call/plaincall/Demo.sayHello.dwr
>
> I don't see how you are possibly weeding out what you call invalid
> requests.  You have likely broken any DWR calls your application may use.
>
>
> On Tue, Dec 13, 2011 at 1:25 PM, gebuh <[hidden email]> wrote:
>
>> I'm going to guess that these are not normal dwr calls.  A normal dwr call
>> would probably access a specific resource.  But what's happening is a user
>> is just accessing dwr/
>> If a user types this in their browser:
>> http://myapp/dwr
>> it generates a security exception with the message I posted earlier.
>>
>> [hidden email] wrote
>> >
>> >
>> > I am curious how you are doing this without affecting normal dwr calls
>> > (which also hit the /dwr of course).
>> >
>>
>>
>> --
>> View this message in context:
>> http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091310.html
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>
>

/dwr is a DWR call because you have a mapping defined in your web.xml
for DWR to handle all /dwr requests.

If DWR is in debug mode (set via an init-param in the web.xml) DWR will
generate a test page when a /dwr or index request comes in.  Because you
are not in debug mode DWR is not allowed to create the index/test page
and a SecurityException is being thrown resulting in the 501 you are
seeing.

Although this is not a major security flaw I do agree that in situations
like this it is best to reveal as little information as possible and
that we can handle this better.  I will look into it and create a Jira
to ensure we address it.  Thanks.

For now I am glad you found a solution.



On 12/13/2011 02:10 PM, gebuh wrote:

> thanx, I will, this probably isn't the last I'll see of this.
> This came about from a security webscan.  An application crawls our site
> looking for vulnerabilities.  It tries to access any folders it finds.  The
> dwr/ folder was one such folder.
> So this is not a DWR call, it is someone typing dwr/ in the address bar.
> Not dwr/someValidThing
> just dwr/
> Before I rerouted the exception to a 404 page, it would generate a
> stacktrace in the server log and reroute to a 501 page.
>
>
> [hidden email] wrote
>> I think it would be in your best interest to read about DWR and learn more
>> about web applications before continuing to change things without
>> completely understanding the consequences.  Downloading the DWR demo or
>> going through the documentation on our site is a good place to start.
>>
>>
>> On Tue, Dec 13, 2011 at 1:37 PM, David Marginian&lt;david@&gt;wrote:
>>
>>> "A normal dwr call would probably access a specific resource"
>>>
>>> A DWR call may look something like this:
>>> /dwr/call/plaincall/Demo.sayHello.dwr
>>>
>>> I don't see how you are possibly weeding out what you call invalid
>>> requests.  You have likely broken any DWR calls your application may use.
>>>
>>>
>>> On Tue, Dec 13, 2011 at 1:25 PM, gebuh&lt;gebuh@&gt; wrote:
>>>
>>>> I'm going to guess that these are not normal dwr calls.  A normal dwr
>>>> call
>>>> would probably access a specific resource.  But what's happening is a
>>>> user
>>>> is just accessing dwr/
>>>> If a user types this in their browser:
>>>> http://myapp/dwr
>>>> it generates a security exception with the message I posted earlier.
>>>>
>>>> david@ wrote
>>>>>
>>>>> I am curious how you are doing this without affecting normal dwr calls
>>>>> (which also hit the /dwr of course).
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091310.html
>>>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>>>
>>>
>
> --
> View this message in context: http://dwr.2114559.n2.nabble.com/dwr-501-errors-with-debug-set-to-false-tp7088099p7091444.html
> Sent from the DWR - Users mailing list archive at Nabble.com.
>