About DWR's JavaScript Security

There are 3 basic ways to protect any service that returns JSON or JavaScript against the <script> tag hack.

Use a Secret in the Request

If you can only support one of these protections, this is the one to chose. Including a secret in the request allows the server to reject the request as invalid before any actions take place. It is common to include the secret in the URL, however this is a slightly vulnerable position for a secret since it is likely to turn up in web server log files and so on.

DWR uses a secret in the POST body to allow the server to deny forged requests. (This secret is randomly generated by an algorithm on the server, and the algorithm is pluggable ). The secret in the POST body is compared with a cookie in the request, and if they don't match the request is rejected as a potential CSRF attack. Security comes from a CSRF attackers inability to assign this cookie. You can turn this protection off (to allow cross-domain requests for public data) by setting the crossDomainSessionSecurity=false init-param in web.xml.

Force pre-eval() Processing

Since <script> tag remoting does not allow you to process the JSON or JavaScript before it is eval()ed you can protect your JSON by forcing it to be manipulated before it is eval()ed. There are 3 ways to do this:

Force POST Requests

Since browsers use GET to process <script> tags, you can prevent <script> tags from working by denying GET requests for some JavaScript resource. This is the most common solution, however it is also perhaps the weakest.

Firstly XHR-POST doesn't work with older versions of Safari, so some support for GET is often useful.

More importantly future versions of Firefox are touted to include cross-domain XHR support. While we don't have exact knowledge of how this will happen, it would be foolish to base your security plans on this technique holding up.

Finally, we're working in an environment where new possibilities are popping up every day - betting your security on a system that works more by fluke than design isn't a great idea in my opinion.

By default DWR denies GET requests for belt and braces security, however this is customizable using the allowGetForSafariButMakeForgeryEasier=true init-param in web.xml.