25-Oct-2021 05:22
I'm intercepting a POST with JSON parameter and I want to check the content but I'm not able to see where to define allowed character, length and type of each parameter
I defined my parameters as JSON value
If I post following request, it's working
<code>
{
"data": {
"type": "enrollment",
"attributes": {
"fire": "t",
"app": "t",
"installation": "t",
"credential": "t",
"phoneNumber": "1"
}
}
}
</code>
This one is also working
<code>
{
"data": {
"type": "enrollment",
"attributes": {
"fire": "f",
"app": "f",
"installation": "f",
"credential": "f",
"phoneNumber": "1"
}
}
}
</code>
But If I post following content, it's blocked with error message that I have "illegal character" (It's the same character as above but I have two character in the value instead of one)
<code>
{
"data": {
"type": "enrollment",
"attributes": {
"fire": "tf",
"app": "tf",
"installation": "tf",
"credential": "tf",
"phoneNumber": "2"
}
}
}
</code>
So where can I define the length and type of each JSNO value ?
Solved! Go to Solution.
03-Nov-2021
14:35
- last edited on
24-Mar-2022
01:18
by
li-migration
Are you sure those are JSON values and not user-input values?
Do you have an OpenAPI Spec file to verify?
Since you are running on 15.1.2.1, as stated - if you have a OpenAPI Spec file can you create a policy "REST API Security (Open API Spec) " with the Guided Configuration?
KR
Daniel
30-Oct-2021
09:56
- last edited on
24-Mar-2022
01:18
by
li-migration
Hi ,
the example which is blocked looks like valid JSON. Maybe check yourJSON Profile here:
Security ›› Application Security : Content Profiles : JSON Profiles
As a reference, check the Manual Chapter : Adding JSON Support to an Existing Security Policy.
KR
Daniel
01-Nov-2021
03:39
- last edited on
24-Mar-2022
01:18
by
li-migration
Hi
Thanks for the reply. I already had a look to this page and I also checked "character set" in "application security - Content profiles - Character sets - JSON content" and in "application security - Parameters - Character sets - Parameter Value/Name".
What I don't understand is why it's accepted when the character is in first position in the value but not when he is in second position (or more)
KR
Philippe
01-Nov-2021 10:11
Sorry, maybe I was on the wrong track.
Does this violation occur with any combination of more than one character in the value?
Or only when the f is in second position?
Or on any character in the second position?
EDIT: Did you change the Default JSON profile?
01-Nov-2021 10:38
It's depend the character, when I'm sending "ft" or "tf", it's occur on second character.
If I'm sending "a" it's occur on first parameter.
And what is strang is that violation occur only on parameters "fire" and "installation" even if my four parameters (fire, installation, app and credential) have the same value.
03-Nov-2021
01:24
- last edited on
24-Mar-2022
01:18
by
li-migration
Hi ,
I managed to reproduce your issue, but could not find a solution yet.
Which version are you on?
KR
Daniel
03-Nov-2021
14:35
- last edited on
24-Mar-2022
01:18
by
li-migration
Are you sure those are JSON values and not user-input values?
Do you have an OpenAPI Spec file to verify?
Since you are running on 15.1.2.1, as stated - if you have a OpenAPI Spec file can you create a policy "REST API Security (Open API Spec) " with the Guided Configuration?
KR
Daniel
05-Nov-2021 06:41
For me those are JSON values as if I define parameters as "user input" nothing is catched (also disallowed character).
I asked developper to forward me OpenAPI spec file but currently I didn't receive any answer. I hope to have something next week
KR
Philippe
11-Nov-2021
00:50
- last edited on
24-Mar-2022
01:18
by
li-migration
I received a spec file from customer and created a new policy with the guided config. Parameters are correctly seen and secured
At the end you were right, parameters are recognized as "user input value". I will now check both policies to understand what was wrong in the first one
03-Nov-2021 02:45
Hi Daniel, Philippe is testing in v15.1.2.1