Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> Replacing the JSP web UIs to HTML 5 applications

Copy link to this message
Re: Replacing the JSP web UIs to HTML 5 applications
Producing JSON would be great. Agree with Colin that we should leave for
now the current JSP based web ui.

On Mon, Oct 28, 2013 at 11:16 AM, Colin McCabe <[EMAIL PROTECTED]>wrote:

> This is a really interesting project, Haohui.  I think it will make
> our web UI much nicer.
> I have a few concerns about removing the old web UI, however:
> * If we're going to remove the old web UI, I think the new web UI has
> to have the same level of unit testing.  We shouldn't go backwards in
> terms of unit testing.
> * Most of the deployments of elinks and links out there don't support
> Javascript.  This is just a reality of life when using CentOS 5 or 6,
> which many users are still using.  I have used "links" to diagnose
> problems through the web UI in the past, in systems where access to
> the cluster was available only through telnet.  If we are going to
> remove this capability, we need to add some other command-line tools
> to get the same functionality.  These tools could use REST if we have
> that, or JMX, but they need to exist before we can consider removing
> the old UI.
> best,
> Colin
> On Fri, Oct 25, 2013 at 7:31 PM, Haohui Mai <[EMAIL PROTECTED]> wrote:
> > Thanks for the reply, Luke. Here I just echo my response from the jira:
> >
> > bq. this client-side js only approach, which is less secure than a
> > progressively enhanced hybrid approach used by YARN. The recent gmail
> > XSS fiasco highlights the issue.
> >
> > I'm presenting an informal security analysis to compare the security of
> the
> > old and the new web UIs.
> >
> > An attacker launches an XSS attack by injecting malicious code which are
> > usually HTML or JavaScript fragments into the web page, so that the
> > malicious code can have the same privileges of the web page.
> >
> > First, in the scope of XSS attacks, note that the threat models of
> > launching XSS attacks on Internet sites Gmail/Linkedin and the one of the
> > Hadoop UIs are different. They have fundamental different sets of
> external
> > inputs that the attackers have control to. Internet sites have little
> > control of these inputs. In the case of Gmail / Linkedin, an attack can
> > send you a crafted e-mail, or put malicious description in his /
> > her Linkedin profile. The sets of external inputs are *restricted* in
> > Hadoop UIs. The new web UIs take JMX and WebHDFS as inputs. The
> > attacker has to launch a XSS attack by:
> >
> > * Compromise the jars so that the output of JMX / WebHDFS have the
> > malicious code.
> > * Replace the web UIs completely to include the malicious code.
> >
> > In either case *the attacker has to compromise the hadoop core or the
> > namenode*. That means the new web UIs are at least as secure as the
> hadoop
> > core, and the namenode machine.
> >
> > Second, I argue that using client-side templates are more secure than the
> > current JSP-based server-side templates. To defend against XSS
> > attacks, both techniques have to filter the external inputs at *every*
> > possible execution paths. Several facts much be taken into
> > plays when evaluating the security of both approaches in real-world
> > environments:
> >
> > * The JavaScript libraries used in the new web UIs have survived in
> > extremely large-scale production tests. jQuery is used by Google and
> >  Microsoft, bootstrap is used by Twitter, and dust.js is used by
> Linkedin.
> > All libraries survived from hundreds of thousands of
> >  attack attempts on a daily basis. I agree that the libraries might still
> > be imperfect, but there's no way that we can test the JSP web
> >  UIs to achieve the same level of assurances given the amount of
> resources
> > the community has.
> > * Client-side templates consolidate all filtering logic in one central
> > place. Recall that the goal is to filter all external inputs at every
> >  execution paths, this is a much more systematic approach compared to the
> > server-side templates we have today. It is difficult (if not
> >  impossible) to do it in a JSP/ASP/PHP application, since such filtering