[ https://issues.apache.org/jira/browse/SPARK-23983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438554#comment-16438554 ]
Joe Pallas commented on SPARK-23983: ------------------------------------ It seems clear that the CSP frame-ancestors approach is better overall: it's more flexible (handles the use cases mentioned here) and it's an actual standard supported by [all-minus-one of the major browsers|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors#Browser_compatibility]. But it's not supported by IE, which could be seen as a problem. Using both frame-ancestors and x-frame-options could lead to strange interactions, since the [OWASP Clickjacking cheat sheet|https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Defending_with_Content_Security_Policy_.28CSP.29_frame-ancestors_directive] says some browsers that recognize both violate the standard by giving priority to x-frame-options. That's unfortunate. > Disable X-Frame-Options from Spark UI response headers if explicitly > configured > ------------------------------------------------------------------------------- > > Key: SPARK-23983 > URL: https://issues.apache.org/jira/browse/SPARK-23983 > Project: Spark > Issue Type: Improvement > Components: Web UI > Affects Versions: 2.3.0 > Reporter: Taylor Cressy > Priority: Minor > Labels: UI > > We should introduce a configuration for the spark UI to omit X-Frame-Options > from the response headers if explicitly set. > The X-Frame-Options header was introduced in *org.apache.spark.ui.JettyUtils* > to prevent frame-related click-jacking vulnerabilities. This was addressed > in: SPARK-10589 > > {code:java} > val allowFramingFrom = conf.getOption("spark.ui.allowFramingFrom") > val xFrameOptionsValue = > allowFramingFrom.map(uri => s"ALLOW-FROM $uri").getOrElse("SAMEORIGIN") > ... > // In doGet > response.setHeader("X-Frame-Options", xFrameOptionsValue) > {code} > > The problem with this, is that we only allow the same origin or a singular > host to present the UI with iframes. I propose we add a configuration that > turns this off. > > Use Case: Currently building a "portal UI" for all things related to a > cluster. Embedding the spark UI in the portal is necessary because the > cluster is in the cloud and can only be accessed via an SSH tunnel - as > intended. (The reverse proxy configuration {{*_spark.ui.reverseProxy_* could > be used to simplify connecting to all the workers}}, but this doesn't solve > handling multiple, unrelated, UIs through a single tunnel. > > Moreover, the host that our "portal UI" would reside on is not assigned a > hostname and has an ephemeral IP address, so the *ALLOW-FROM* directive isn't > useful in this case. > > Lastly, the current design does not allow for different hosts to be > configured, i.e. *_spark.ui.allowFramingFrom_* _*hostname1,hostname2*_ is not > a valid config. > > An alternative option would be to explore Content-Security-Policy: > [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#frame-ancestors] -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org