Reverse Ajax, Problem with blocking by antiviruses,(Avast, Kerio, NOD..)

[libor]

Hi all,

I use dwr Reverse ajax, and most of antiviruses blocks reverse connection. The only way is to ask users to setup their web shield protection in their antivirus. I wrote to AVAST company and asked them for help. They told me, that thay are not able to analyze response header, because there is no information saying that it is long-term connection.

My response header is this:

Content-Type text/javascript; charset=ISO-8859-1
Transfer-Encoding chunked
Server Jetty(6.1.3)

They told me, that web shield can recognise lightstreamer server according its response header.

LightStreamer header is:

Date Mon, 1 Dec 2008 16:43:17 GMT
Server Lightstreamer/3.5 build 1426 (Lightstreamer Push Server - www.lightstreamer.com) Vivace edition
Content-Type text/html; charset=iso-8859-1
Cache-Control no-store, no-cache
Pragma no-cache
Expires Thu, 1 Jan 1970 00:00:00 GMT
Content-Length 1782
Connection Keep-Alive

So my question is, how can i setup response header of DWR reverse ajax response (ReverseAjax.dwr) ?

And other question is.. Can i setup anything from this header? Because if i can, they will code for me, and globally for all dwr Users exception in their web filter. They told me, that if i can send something like Server: COMET-AJAX jetty(6.1.3) they will add it to the exceptions.

Thanks a lot..

please try to help me, and find a way how to setup it, it will bring solution for all of us, who has problem with avast.


Libor

[Joe Walker-3]

I think that "Transfer-Encoding:chunked" is a massive clue that we're doing comet.
Chunked mode is the part of the HTTP spec that allows us to do this:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

Whilst it's tempting to have the proxy manufacturers of the world constantly on the lookout for DWR by name, I suspect they don't need to. ;-)

If the AVAST people want to contact us on the list, they're very welcome.

Joe.

On Mon, Dec 1, 2008 at 5:28 PM, libor <liborhavlicek%2Bdwrforum@...> wrote:

Hi all,

I use dwr Reverse ajax, and most of antiviruses blocks reverse connection.
The only way is to ask users to setup their web shield protection in their
antivirus. I wrote to AVAST company and asked them for help. They told me,
that thay are not able to analyze response header, because there is no
information saying that it is long-term connection.

My response header is this:

Content-Type    text/javascript; charset=ISO-8859-1
Transfer-Encoding       chunked
Server  Jetty(6.1.3)

They told me, that web shield can recognise lightstreamer server according
its response header.

LightStreamer header is:

Date    Mon, 1 Dec 2008 16:43:17 GMT
Server  Lightstreamer/3.5 build 1426 (Lightstreamer Push Server -
www.lightstreamer.com) Vivace edition
Content-Type    text/html; charset=iso-8859-1
Cache-Control   no-store, no-cache
Pragma  no-cache
Expires Thu, 1 Jan 1970 00:00:00 GMT
Content-Length  1782
Connection      Keep-Alive

So my question is, how can i setup response header of DWR reverse ajax
response (ReverseAjax.dwr) ?

And other question is.. Can i setup anything from this header? Because if i
can, they will code for me, and globally for all dwr Users exception in
their web filter. They told me, that if i can send something like Server:
COMET-AJAX jetty(6.1.3) they will add it to the exceptions.

Thanks a lot..

please try to help me, and find a way how to setup it, it will bring
solution for all of us, who has problem with avast.


Libor



--
View this message in context: http://www.nabble.com/Reverse-Ajax%2C-Problem-with-blocking-by-antiviruses%2C%28Avast%2C-Kerio%2C-NOD..%29-tp20774687p20774687.html
Sent from the DWR - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[libor]

Thanks, for reply Joe.

I have good and bad news. Bad news are, that "Transfer-Encoding:chunked" gives not enought information for avast team, because it only says, that the length of transfered data is unknown at beginning. So it is hudge technical problem to deside if functionality of web depends on if the chunk is received imediatelly or not. They will not accept chunged word as keyword for comet.

Now good news.  They were so kind, that they offered me to detect DWR comet by
"Server: DWR-Reverse-Ajax  ...." if string prefix for Server attribute in response header starts with "DWR-Reverse-Ajax" substring, thay will detect it, and stop blocking reverse ajax.
So for now this is hotfix. The Avast update will be released today.

They told me, thay you DWR team should deside how to describe that this response is COMET. For example by "Content-Type: COMET", and you should add it to next release, so antivirus and firewall companies could recognise it and fixe this problem universally.

So from today, you can use Avast fix, by using for example the Servlet  code below except the old one  DWR servlet.



package server.comunication.dwr;

public class AntivirusSolvedDWRServlet extends org.directwebremoting.servlet.DwrServlet{

