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)