ZK - Open Source Ajax Java Framework

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4506978

By: fredjeansun

Is there protection built into the framework to guard against Cross-Site Scripting
(XSS) or Cross-Site Request Forgery (CSRF)? If not, what would be the best approach to add protections against those within ZK?

Fred

Dear Mr. Admin. I saw that ZK claims to be a framework with:
- anti-XSS and anti-DoS protection
- Anti-Malicious JavaScript/SQL Injection
These points can be seen in "RIA/AJAX Framework Evaluation Checklist". Could anyone from ZK explains how these security threats are addressed by ZK framework?

Thank you in advance.

Hello Jumin,

To answer your questions:

Anti-XSS and Anti-malicious JavaScript/SQL Injection protection are provided by our server-centric architecture. In addition to this we have added extra protection to prevent custom JavaScript from activating invisible or disabled components.

With regard to anti-DOS protection we have put in place two mechanisms to prevent a user overloading the server with many requests. By setting the two options “max-desktops-per-session” and “max-requests-per-session” you can limit the number of desktops and requests per session. This will prevent your web server succumbing to a DoS attack. However, please note that targeted DoS attacks from multiple IPs are better handled by the web host.

We put a great amount of emphasis on security and this is reflected by our excellent reputation among security companies. One such example is InfoCert, who deemed a ZK application to be the most secure in the entire company.

Hi tmillsclare,

Can you guide how we can test it within our ZK application? Does ZK throws any exception when such condition is encountered?

Hey j4jpp,

What would you like to test?

Hi tmillsclare,

As you have mentioned that 'Anti-XSS and Anti-malicious JavaScript/SQL Injection protection are provided by our server-centric architecture', I wanted to test all these features. If you can provide some example code then it would be great. e.g. On a textbox of a screen if I enter some SQL input that can turn into a 'SQL Injection' attack. So, wanted to know how ZK will behave in this case. Will ZK throw some exception saying that 'SQL Injection detected' or something else will happen?

What you input through textbox will be treated as pure string.
It won't execute sql unless you told it so.

Hi PeterKuo,

I understand your point. For the queries posted by jumin above, tmillsclare has replied that required protection is provided by the server-centric architecture. So, I wanted to know & understand how we can test/check these inbuilt protections. From these we can understand what kind of protection is already provided by ZK. If you can guide something on these then it will be helpful.

Bumping this thread. Are there any details about how the "server-centric" architecture protects applications against xss or csrf? Without any details, we have to assume that there aren't any precautions in place.

AFAIK ZK (3.6) is not well protected against CSRF. When I have a disabled or readonly textbox, then the user can very easily change the attributes of the "input" in the browser and change the value on the server side, too. IMHO the server implementation of the InputElement should check if the server has set disabled/readonly property, and if so, prevent the changing the value and log some warning or error. Also, the band/combo box should be strengthened by the similar way against opening the band/combo popup when the band/combo box is disabled/readonly.

Hi all,

Thanks xmedeko for pointing this out. In ZK 5 there is a way to specify a blocking mechanism for this kind of issue, see Security Tips.
If you have a security concern, it is recommended to use ZK 5.

Regards,
Simon

Hmm, it's pity this feature is ZK 5 EE only, I would consider such a feature as a default behaviour.

Ahh, I think this wasn't stated clearly in the doc. The class InaccessibleWidgetBlockService only comes with EE version, but the entire mechanism works for all ZK 5 versions. You just need to implement your own org.zkoss.zk.au.AuService.

Simon

I understand this, but I would consider something like "InaccessibleWidgetBlockService" is implemented and switched on by default for ZK 3 CE and ZK 5 CE, so inexperienced ZK novice should not care about it. Then, only experienced users could switch it off or change it. IMHO such behaviour would more fit to the ZK philosophy "zero code". And you could boast to the world: "ZK has a CSRF protection build in!".

At least, it's not a good thing that you hide such an important feature somewhere in wiki. You should highlight it in the main product overview http://www.zkoss.org/product/. Something like "You may switch on CSRF protection in ZK EE only, but it is switched off by default".

@Simon: Is there any reason, why ZK 5 uses AuService for CSRF protection and not EventInterceptor.beforeProcessEvent() ? Thx.

Here is the source code of InaccessibleWidgetBlockService class, as an example for people who want to implement:

public class InaccessibleWidgetBlockService implements AuService, java.io.Serializable {
	public boolean service(AuRequest request, boolean everError) {
		final Component comp = request.getComponent();
		return comp != null && (!Components.isRealVisible(comp) ||
			(comp instanceof Disable && ((Disable)comp).isDisabled())); //block if invisible or disabled
	}
}

@xmedeko, thanks for you suggestion. We think it really makes your point, and we will take that into consideration.
For the question about using EventInterceptor, there are two reasons:

1. AuService is the first line of defense, which covers not only Events but also AU updates. To block the latter, it's better to check at AuService.
2. Users may define their own Events, depending on their application, which may be incorrectly trapped if we look at the Event layer.

Thanks,
Simon

I have created a very basic event filter for ZK 3.6 to tackle this CSRF issue, see http://sites.google.com/site/xmedeko/code/zk-web-framework/zk-3-6-csrf-protection

Do the CKEditor/FCKEditor component implementations attempt to block XSS by default, or do they or the underlying JSON services allow the user to include scripts?