[ZEPPELIN-4119] Zeppelin Shiro's roles parameter can be modulated.

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.8.1
• Component/s: security, zeppelin-server
• Assignee: Unassigned
• Reporter: Yun Young Don
• Created: 12/Apr/19 02:33
• Updated: 15/Apr/19 04:29

Description

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 [admin] 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","admin"]"}

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","admin"], RECEIVE DATA << null
• webserver has received a modulated role parameter.

4. note list

• note 1 (role1 permission)
• note 2 (role1 permission)
• note 3 (admin permission)
• note 4 (admin permission)

> note 3, note 4 must be hidden 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.