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)