[
https://issues.apache.org/jira/browse/HDFS-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808874#comment-13808874
]
Haohui Mai commented on HDFS-5333:
----------------------------------
bq. I've tried all the text browsers that I can get my hands on in a Ubuntu
12.04 LTS VM: elinks, links, lynx, w3m, all handled iframe gracefully – In all
but w3m, iframe shows up as a specially marked iframe link you can follow with
iframe src url prominently displayed. w3m doesn't support iframe, which is
simply ignored. All scripts are simply ignored in all the text browsers I've
tried.
XSS attack can still happen. For example, an attacker can exploit HDFS-4901 to
inject a cross-domain CSS request to steal the cookie information.
Again, XSS attacks are due to unsanitized external inputs. Defending XSS
attacks is *orthogonal* to which rendering technique that you're using. Both
the old and the new web UI can suffer from this type of vulnerabilities.
Therefore, I don't agree with your argument on the old web UI is more secure
(w.r.t XSS attacks) than the new one, just because they render pages at
different locations. See my previous responses for details.
bq. for most (see above for concrete examples) text based browsers (there is
also a market for secure graphical browser), paranoid users can reduce the
attack surface of XSS to 0 while still enjoy the (admittedly spartan) UI, if we
do server-side rendering, while the attack surface for client only rendering is
always much greater than 0 (millions lines of code in network
configuration/stack, browser/script engine, javascript libraries/applications)
I don't buy the argument of *achieving security through unavailability*. It's
legitimate to say that the vulnerability does not affect me because my browser
has no support of feature foo, but it doesn't change the fact we have a
vulnerability that we should fix in the code.
I respect your right of using text-based browsers for the web UI, or even
shutting it down to prevent security vulnerabilities. However, we should
respect the rights of other Hadoop users to use the web UI in commodity web
browsers.
I think it is a shame to force the users to use text-based browsers because of
security issues, without even discussing fixing the bug itself at all.
bq. In theory, the attack surface for a text browser is its small and
relatively simple html parser, which can potentially overflow a buffer given
bad input. Phishing is still possible if a user is not careful, but the user
still has some control: inspect any links before following, as link following
is never automatic).
You can write your own UI using the JMX API.
> Improvement of current HDFS Web UI
> ----------------------------------
>
> Key: HDFS-5333
> URL: https://issues.apache.org/jira/browse/HDFS-5333
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Jing Zhao
> Assignee: Haohui Mai
>
> This is an umbrella jira for improving the current JSP-based HDFS Web UI.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