        public void doPost (HttpServletRequest request,
                    HttpServletResponse response) throws ServletException, IOException{
       
                updateReverseAjaxInfo(request,response);
                super.doPost(request,response);
               
       
        }

       
        public void doGet (HttpServletRequest request,
                    HttpServletResponse response) throws ServletException, IOException{
                updateReverseAjaxInfo(request,response);
                super.doGet(request,response);
               
        }
       
        void updateReverseAjaxInfo(HttpServletRequest request, HttpServletResponse response){
                if(request.getPathInfo().indexOf("ReverseAjax.dwr")>=0){
                        response.setHeader("Server", "DWR-Reverse-Ajax Jetty(6.1.3)");
                }
        }
}


and you should change in web.xml

from:

<servlet-name>dwr-invoker</servlet-name>
                <servlet-class>
                        org.directwebremoting.servlet.DwrServlet
                </servlet-class>

to:

<servlet-name>dwr-invoker</servlet-name>
                <servlet-class>
                        server.comunication.dwr.AntivirusSolvedDWRServlet
                </servlet-class>


NOTE: Some app servers like Jetty are configurable and you can set them not to send Server attribute in response header. So if this code doesn't add this attribute, just edit /etc/jetty.xml  and  change/insert this row:

<Set name="sendServerVersion">true</Set>



Hope, this helped someone.

If the code postet here is "wird", it can be because of html tags dissmissed.



Anyway, I am solving this problem with Esset too, which is company developing NOD antivirus, so I hope I will bring solution for NOD too.

 

Joe Walker-3 wrote:

I think that "Transfer-Encoding:chunked" is a massive clue that we're doing
comet.
Chunked mode is the part of the HTTP spec that allows us to do this:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

Whilst it's tempting to have the proxy manufacturers of the world constantly
on the lookout for DWR by name, I suspect they don't need to. ;-)

If the AVAST people want to contact us on the list, they're very welcome.

Joe.


On Mon, Dec 1, 2008 at 5:28 PM, libor
<[e-mail]<[e-mail]>
> wrote:

>
> Hi all,
>
> I use dwr Reverse ajax, and most of antiviruses blocks reverse connection.
> The only way is to ask users to setup their web shield protection in their
> antivirus. I wrote to AVAST company and asked them for help. They told me,
> that thay are not able to analyze response header, because there is no
> information saying that it is long-term connection.
>
> My response header is this:
>
> Content-Type    text/javascript; charset=ISO-8859-1
> Transfer-Encoding       chunked
> Server  Jetty(6.1.3)
>
> They told me, that web shield can recognise lightstreamer server according
> its response header.
>
> LightStreamer header is:
>
> Date    Mon, 1 Dec 2008 16:43:17 GMT
> Server  Lightstreamer/3.5 build 1426 (Lightstreamer Push Server -
> www.lightstreamer.com) Vivace edition
> Content-Type    text/html; charset=iso-8859-1
> Cache-Control   no-store, no-cache
> Pragma  no-cache
> Expires Thu, 1 Jan 1970 00:00:00 GMT
> Content-Length  1782
> Connection      Keep-Alive
>
> So my question is, how can i setup response header of DWR reverse ajax
> response (ReverseAjax.dwr) ?
>
> And other question is.. Can i setup anything from this header? Because if i
> can, they will code for me, and globally for all dwr Users exception in
> their web filter. They told me, that if i can send something like Server:
> COMET-AJAX jetty(6.1.3) they will add it to the exceptions.
>
> Thanks a lot..
>
> please try to help me, and find a way how to setup it, it will bring
> solution for all of us, who has problem with avast.
>
>
> Libor
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Reverse-Ajax%2C-Problem-with-blocking-by-antiviruses%2C%28Avast%2C-Kerio%2C-NOD..%29-tp20774687p20774687.html
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Joe Walker-3]

It would be really helpful if someone from the AVAST team could comment here - it would probably save a lot of ping-pong.

On Tue, Dec 2, 2008 at 12:02 PM, libor <liborhavlicek%2Bdwrforum@...> wrote:

Thanks, for reply Joe.

I have good and bad news. Bad news are, that "Transfer-Encoding:chunked"
gives not enought information for avast team, because it only says, that the
length of transfered data is unknown at beginning.

I have to say, I think this is being done the wrong way around.
Surely it would be better to assume that chunked mode meant drip-feed, and the special case things like compression (which are easy to detect) rather than to assume chunked mode didn't exist (which it clearly does) and special case a growing set of services that are hard to detect. Today it's Lightstreamer, DWR, Google, Facebook, Jetty, Perbal, etc, etc, etc but I expect the list will grow.
 

So it is hudge technical
problem to deside if functionality of web depends on if the chunk is
received imediatelly or not. They will not accept chunged word as keyword
for comet.

