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

Question about possible code exploit #9

Closed
symroe opened this issue Aug 23, 2017 · 4 comments
Closed

Question about possible code exploit #9

symroe opened this issue Aug 23, 2017 · 4 comments

Comments

@symroe
Copy link

symroe commented Aug 23, 2017

From the README:

You can include other files in your blueprint by using an include directive with a path to the included file relative to the current file's directory.

And the line in the code that parses includes looks like this:

include_path = os.path.join(os.path.dirname(self.blueprint), match)

What if the value of match there is ../../../etc/passwd? Is there some sort of sanity check that makes sure this code can't be made to include arbitrary files on the file system?

It might be best to use Django's safe_join and raise a SuspiciousOperation exception if the absolute path of the included file is outside of the django project's directory.

This might be built in to drafter, but it's not obvious that a) it is and b) it can be trusted to be there forever.

@chris48s
Copy link
Owner

What if the value of match there is ../../../etc/passwd?

Interesting.. For use in WhereDIV (just rendering our own templates), if that is in the file then I put it there so I'm not too worried about it in that context. In principle, if you were to accept a user-uploaded api blueprint file and then render that, then there is a potential directory traversal vulnerability there.

It might be best to use Django's safe_join and raise a SuspiciousOperation exception if the absolute path of the included file is outside of the django project's directory.

Yep - sounds like a good plan..

This might be built in to drafter, but it's not obvious that a) it is and b) it can be trusted to be there forever.

It isn't - as noted in the readme, the include directive isn't part of the API blueprint spec (hence I'm implementing it myself here)

@chris48s
Copy link
Owner

Thinking about this in slightly more detail, it is probably sensible to make processing includes a configurable option and document that it should be off if accepting unsanitised user input. Even if you limit the paths as you've suggested, there's still potential for bad stuff to happen (e.g: including your django settings files). I don't think there's a safe way to do it.. You could whitelists paths or extensions but it probably makes sense to just enable processing include directives if you trust your input and disable it if you don't..

@symroe
Copy link
Author

symroe commented Aug 23, 2017

Maybe you could piggyback on Django's get_template to make sure that the file is only in one of the paths the template loaders recognise?

But yes, I agree that it's a good idea to have an option to disable it.

Also, noted that this is content from known contributors in most cases, but it's generally good for the software to think about human error as well as humans…

@chris48s
Copy link
Owner

chris48s commented Oct 3, 2017

Fixed in version 1.1.0

@chris48s chris48s closed this as completed Oct 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants