Layer7 API Management

We are working with a using XPath credentials and part of security policy included "Protect Against Code Injection" protection of the body.

Came across a password that fired it off and that password ended up being logged in clear in the log file. That would allow folks who shouldn't have access to it to know the key.

Is there a recommended way to keep this from happening with POST body and still get the code injection protection? I wouldn't want to change it globally for non-sensitive POST data, but for sensitive POST content want to ensure the actual value is masked in some way or something.

I'd want it applied to only very specific policies where sensitive stuff is present. Everything else would be fine, and better, to have the value to know what someone was trying to send across.

WARNING 5687 com.l7tech.server.policy.assertion.ServerCodeInjectionProtectionAssertion: 7154: [password was here]... detected in Request message body

Dear CBertagnolli ,

Did you put the password in plain text in the post body?

The protect assertions should not decode the body automatically if you have password encoded.

I would suggest to have the password base64 encoded at least.

You can decode the password in your policy afterward (with encode/decode data assertion)

Regards,

Mark

Yes, the app is posting via a POST body that is URL encoded. The body is simply something like:

username=myuser&password=mypassword&otherparam=blah&otherstuff=blahagain...so on.

The problem is even base64 encoded it does not protect the password value itself. You can simply decode it from the log file and now have the value.

From my point of view, how to protect the password is depends on implementation.

Usually SSL connection is secure enough to protect the content in the incoming request along the network. After reach gateway, if it's base64 encoded, it should not be put to the log by accident.

After all, the user/password authentication has its limit.

If you want more secure, you may consider other advanced authentication method, such as one time password, SAML, etc.

Except that the applications tend to use application/x-www-form-urlencoded and don't encode it. So I'd have to ask that to be changed on the app side and to encode first.

What if we do the encode at the API Gateway BEFORE the injection protection assertion....maybe something like? So when it first hits the gateway it may not be encoded, we encode the values desired, and then into the injection protection assertion; That would avoid any app making changes for now and still keep it from getting logged due to encoding the values.

Yes, we can do it with different ways.

But general speaking, it should be done on client side. Putting special chars in payload might not be a good practice. Before the request reach gateway, there could be many other devices in the middle such as firewall, LB, etc. doing similar scan and might block the request. You don't know.

So at this point, this assertion is completely non-usable. Any kind of form POST that contains sensitive info - e.g., PII cause user is entering SSN etc - could potentially have it audited in a log file on the gateway if an unexpected characters is seen.

Unfortunate because it gave a quick/easy way to do some baseline validations on the form, which apps wanted. 

Will keep playing with it to see how we want to handle it, but right now removed it from any security policies.