gRPC Support

[kingthorin]

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

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

• https://grpc.io/
• https://en.wikipedia.org/wiki/GRPC
• https://github.com/grpc/grpc (Does point to a Java library that may be on benefit)
• https://cloud.google.com/blog/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them

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
  • Extend view/editor to work with WebSocket comms as well. (To support things like: https://github.com/Cysharp/GrpcWebSocketBridge per gRPC Support #7695 (comment))

  Streamlit, a very popular Python framework, uses protocol buffers over websockets

• 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]

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

[kingthorin]

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

• https://www.gosecure.net/blog/2021/04/13/creating-a-custom-view-for-websocket-in-zap/

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

• https://github.com/SasanLabs/owasp-zap-jwt-addon
• https://www.zaproxy.org/blog/2020-09-03-zap-jwt-scanner/

[ArkaprabhaChakraborty]

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

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

[aryangupta701]

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

[adwait-godbole]

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

[amitpanwar789]

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]

@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]

@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]

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]

How about using postman on an gRPC API to get some good UI ideas?

[psiinon]

@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]

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:

• GraphQL Variant: https://github.com/zaproxy/zap-extensions/blob/main/addOns/graphql/src/main/java/org/zaproxy/addon/graphql/VariantGraphQl.java
• SOAP Variant: https://github.com/zaproxy/zap-extensions/blob/main/addOns/soap/src/main/java/org/zaproxy/zap/extension/soap/VariantSoap.java

[amitpanwar789]

@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]

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:

• GraphQL Variant: https://github.com/zaproxy/zap-extensions/blob/main/addOns/graphql/src/main/java/org/zaproxy/addon/graphql/VariantGraphQl.java
• SOAP Variant: https://github.com/zaproxy/zap-extensions/blob/main/addOns/soap/src/main/java/org/zaproxy/zap/extension/soap/VariantSoap.java

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]

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]

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]

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/

[sylwia-budzynska]

Hello! I just saw the announcement about the gRPC add-on being released. Congrats on the release, this is a great add-on to have in ZAP 🙏

I was wondering - are there any plans to have it enabled also on websocket messages? So far I can see it is possible to use it on HTTP messages, but not on websockets.

[kingthorin]

@sylwia-budzynska do you have specific sites/implementations/frameworks in mind?

[sylwia-budzynska]

@kingthorin Streamlit, a very popular Python framework, uses protocol buffers over websockets