You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Haohui Mai (JIRA)" <ji...@apache.org> on 2014/10/11 02:37:34 UTC

[jira] [Resolved] (HDFS-6845) XSS and or content injection in hdfs

     [ https://issues.apache.org/jira/browse/HDFS-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Haohui Mai resolved HDFS-6845.
------------------------------
    Resolution: Not a Problem

This is no longer an issue after HDFS-6252 is merged into branch-2.

> XSS and or content injection in hdfs
> ------------------------------------
>
>                 Key: HDFS-6845
>                 URL: https://issues.apache.org/jira/browse/HDFS-6845
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>            Reporter: clouds
>              Labels: security
>
> Following up from email
> "...
> I was auditing the latest stable version of hdfs - 2.4.1 (as made
> available from
> http://mirror.nexcess.net/apache/hadoop/common/hadoop-2.4.1/hadoop-2.4.1-src.tar.gz
> ), I noticed an interesting XSS filter.  Ok, sure.  But what intrigued me
> was where I didn't find any attempt to validate or sanitize.
> Within DatanodeJSPHelper.java - line 108, nnAddr is assigned the value
> from the raw parameter NAMENODE_ADDRESS.     On line 120, printgotoform is
> called with the raw value.  Then then called JspHelper.java's
> printGotoForm method - Line 452.  Then on line 468, the unvalidated or
> sanitized value is printed to the html page.  Worst case, reflected XSS. 
> Better case, content injection.
> Similarily,  DatanodeJSPHelper.java's line 102 tokenString variable looks
> plausible but I am not certain if an incorrect token will cause the
> business logic to fail before the malicious input it displayed
> (JspHelper.java - line 465.)
> ..."
> These are not the only XSS / Content injection points but should give an easy idea to find the others.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)