public interface XssAndCSRFSecurity
<script>alert("Hacked!")</script>then inserting that field value into an HTML document will cause the script to execute.
The way to prevent this kind of attack is
that flag on your fields will ensure that script embedded in field values won't
execute; because it is escaped, the value will be treated as literal text.
A CSRF token is a unique string of text that you generate on the server on session creation, and then expect to be passed as a parameter with all future requests. By storing the CSRF token in the session and comparing it to the passed token parameter, you can be sure that the request came from a source that is privy to the CSRF token, and thus that the request is not forged.
implementing a CSRF token strategy is really easy with Smart GWT, especially if you
are using the Smart GWT server framework. Since all data-related requests go to a
single URL, specified with
can just add your CSRF
token to that URL in your bootstrap file. Alternatively, you could use
add your token, if your authentication system
requires the CSRF token in another part of the request (for example, in an HTTP header).
Using a CSRF token is a highly recommended security practice.
The "hiddenFrame" protocol uses an iframe to load content from the server. If your
document.domain at all, an iframe must have a matching
document.domain setting or it can't contact the main page to report
results. Due to proxying and other commonly-used techniques, there is no reliable way
for the server to know what
document.domain setting must be used.
Therefore, Smart GWT passes the setting to the server with each "hiddenFrame"
request, in a parameter called
isc_dd, and the server echoes that setting
back down to the client.
Domain synchronization opens up the potential for an obscure hybrid XSS/CSRF attack on
a Smart GWT application, where it shares a domain with another, non-Smart GWT
application that is vulnerable to XSS attacks - for example, a Smart GWT app at
payments.example.com and a non-Smart GWT app at
enquiry.example.com. This attack would work by injecting an XSS payload
into the vulnerable, non-Smart GWT app at
injected code would set the domain to "example.com", and then create an iframe that
targets the Smart GWT app at "payments.example.com", passing
"example.com". The return function from that CSRF call would be able to access data
from "payments.example.com", as a result of exploiting an XSS vulnerability in the app
document.domain, there is no need for
domain synchronization, and you can simply switch it off by specifying
domainSync.disabled: true in your
document.domain, you can prevent this
kind of exploit by providing a comma-separated list of valid base domains in
example, the following setting would have prevented the above attack:
baseDomains setting as described above, the system will log a
warning every time it echoes a client-provided domain name in a response.