You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zeppelin.apache.org by "Yun Young Don (JIRA)" <ji...@apache.org> on 2019/04/12 02:34:00 UTC

[jira] [Created] (ZEPPELIN-4119) Zeppelin Shiro's roles parameter can be modulated.

Yun Young Don created ZEPPELIN-4119:
---------------------------------------

             Summary: Zeppelin Shiro's roles parameter can be modulated.
                 Key: ZEPPELIN-4119
                 URL: https://issues.apache.org/jira/browse/ZEPPELIN-4119
             Project: Zeppelin
          Issue Type: Bug
          Components: security, zeppelin-server
    Affects Versions: 0.8.1
            Reporter: Yun Young Don


*Subject: Zeppelin Shiro's roles parameter can be modulated.*

<example : shiro.ini settings>
 admin=password0,admin
 user1=password1,role1

*Normal Case* ----------------------------------------

1. login
 - id: user1
 - pwd: password1

2. note list
 - note 1 (role1 permission)
 - note 2 (role1 permission)
 - list only role1 permissions notes

*Roles Parameter Modulation Case* ----------------------------------------
 * prepare for websocket logging => add below lines at ~/conf/log4j.properties

log4j.logger.org.apache.zeppelin.socket = DEBUG, dailyWSfile
 log4j.logger.org.apache.zeppelin.notebook = DEBUG, dailyWSfile
 log4j.appender.dailyWSfile.Threshold = DEBUG
 log4j.appender.dailyWSfile = org.apache.log4j.DailyRollingFileAppender
 log4j.appender.dailyWSfile.File = ${zeppelin.log.file}.ws
 log4j.appender.dailyWSfile.layout = org.apache.log4j.PatternLayout
 log4j.appender.dailyWSfile.layout.ConversionPattern=%5p [%d] (\{%t}%F[%M]:%L) - %m%n

1. login
 - id: user1
 - pwd: password1

2. roles parameter modulation using fiddler
 - response modualtion
 ** add [{color:#FF0000}admin{color}] role arbitrarily.
 - original body
 > body: \{principal: "user1", ticket: "bd928176-70b4-4c08-92a3-d0f5b2037be1", roles: "["role1"]"}
 - modulation body
 > body: {principal: "user1", ticket: "bd928176-70b4-4c08-92a3-d0f5b2037be1", roles: "["role1",{color:#FF0000}"admin"{color}]"}

3. when login success, client calls websocket event for display note lists.
 - zeppelin-web project
 - src/components/navbar/navbar.controller.js
 - loadNotes()

3. check zeppelin server's websocket logs
 - ~~/logs/~.~log.ws (by upper prepared settings)
 > NotebookServer.java[onMessage]:161) - RECEIVE << PING, RECEIVE PRINCIPAL << user1, RECEIVE TICKET << bd928176-70b4-4c08-92a3-d0f5b2037be1, RECEIVE ROLES << ["role1",{color:#FF0000}"admin"{color}], RECEIVE DATA << null
 - webserver has received a modulated role parameter.

4. note list
 - note 1 (role1 permission)
 - note 2 (role1 permission)
 - {color:#FF0000}note 3 (admin permission){color}
 - {color:#FF0000}note 4 (admin permission){color}

> note 3, note 4 {color:#FF0000}must be hidden{color} to role1 permission users. but by roles parameter modulation, it can be displayed abnormally.

Conclusion
 Role infomation is very important for security concerns and must be treated very carefully.
 For this security issue, it is needed that the server sustains priciple's roles and validate if it is same between server side role info and client side sended one when processing websocket request. if there is an dismatch, it have to throw error and do not progress next step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)