Now good news.  They were so kind, that they offered me to detect DWR comet
by
"Server: DWR-Reverse-Ajax  ...." if string prefix for Server attribute in
response header starts with "DWR-Reverse-Ajax" substring, thay will detect
it, and stop blocking reverse ajax.

So are we saying that AVAST will whitelist anything with this growing list of server names?
Isn't this a huge security hole?

So for now this is hotfix. The Avast update will be released today.

They told me, thay you DWR team should deside how to describe that this
response is COMET. For example by "Content-Type: COMET", and you should add
it to next release, so antivirus and firewall companies could recognise it
and fixe this problem universally.

Except that the content type isn't COMET. COMET isn't event a valid value for the Content-Type header. Our content type is text/javascript.
Changing this would break the security of systems that are examining DWR content.
I took a look to see what Google was doing, and found this header:

X-Content-Type-Options: nosniff

If this *requires* a header, then I'd be far happier if the header was something like this that was not subverting the meaning of something else.

Joe.

[mikewse]

Joe wrote:

It would be really helpful if someone from the AVAST team could comment here - it would probably save a lot of ping-pong. 

I agree totally. It is very hard to make suggestions for a protection scheme when we don't know what we are trying to protect from. Spontaneously, I don't see why the firewall needs to protect us from long-term http connections. Or rather, I don't see how we could create an exception scheme that couldn't be mimiced by attackers.

On Tue, Dec 2, 2008 at 12:02 PM, libor <liborhavlicek%2Bdwrforum@...> wrote:

Thanks, for reply Joe.

I have good and bad news. Bad news are, that "Transfer-Encoding:chunked"
gives not enought information for avast team, because it only says, that the
length of transfered data is unknown at beginning.

I have to say, I think this is being done the wrong way around.
Surely it would be better to assume that chunked mode meant drip-feed, and the special case things like compression (which are easy to detect) rather than to assume chunked mode didn't exist (which it clearly does) and special case a growing set of services that are hard to detect. Today it's Lightstreamer, DWR, Google, Facebook, Jetty, Perbal, etc, etc, etc but I expect the list will grow. 

I agree with Joe here. Chunked encoding has very well defined semantics: it will send its data in chunks each prefixed with a byte length and the connection is considered open/active until there is a byte length of zero returned to the client. I can't see on what grounds the firewall should intervene and prematurely abort this scheme based on another server header.

The suggested fix would probably have a short lifetime anyway as it can so easily be copied by attackers' servers. With the current information at hand I don't think there is much use customizing DWR to implement the header fix.

 

Best regards

Mike Wilson

Hi,

I'm playing around with DWR, and noticed that if I don't declare a converter for the return type of a remoted method, exceptions like this happen:

2009-02-20 19:35:53,051 [http-80-1] WARN  org.directwebremoting.dwrp.BaseCallMarshaller - --Erroring: batchId[1] message[java.lang.IllegalArgumentException: Missing method or missing parameter converters]

However for a method like:

public ITypedObject readTypedObject()
{
return instanceOfITypedObject;
}

If I run readTypedObject() without declaring a converter for ITypedObject, the instanceOfITypedObject is still returned to the callback handler of readTypedObject(),
it's just that the exception is also propagated to the browser, so I get an error alert.

So DWR wants me to declare a converter for ITypedObject, although it still gets the job done without it.

It seems like DWR would be simpler to work with if I did not have to declare the ITypedObject converter.  So I'm just wondering whether it's something that has been considered?

Cheers,
- Ole

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Walker]

The DWR promise is "we won't let the Internet touch your code without your permission". Whilst we could do all sorts of things automatically, we prefer to keep to a simple promise like that to keep things safe.

Joe.

On Sat, Feb 21, 2009 at 1:49 AM, Ole Ersoy <ole.ersoy@...> wrote:

Hi,

I'm playing around with DWR, and noticed that if I don't declare a converter for the return type of a remoted method, exceptions like this happen:

2009-02-20 19:35:53,051 [http-80-1] WARN  org.directwebremoting.dwrp.BaseCallMarshaller - --Erroring: batchId[1] message[java.lang.IllegalArgumentException: Missing method or missing parameter converters]

However for a method like:

public ITypedObject readTypedObject()
{
return instanceOfITypedObject;
}

If I run readTypedObject() without declaring a converter for ITypedObject, the instanceOfITypedObject is still returned to the callback handler of readTypedObject(),
it's just that the exception is also propagated to the browser, so I get an error alert.

So DWR wants me to declare a converter for ITypedObject, although it still gets the job done without it.

It seems like DWR would be simpler to work with if I did not have to declare the ITypedObject converter.  So I'm just wondering whether it's something that has been considered?

Cheers,
- Ole

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...