Mask passwords with JSONPath issue

mrios
New Member

Hi,

I'm adding to the organization level a mask for passwords. The xml looks like this:

<MaskDataConfiguration name="default">
    <JSONPathsRequest>
        <JSONPathRequest>$..password.</JSONPathRequest>
        <JSONPathRequest>$..oldPassword.</JSONPathRequest>
        <JSONPathRequest>$..newPassword.</JSONPathRequest>
    </JSONPathsRequest>
    <JSONPathsResponse>
        <JSONPathResponse>$..password.</JSONPathResponse>
        <JSONPathResponse>$..oldPassword.</JSONPathResponse>
        <JSONPathResponse>$..newPassword.</JSONPathResponse>
    </JSONPathsResponse>
    <Variables>
        <Variable>ServiceCallout.request</Variable>
        <Variable>request.formparam.password</Variable>
    </Variables>
</MaskDataConfiguration>

Using that description for the mask I noticed that if you have a json request that looks like this

{ "email": "user@abc.com", "password": "password"}

on the Edge I see this

{ "email": "user@abc.com", "**********":"**********"}

which is quite easy to infer the password 🙂

So, is that an expected behavior on the Edge or is it a bug?

2030-screen-shot-2016-02-24-at-114342-am.png

Thanks,

Matias

2 4 227
4 REPLIES 4

adas
New Member

@Matias It might appear that there's a correlation between the actual and the masked characters in terms of the total number of characters and what the actual content could be, but that's not true. You can try with a very long string and it would still mask it the same way.

But I do see your point about the key getting masked, which can act as some sort of indication of what the value could be. This is a known bug, that we are already aware of and should get fixed in some future release. Here's a sample request, where the masking happens differently:

curl -v http://myapis.apigee.net/masking -d '{ "email": "user@abc.com", "password": "unknownpasswordstring"}' -H "content-type: application/json"

2046-masking.png

adas
New Member

2047-masking.png

@Matias I would also like to confirm, if you are a trying this on cloud or on-premises. If I remember correctly, this bug was fixed on our cloud release somewhere in October and I see its working fine. If you are on some version of OPDK, you might need a patch for this fix. If you can share more details about your test environment, it would be great.

@arghya das Thanks for the information.

We are working with the on-premises version 4.15.07.00

Is there a patch available for this issue?

Thanks,

Matias

@Matias I would have to look it up. Even if there's not one, you can always request for it since the next major version is not out yet. I will check the status of that bug and see if its packaged in any of our patches on 1507 and let you know.