HTTP Parameter Pollution

[nmarkevich]

Hi there,

According to the Apigee docs, Javascript policy can be used to rewrite the target url.

However, the solution provided in docs is vulnerable to HTTP parameter pollution, since Apigee decodes all parameters extracted either via ExtractVariables policy or via request.* object.

Moreover, an attacker can add hash ("#") which may result to unexpected behavior of target system, since part of the target request query may be omitted.

And as I see, many developers rely on this solution 😢.

To mitigate the issue above please add a statement about url encoding before constructing target url

[nmarkevich]

That's what I got when sent mailformed request to such proxy

[nmarkevich]

Any updates on this?

[dchiesa1]

I'm not sure what problem we are solving. Maybe you could walk me through it more slowly. 

You said you sent in a "malformed request."   What exactly is malformed in your tests?  In my tests with Apigee, when I pass a qparam that has encoded ampersands and equals signs, in other words 

username=johndoe%26verbose%3Dtrue

...the full value of that qparam gets passed to the upstream system.

Are you suggesting that if I build logic in my apiproxy to set the variable target.url, then the query param gets decoded and encoded incorrectly, such that the upstream receives something different? 

Are you saying that ExtractVariables is returning incorrect results?

It seems like you are suggesting that we make an amendment to the documentation, but I am not sure what specifically you're asking for.

[nmarkevich]

Hi @dchiesa1,

Yes, you are right when saying that the full value of that qparam gets passed to the upstream system. And yes, ExtractVariables returning correct results - query params get decoded.

But in this build logic (when target.url is setting via Javascript), query params are not encoded when passed to upstream.

So when you pass

username=johndoe%26verbose%3Dtrue

to a proxy, then you will get the following in upstream request

username=johndoe&verbose=true

[dchiesa1]

I see. You are telling me that if I set target.url , then , the correct encoding of the qparams is broken.  Is that right?  If so, let me test that here and verify that I see the same thing.  If that's what is happening, I agree with you: it's quite wrong, and we need to fix that. Let me explore a bit, and I will revert and let you know. 

[nmarkevich]

Yes, please. Looking forward to your reply

[nmarkevich]

Hi @dchiesa1,

Could you please provide any updates on this? Thanks

[dchiesa1]

Hi nmarkevich

I was away on holiday on Thursday and Friday, I haven't had time to look into this yet. But I will. I'm sorry I have no update for you at this time. When I do have an update, I'll provide it here.

[nmarkevich]

Hi @dchiesa1,

Have you had a chance to test the issue above?