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

Added context to crtsh database query to prevent it from blocking forever if the connection was lost #1190

Merged
merged 2 commits into from Mar 26, 2024

Conversation

UFeindschiff
Copy link
Contributor

The db.Query() call used prior blocks until results have been received. However, if using an unreliable connection (e.g. routing all traffic through Tor), the connection may break, resulting in db.Query() to block forever and as a result for the enumeration to never finish if crtsh was used as a datasource (even if the maximum enumeration time was reached).

This MR is a simple duct-tape fix to query the database with the enumeration context (which is usually a timeout context), so the enumeration will at least always finish after the enumeration timeout was reached. While not a very elegant solution to the problem (we may still be attempting to query a broken connection until the maximum enumeration time is reached), it at least assures that the enumeration actually finishes eventually.

Copy link
Member

@Mzack9999 Mzack9999 left a comment

Choose a reason for hiding this comment

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

lgtm - @UFeindschiff Thanks for this PR, the proposed solution is by no means a dutch tape but a very good fit as it uses native methods and perfectly respect the maximum enumeration timeout without altering the existing functionality

@UFeindschiff
Copy link
Contributor Author

@Mzack9999 I meant duct tape solution in a way that a query may still hang until the context is canceled, which usually means that if the db connection is lost during enumeration, an enumeration will always take the maximum enumeration time. A "proper" solution would be to check every n seconds to see whether the database connection is still alive and if not open a new TCP connection. That however would need to be patched in the postgresql driver.

@ehsandeep ehsandeep merged commit 7df3d9b into projectdiscovery:dev Mar 26, 2024
8 checks passed
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

Successfully merging this pull request may close these issues.

None yet

3 participants