CSSRF Prevention
Overview
From OWASP
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.
So in short, a successful CSRF attack uses a valid http request, but often with malicious data to cause unwanted and unintended results, which assumes a valid identity of end user by using above mentioned browser's way of handling of user related information.
According OWASP mentioned CSRF Limitations, in order to mount a successful CSRF attack several things have to happen
- The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin that allows referer spoofing (which is rare)
This can be avoided by adding a servlet filter that checks if all request referer and origin headers contain the appropriate values.
- The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
By design ZK is an Ajax solution. Because of this design generally no form submit nor specific URL request can cause side effects
- The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
ZK generates unique ids for html elements that represent ZK components on client side and these unique ids are checked on server side when data containing them is passed via ZK's Ajax mechanism. For successful CSRF attack, the attacker will have to guess all unique ids for those html elements while submitting the malicious request. Also note that ZK will regenerate these ids if the components are re-rendered via page refresh or recreated again.
- The attacker must lure the victim to a Web page with malicious code while the victim is logged into the target site.
This is more humane issue and depends on the end user. Application developers should raise the awareness about CSRF by documenting this in their application documentation that end users can refer to.
General recommendation to prevent CSRF is to use Synchronizer Toeken Pattern. Generally this is done by inserting a unique token usually referred as csrf token in the generated html and check it on server side on form submission. "ZK employs similar technique in the form of desktop id." Each url in ZK web application when requested gets associated a Desktop instance. Refer to Desktop and Pages for more details on the concept of Desktop in ZK. When a page is rendered on client side a unique desktop id will also be assigned to the desktop. ZK desktop is discarded and re-created each time a new page is loaded in browser or even the current page is refreshed. On each re-rendering of page a new automatically generated unique id is assigned to desktop as illustrated in below image
Henceforth each user interaction is carried via ZK Ajax mechanism and on each interaction this unique desktop id will be passed as Ajax request POST data.