Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate pk in job api url #1496

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

akihikokuroda
Copy link
Collaborator

Summary

Validate pk in the job api url to prevent SQL Injection

Details and comments

pk,
re.IGNORECASE,
):
return None
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably log a warning too if this happens

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a log entry

Copy link
Member

@Tansito Tansito Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question @akihikokuroda , is here where we need to check this? Because we are not using pk in the entire method 🤔

Thinking that in general, Django ORM should prevent this kind of things.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is when the request is like this

https://qiskit-serverless-dev.quantum.ibm.com/api/v1/jobs/case+randomblob%281000000%29+when+not+null+then+1+else+1+end+/stop

It has a bad string in stead of the job id in the request url. It causes a database request with the string. The request that has the pk in the url always executes the get_queryset method before it calls the individual method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to say that I am not being able to replicate it

Copy link
Collaborator Author

@akihikokuroda akihikokuroda Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tried it by myself. The issue says

The query time is controllable using parameter value [case randomblob(1000000) when not null then 1 else 1 end ], which caused the request to take [334] milliseconds, parameter value [case randomblob(10000000) when not null then 1 else 1 end ], which caused the request to take [2,141] milliseconds, when the original unmodified query with value [id] took [824] milliseconds.

Validating the id part should prevent this.

Copy link
Member

@Tansito Tansito Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My doubt here is that it surprises me that django orm doesn't manage this and we have similar end-points that passed the tests so I'm trying to figure out if we are doing something that we should not do.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just tried to reproduce this issue but it didn't happen. So I can not see what happened. How about putting this fix in and see if the issue happens with it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before merge it let me try to pass another scan Monday with security to confirm it and solve any doubt, Aki.

@Tansito Tansito added the on-hold On hold due to any reason label Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on-hold On hold due to any reason
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants