Prevent external sites from embedding Build

[yanokwa]

Build can be run in an iframe and that means someone harvest credentials when in an iframe.

[issa-tseng]

how does that compromise the credentials?

[florianm]

Something like in nginx add_header X-Frame-Options "SAMEORIGIN";?

[yanokwa]

@issa-tseng An attacker could put ODK cloud or forum or whatever credentials here in the outside frame and claim it will enable some better functionality.

@florianm What I've used in the past is this:

  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-Content-Type-Options nosniff;

I'm not sure if/how Build uses cookies so we may want to explore adding SameSite=Strict too.

[harisahmed101]

Remediation: The best way to defend clickjacking is to defend it from server side and there are two mechanisms for server-side clickjacking protection, which are X-Frame-Options and Content Security Policy.

1st-way X-Frame-Options:

You may set X-Frame-Options as per your requirement according to their use case.

1. X-Frame-Options: deny

DENY – does not allow any domain to display this page within a frame

2. X-Frame-Options: sameorigin

SAMEORIGIN – allows the current page to be displayed in a frame on another page, but only within the current domain.

Content Security Policy (CSP)

Common uses of CSP frame-ancestors:

Content-Security-Policy: frame-ancestors 'none';

This prevents any domain from framing the content. This setting is recommended unless a specific need has been identified for framing.

1. Content-Security-Policy: frame-ancestors 'self';

This only allows the current site to frame the content.

2. Content-Security-Policy: frame-ancestors 'self' *.somesite.com https://myfriend.site.com/;

This allows the current site, as well as any page on somesite.com (using any protocol), and only the page myfriend.site.com, using HTTPS only on the default port (443).

[harisahmed101]

@issa-tseng As You have not disabled iframes or did not set them on same-origins therefore attackers can use multiple transparent or opaque layers to trick a user into clicking on a button or link for redirecting to another page. Furthermore, as the server response is visible in iframes so attackers can use multiple transparent or opaque layers so when the user intends to click on the top-level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Attacker scenario: If the attacker uses multiple transparent or opaque layers and sent that suspicious link to the user, once the user opens the link, your website would be opened in an Iframe as the server was responding to the iframe page request so the user thinks that is a genuine website as the server is responding on his request. If the attacker would set transparent buttons on the login button so the user can become a victim of losing login credentials (account takeover).

" As the Server is responding same whether a website open in an iframe or website is open in normal mode."

Let's assume your user opens his account in the iframe and he is using your platform, as your web server is responding to each request normally so he will consider himself in a safe environment. While using your platform a message is shown "Click here for a free iPhone " as the user was receiving every response from your server he will be sure the offer is from your website but once he clicks on the button he would be a victim of the attacker's trick.

BOOM!

I shared the detailed article on clickjacking below:

https://auth0.com/blog/preventing-clickjacking-attacks/#Prevent-Clickjacking-Attacks

[harisahmed101]

Is there any update regarding the reported issue and bounty reward for my responsible disclosure?

[yanokwa]

Thanks for the responsible disclosure. We do not have a bounty program. We will resolve this issue in due time.