Mask parameters in log file

[testn]

I have some password field that I don't want to emit in the log file. However, the mapper log will try to print all the parameter. It would be nice if there is a way to hide/mask certain parameters. In addition to that, there is also no way to turn on debugging SQL statement but turn off debugging parameter information.

[joshijimit]

Hi there,

Have you sorted it out? Is there any way to do it? I have same requirement as of yours.

As a worst case I have to disable myBatis log and add custom log for SQL.

[emacarron]

Hi testn.

Sorry for the late reply. Statements are logged with debug level, and results with trace level.
http://mybatis.github.io/mybatis-3/logging.html

You can disable the logging only for one statement so probably this is a good workaround.

Let us know how you would like that masking to be configured/applied.

[joshijimit]

Are you saying we can disable logging for the statement in which sensitive information is being written so that the whole statement will be wiped out from the log? If yes, I don't think it's a good solution as we never know what other parameter are passed to this statement. can't we just mask the parameter value in the statement?

[emacarron]

@joshijimit

Yep, but note I was only proposing it as a workaround, not as the final solution.

Again :) how you would like that masking to be configured/applied?

[joshijimit]

Can we have some implementation such that we can pass the comma separated list of masked parameter while calling statement in XML? Check parameter maskParamList in below statement call. Parameter which are given in this list will be masked with **** in log.

select id="callSysUserLogin" resultMap="userLoginResult" statementType="CALLABLE" maskParamList="Password,encryptionKey"
{ call dbo.Sys_UserLogin
(#{UserName},#{Password},#{encryptionKey},#{SessionID},#{AltSeesionID},#{Context})}
select

Not sure if this can be achievable. Just a thought.

(Removed < and > from statement as it hides the call.)

[emacarron]

Makes sense.

A new token ni the parameter expression like :

select * from users where user = #{user} and password = #{password,maskLog=true}

Note it has to be like key=value, though probably only maskLog looks enough.

The problem with this approach is that it only will mask input params but not output. For example, the stament I posted will show the password also in the results.

[joshijimit]

I am fine with your approach. it make sense. Also regarding password in result, I don't think anyone should return the password or such sensitive information in result. In above case user should check the password in the query itself and return only user related information. Also in case of Stored procedure you can mask the result as well. so I think the masking of result should be handled at DB layer.

[harawata]

Isn't it suitable to use AOP to output necessary information rather than bringing the logging factor into an SQL statement?
Just my two cents,
Iwao

[joshijimit]

The main question is, what are the other information you need to mask in logs. If it just a parameter then the approach discussed with emacarron will do the Job with less work I guess. However, if you are looking at masking some more information apart from param then we should re think on it.

Another approach which I was wondering can help here is we can add the masking information at log4j config file where we can specify the logging for statement as well. something like below can help to mask param as well as result. Again just a thought not sure if it works. :)

log4j.logger.org.mybatis.example.BlogMapper.selectBlog=TRACE
log4j.logger.org.mybatis.example.BlogMapper.selectBlog.param.maskLog=Password,encryptionKey
log4j.logger.org.mybatis.example.BlogMapper.selectBlog.result.maskLog=Password

[emacarron]

Hi again.

Well, I said I saw a problem with the approach. It was more an invitation for community thinking :)

I agree in that nobody should query for passwords but MyBatis should not care about how you code, both good and bad developers are welcome. We should focus on symmetry and avoiding surprises. If you can mask inputs then you will probably expect to be able to mask outputs, and probably you will prefer to do it with a similar configuration.

If we go this way we will need also a new attribute for ouputs :

<resultMap>
  <result colum="col" property="prop" maskLog="true"/>
</resultMap>

Or... add a configuration property like "maskColumns=password" and check it for all statements.

[joshijimit]

Hi emacarron,

I like your statement "both good and bad developers are welcome". :)

The solution for result masking looks good to me at resultMap. What about multiple column masking at configuration property? Shall we give comma separated column list?

[lmeadors]

If this is a global parameter (like maskColumns="password"), will that then be set on the parameter and result maps one time at start up?

Seems like doing the check at call time would be a real performance drain.

[emacarron]

@lmeadors

Yep. That is something to take into account. I is easy to messure in case we go that way.

[sreetha05]

is there an option to mask a column? I am using ibatis and have a similar requirement