This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Hardening Site Security – Enable ClickJacking Protection
In layman terms, ClickJacking or Framesniffing is when a malicious site includes your store using an IFRAME. Attackers trick shoppers into thinking that they are in your domain, and using overlays they are able to change the appearance of the store and steal customer data.
There are multiple techniques to protect against ClickJacking. The OWASP Clickjacking Defense Cheat Sheet describes the most popular ones. Next I discuss the use of the X-Frame-Options response header.
Content Security Policy
The Content Security Policy (CSP) directives replace X-Frame-Options. CSP policies are comprehensive and help you protect against ClickJacking and XSS attacks,
Header always set Content-Security-Policy frame-ancestors 'none'
Enabling the X-Frame-Options header
The X-Frame-Options header can be included with the response either using the IBM HTTP Server (IHS), or within the Commerce application.
Header always append X-Frame-Options SAMEORIGIN
See the IHS documentation for details: mod_headers.
Testing for the header
Testing is straightforward. Use a browser plug-in such as Firefox's Firebug to display the response headers:
<html> <body> <iframe src="http://mystore.com/webapp/wcs/stores/servlet/en/aurora" height="500" width="500"></iframe> </body> </html>
If X-Frame-Options prevents the displaying of the IFRAME, the browser will show an empty fragment and the browser's console will include an informational message such as:
Refused to display 'http://www.mysite.com/webapp/wcs/stores/servlet/en/aurora' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Enabling this setting will help you with the ever more complex security challenges. Just ensure the setting is not too restrictive and breaks a valid business scenario.