REST API testing - Should POSTing an unknown attribute in body be allowed?

🗄️ Archive
1

Hi there all,

This is my first post here in this forum and I hope I’m doing it correctly. Been wanting to join here for a while now. And now that I have a question I’ve actually done it. :slight_smile:

Our company is moving towards Azure. For this the dev.team is building new REST API’s.
I have a fair amount of API testing experience (in postman / rest assured).

But I seem to have a disagreement with the developers concerning a simple issue.
The API’s they are building allow for unknown attributes to be added to the POST body.

I’ve created this JSON schema as an example to better explain my question:

{
    "type": "object",
    "properties": {
        "name": {
            "maxLength": 20,
            "type": "string"
        }
    },
    "required": [
        "name"
    ],
    "example": {
        "name": "string"
    }
}

But the endpoints allows me to send a body which looks like this:

{
    "name": "boofar",
    "notExistingAttribute": "fubar"
}

The input gets accepted and the “notExistingAttribute” gets ignored.
I for one think that the POSTing application/user should be informed that the request that has been made is not correct (it should return a 400 Bad Request) and thus refuse to handle the request.

The devs however say that the problem is on the side of the application that sends the POST request. They should obey to the API documentation/JSON schema.

What do you guys think? And if you’re on the same page as me: what arguments beside the one I’ve mentioned already can I use in the discussion?

2 Likes
2

Sounds like a tail wagging the dog problem.

You could always do a post request with a really really huge attribute content and see if the performance is impacted , or for that matter with unusual attack-vector type content in the attribute, to be really sure it does get ignored. I would really try crash the service, if it does nothing, and IMHO, as long as the app ignores invalid attributes consistently, that’s probably within the requirements.

Just as an unrelated curiosity. In the C/C++ language any method-calls made using the “C” calling convention (__cdecl) can push as many additional parameters onto the stack as they please, the callee simply ignores and does not modify/read the extra stack args, this is an attack vector for people who want to move data and read it in the callee if they corrupt/control the callee. “C” does not modify the stack, it only looks at the stack area it expects, and ignores the rest. The caller is responsible for stack cleanup, so no harm done. In, Pascal calling convention , the callee actually “pulls” args off the stack, which corrupts the RET when the callee returns, if the wrong number of args was passed. Which once again is an attack not unique to the Pascal language.

So sometimes, it’s not necessary to tell the caller that a attribute that might not be in use anymore was ignored. One assumes the API is versioned? That’s the only discussion to have I guess.

1 Like
3

Thanks for your response @conrad.braam !
These are some welcome insights!
And yes, we are versioning the API.

I don’t have any experience with sending attack-vector type content. Will look into that next week.

I’ve tested it now with a huge attribute content (31 milion+ characters) and it does indeed seriously effect the reponse time. From ~42ms to ~10s…

But functionality wise I don’t see any issues…

3 Likes
4

Boerman! Yes. That is awesome, I think the trick is to make another client do an API call just around about at the same time as your 31MB call and see if it is impacted - that would indicate a locking problem I guess, but so far it looks like there is no bug, but you now know a thing you might not have before. I love that we get paid to run silly experiments.

1 Like
5

Yes that’s normal. That’s part of using Json. Developers can’t control that. It’s just ignored isn’t a problem. Same would be true for any http params. Dev won’t checks for params they aren’t expecting. Security firewalls don’t even do that.

2 Likes
6

just have a JSON Schema for the incoming parameters and disable unknown parameters, this should always raise concerns.
see https://jsonschema.net/

1 Like
7

For those people saying it’s illegal to pass attribs that are not within spec, it’s always good to remember that the test engineers job is to tell us what kind of evil things may happen. Not if they are wrong. Like when a client app that fails to update itself makes calls, should the client break and annoy the paying customers? It’s often up to the business to decide if we care, and things like whether we generate schemas and then implement a semantic version or a functional version mechanism. We don’t control the environment our product lives in, even in B2B situations, and so only testing happy path gives you no clue about tech debt that may hit you tomorrow when someone forgets to edit a schema or something.

1 Like