[jira] [Updated] (SPARK-23983) Disable X-Frame-Options from Spark UI response headers if explicitly configured
[
https://issues.apache.org/jira/browse/SPARK-23983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taylor Cressy updated SPARK-23983:
--
Description:
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]
was:
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:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#frame-ancestors
> 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
[jira] [Updated] (SPARK-23983) Disable X-Frame-Options from Spark UI response headers if explicitly configured
[
https://issues.apache.org/jira/browse/SPARK-23983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taylor Cressy updated SPARK-23983:
--
Description:
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]
was:
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]
> 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
