X-Frame-Options

[Nidish93]

Hey , I was testing if the browser supports the X-Frame-Options directive, the HTTP response header can be used to indicate whether or not the browser should be allowed to render a page in a frame, iframe or object. I found out that this method is used to avoid clickjacking attacks by websites. It ensures that their content is not embedded into other potential malicious sites.

However after further investigation I noticed that gngr would not display any results after using this test page. For comparison between other browsers like chrome and firefox, please find in the following link three images labeled with the according names.

After some further testing, I also found out through OWASP ZAP that either gngr's XSS filter is disabled or the X-XSS-Protection HTTP response header allows the web server to enable or disable the browser's XSS protection mechanism. This can be normal or related to something else entirely, I am not sure.

If needed, the web browser's XSS filter can be toggled by defining it's parameters in the following way:
0 - Disables the XSS Protections offered by the user-agent.
1 - Enables the XSS Protections
1; mode=block - Enables XSS protections and instructs the user-agent to block the response in the event that script has been inserted from user input, instead of sanitizing.
1; report=http://site.com/report - This is a Chrome and WebKit only directive that tells the user-agent to report potential XSS attacks to a single URL. Data will be POST'd to the report URL in JSON format. Mentioned it as it can be used to model one for gngr.

[hrj]

@Nidish93 Hi! Thanks for the detailed report!

I noticed that gngr would not display any results after using this test page.

In the case of gngr, there is a layer of control called the Request Manager. More info in this wiki page. On the enhanceie test page, you will notice that the Request Manager shows frames from different domains being blocked. When you make them green, they will show through.

In fact, more frames than required will show through when their respective entries are enabled in Request Manager. This is currently a draw-back in gngr. There needs to be a second level of control, to manage X-Frames, XSS and to enforce same origin policies, through headers such as CORS.

Note that the Request Manager is a layer which is explicitly under user's control. There needs to be a layer in gngr which is controlled by HTTP headers, just as in other browsers.

Contributions to this second level of control are very welcome and I think it would make a good thesis topic! If you want to take this up, it would be good to first survey all the relevant standards and headers and make a high level design. I would prefer to stick with W3C or Mozilla Firefox supported headers.

1; report=http://site.com/report - This is a Chrome and WebKit only directive that tells the user-agent to report potential XSS attacks to a single URL. Data will be POST'd to the report URL in JSON format.

If the report is automatically submitted, it sounds bad from a privacy perspective. If we want to support such a feature we should ensure that user's permission is taken before sending the report.

[Nidish93]

Contributions to the second level of control seems interesting. I will try to look more into it in the future.