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

gRPC Support #7695

Open
1 task
kingthorin opened this issue Jan 17, 2023 · 17 comments
Open
1 task

gRPC Support #7695

kingthorin opened this issue Jan 17, 2023 · 17 comments

Comments

@kingthorin
Copy link
Member

Is your feature request related to a problem? Please describe.

ZAP doesn't currently have gRPC support out of the box.

Describe the solution you'd like

gRPC requests should already be shown in the History / Sites tree as binary requests.
This means that someone would need to:

  • Implement a body view/editor
  • Implement a variant
  • Add fuzzing support
  • Implement a set of ascan rules which specifically target gRPC requests, e.g.
    • changing types
    • trying to call other classes / methods

Describe alternatives you've considered

N/A

Screenshots

N/A

Additional context

N/A

Would you like to help fix this issue?

  • Yes
@kingthorin
Copy link
Member Author

Marking as GSoC-Candidate for the time being. We'll have to discuss further I guess.

@kingthorin
Copy link
Member Author

kingthorin commented Jan 17, 2023

This probably isn't a perfect solution, but it could help getting the view sorted out/implemented:

The 3rd party JWT add-on also has views and fuzzing support which may help as examples:

@ArkaprabhaChakraborty
Copy link
Contributor

ArkaprabhaChakraborty commented Jan 17, 2023

I just discussed this! Good to see it's here! WooHoo!

Edit: the "just" is still maybe 5 hours ago probably :P

@aryangupta701
Copy link
Contributor

Thank you for the resources. I will begin my research on it soon.

@adwait-godbole
Copy link

Looking forward to contributing to ZAP this year in GSoC, thank you for the resources.

@amitpanwar789
Copy link
Contributor

Hi! I'm very interested in participating in this project for GSoC 2024 and would love to discuss it further. Do you prefer I ask my questions here or reach out via email?

@psiinon
Copy link
Member

psiinon commented Feb 13, 2024

@amitpanwar789 great! Here is best for general questions about the project, but you can also reach out to use via zaproxy-admin@googlegroups.com

@amitpanwar789
Copy link
Contributor

@psiinon I've been digging into body view and editor implementation first. To tackle the entire decoding and encoding process, I think we can take reference from https://github.com/protocolbuffers/protoscope it is written in go. and do we need to code whole thing in java or there any similar tools specifically designed for Java that we should consider?

@kingthorin
Copy link
Member Author

Something like: https://github.com/grpc/grpc-java might help, but that's kinda part of the work/design. I don't think anyone in the core team has done much research on this 🤷‍♂️

@ArkaprabhaChakraborty
Copy link
Contributor

ArkaprabhaChakraborty commented Feb 13, 2024 via email

@psiinon
Copy link
Member

psiinon commented Feb 13, 2024

@psiinon I've been digging into body view and editor implementation first. To tackle the entire decoding and encoding process, I think we can take reference from https://github.com/protocolbuffers/protoscope it is written in go. and do we need to code whole thing in java or there any similar tools specifically designed for Java that we should consider?

ZAP only has one real runtime dependency - Java, and we want to keep it that way. We're ok using other technologies but we dont want any more runtime dependencies. And we want to be able to support anything that has the right JVM on it. This makes using other techs hard...

@ricekot
Copy link
Member

ricekot commented Feb 13, 2024

Rather than the GUI, I would recommend starting with writing a Variant class. In my opinion that would have the greatest ROI in terms of time spent on the feature versus what it has to offer. With HTTP/2 support, ZAP can already proxy gRPC calls, but a variant would allow it to also replay them with payloads injected in the right locations in the request body.

For reference / examples, see:

@amitpanwar789
Copy link
Contributor

@psiinon I've been digging into body view and editor implementation first. To tackle the entire decoding and encoding process, I think we can take reference from https://github.com/protocolbuffers/protoscope it is written in go. and do we need to code whole thing in java or there any similar tools specifically designed for Java that we should consider?

ZAP only has one real runtime dependency - Java, and we want to keep it that way. We're ok using other technologies but we dont want any more runtime dependencies. And we want to be able to support anything that has the right JVM on it. This makes using other techs hard...

so then we can implement the whole decoding and encoding part in java or let me go through https://github.com/grpc/grpc-java .

@amitpanwar789
Copy link
Contributor

amitpanwar789 commented Feb 13, 2024

Rather than the GUI, I would recommend starting with writing a Variant class. In my opinion that would have the greatest ROI in terms of time spent on the feature versus what it has to offer. With HTTP/2 support, ZAP can already proxy gRPC calls, but a variant would allow it to also replay them with payloads injected in the right locations in the request body.

For reference / examples, see:

Sure, I'll start by implementing it. I think if we decode grpc message properly we can use the tag(which consist of fieldnumber and wiretype) as name and value_field as value maybe like in json . I'll go through the GraphQL implementation and reach out for further clarification. Thanks!

@amitpanwar789
Copy link
Contributor

amitpanwar789 commented Feb 19, 2024

I have been going through the active scan functionality of ZAP and trying to understand its variants for different formats. One doubt I have pertains to gRPC. I understand that the variant will get or set (something like) parameter in which ZAP scan rule will assign different payloads (scan rules) as values for different keys according to parameters. I think this can be done by encoding the response body every time we call setParameter method of the variant before making the request.

However, since gRPC communicates using binary format, when we receive a response back for the payload, we need to first convert it into a simpler format so that ZAP's scan rule can comprehend it. I am unsure about how we will perform this conversion for the response body as this is handled by individual scan rule, as each scan rule has its own way of interpreting the response body. we can't make changes to every scan rule file like add code to convert it in simple format, maybe.

@kingthorin
Copy link
Member Author

kingthorin commented Feb 19, 2024

It might have to be more like WebSocket support. First deal with views, then fuzzing, then passive scanning, and finally active 🤷‍♂️

Edit: I know someone suggested starting with the variant but maybe you've just discovered that isn't a practical way to proceed.

@amitpanwar789
Copy link
Contributor

amitpanwar789 commented Mar 6, 2024

Hey @psiinon @thc202 , I have wrote some code for protocol buffer message decoding, can you please look on it and give some early feedback https://github.com/amitpanwar789/Sample_grpc_support/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

8 participants