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

graphql: Add tech detection for GraphQL Engines #5843

Merged
merged 1 commit into from
Dec 14, 2024

Conversation

kingthorin
Copy link
Member

@kingthorin kingthorin commented Oct 23, 2024

Overview

  • CHANGELOG > Added note.
  • build file > Added dependency.
  • GraphQlFingerprinter > Updated to add Technology matches when GraphQL engines are fingerprinted.
  • GraphQlFingerprinterUnitTest > Updated for new handling.
  • DiscoveredGraphQlEngineHandler > An interface to be implemented for consumption/handling of discovered GraphQL engines.
  • ExtensionTechDetection > Added to facilitate optional dependence.
  • ExtensionTechDetectionUnitTest > Tests :)
  • Messages.properties > Added key/value pairs to support the optional dependency.
  • alert.html > Added note about the new functionality.

Ex: See the Apollo entry:
image

This seems to be a decent place for testing: https://countries.trevorblades.com/graphql
(Note if you do serial imports you will hit a limit and need to wait a min or so.)

Related Issues

N/A

Checklist

  • Update help
  • Update changelog
  • Run ./gradlew spotlessApply for code formatting
  • Write tests
  • Check code coverage
  • Sign-off commits
  • Squash commits
  • Use a descriptive title

@kingthorin
Copy link
Member Author

I did try adding this to GraphQlFingerprinterUnitTest#shouldFingerprintValidData and verify call to ExtensionWappalyzer.addApplicationsToSite but the best I could do was have it work on the first of the parameterized runs, subsequently it would claim zero interactions with the mock 🤷‍♂️

@kingthorin kingthorin force-pushed the gql-td branch 6 times, most recently from 98ca05d to 5a9f162 Compare October 24, 2024 18:41
@kingthorin
Copy link
Member Author

I should probably add some more tests. But, I'd be glad to have any feedback in the meantime.

@kingthorin kingthorin force-pushed the gql-td branch 3 times, most recently from d8a916e to 7bd1a00 Compare October 25, 2024 15:25
Comment on lines 320 to 323
Object[] arguments = new Object[2];
GraphQlFingerprinter.setAppConsumer(
(site, engine) -> {
arguments[0] = site.toString();
arguments[1] = engine;
});
Copy link
Member Author

Choose a reason for hiding this comment

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

Used an array because of the whole lambda 'must be final or effectively final' restriction.

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess alternatively I could have created an assertion method that accepts the two values?

@kingthorin
Copy link
Member Author

Rebased current and deconflicted.

@kingthorin
Copy link
Member Author

Previous review has been addressed

@kingthorin
Copy link
Member Author

Rebased current and deconflicted, again.

@kingthorin
Copy link
Member Author

Rebased current and deconflicted, yet again.


private final Requestor requestor;
private final Map<String, HttpMessage> queryCache;

private HttpMessage lastQueryMsg;
private String matchedString;
private static BiConsumer<URI, Engine> appConsumer = DEFAULT_APP_CONSUMER;
Copy link
Member

Choose a reason for hiding this comment

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

I know I'm late to review but a few notes on the appConsumer...

  • The Engine (DiscoveredGraphQlEngine?) could include the URI
  • The appConsumer (discoveredEnginesListener?) could be a functional interface.
  • GraphQlFingerprinter could keep a list of listeners instead of a single listener.
  • The raiseFingerPrintingAlert method can also be added as a listener.

This should make the fingerprinter flexible even for future features that rely on GraphQL engines. That being said I'm good with the PR as-is too and this could even be done in a follow-up PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I see the vision. I'll tweak for the first item.

I think I'll hold on the listener implementation for another PR. (This one has been dragging I'd like to just get it merged 😇)

Copy link
Member Author

Choose a reason for hiding this comment

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

Isn't a Consumer already a functional interface? Is there a reason to not just simply use a list of Consumers?

If I'm right it wouldn't be too hard to change for this PR.

Copy link
Member Author

@kingthorin kingthorin Nov 20, 2024

Choose a reason for hiding this comment

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

@ricekot I'm pretty sure I'm right the more I think about this.

I can create List<Consumer> consumers; Instead of the existing default consumer being noop I could turn it into raiseFingerPrintingAlert being the default. If/when the conditions are proper then the Tech Detection consumer can be added. Instead of calling each separately as things currently are I can do something like: consumers.forEach(consumer -> consumer.accept(discoveredGraphQlEngine));

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me.

Copy link
Member

Choose a reason for hiding this comment

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

#5843 (comment)

There are reasons/benefits to use a custom interface rather than Consumer (or any variant of), e.g. if in the future there's the need to add other methods or parameters. If you use Consumer you will not be able to do that, with the custom interface you can rely on default methods.

#5843 (comment)

Never late :) I was not thinking this would be used by/for other purposes in the future, if that's the intent we should expose the functionality through the extension not as static methods in "internal" classes, proper JavaDoc should be added and so on. (Unless you mean as internal functionality?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay I can make a custom interface, thanks for talking through it!

I believe it would only be used 'internally' to the add-on but @ricekot feel free to correct me if you see it differently.

Copy link
Member Author

Choose a reason for hiding this comment

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

Reworked 😀

Copy link
Member

@ricekot ricekot Dec 13, 2024

Choose a reason for hiding this comment

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

Unless you mean as internal functionality?

I meant generally but at the moment I can't think of ways this would be used outside the add-on.

@kingthorin kingthorin force-pushed the gql-td branch 3 times, most recently from d0c49b0 to f64c3ec Compare November 19, 2024 20:45
@kingthorin kingthorin force-pushed the gql-td branch 4 times, most recently from 79e1915 to 29efe57 Compare November 20, 2024 19:11
@kingthorin
Copy link
Member Author

Hey crew, is this implementation better?

@kingthorin
Copy link
Member Author

@ricekot does this implementation seem better?

@kingthorin
Copy link
Member Author

Bump

@psiinon

This comment was marked as outdated.

@kingthorin kingthorin force-pushed the gql-td branch 2 times, most recently from 5488bfd to 558c1bb Compare December 13, 2024 13:26
@kingthorin
Copy link
Member Author

@ricekot got all those.

@thc202 I did tackle all your original comments (I believe) I just didn't resolve them.

@kingthorin
Copy link
Member Author

Feedback addressed.

@thc202
Copy link
Member

thc202 commented Dec 13, 2024

This one still pending #5843 (comment)

- CHANGELOG > Added note.
- build file > Added dependency.
- GraphQlFingerprinter > Updated to add Technology matches when GraphQL
engines are fingerprinted.
- GraphQlFingerprinterUnitTest > Updated for new handling.
- DiscoveredGraphQlEngineHandler > An interface to be implemented for
consumption/handling of discovered GraphQL engines.
- ExtensionTechDetection > Added to facilitate optional dependence.
- ExtensionTechDetectionUnitTest > Tests :)
- Messages.properties > Added key/value pairs to support the optional
dependency.
- alert.html > Added note about the new functionality.

Signed-off-by: kingthorin <kingthorin@users.noreply.github.com>
@kingthorin
Copy link
Member Author

Ok I think I got all those now too.

@thc202
Copy link
Member

thc202 commented Dec 14, 2024

Thank you!

Copy link
Member

@ricekot ricekot left a comment

Choose a reason for hiding this comment

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

Thanks!

@ricekot ricekot merged commit 0e2491b into zaproxy:main Dec 14, 2024
10 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Dec 14, 2024
@kingthorin kingthorin deleted the gql-td branch December 14, 2024 11:46
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants