Some targets may require CSRF tokens in order to properly process requests. With the current shellfire implementation, assigning token value to the outgoing request would need to be done manually (assuming it changes with each request).
Example One:
- Response 1 returns a
Set-Cookie header that modifies the csrftoken cookie value
- The server expects the updated
csrftoken cookie to be present in the next request, but the request fails due to an invalid value.
Example Two:
- Response 1 returns a
X-CSRF-TOKEN header that modifies the existing value.
- The server expects the new
X-CSRF-TOKEN header in the next request, but the request fails due to an invalid value.
Ideally a mechanism would be put in place that supports sessions with a lifespan of at least the duration of the shellfire process itself. Since the utility is utilizing the requests library, it makes sense to instantiate a Session Object that is shared within the context of the active target session.
This mechanism should also allow the user to watch for specific HTTP response headers and change behavior or configuration if a match or value is found - think X-CSRF-TOKEN. The ideal candidate for this would be to utilize the Requests Event Hooks API and wrap it in the plugin system that is currently located in the experimental branch.
Some targets may require CSRF tokens in order to properly process requests. With the current shellfire implementation, assigning token value to the outgoing request would need to be done manually (assuming it changes with each request).
Example One:
Set-Cookieheader that modifies thecsrftokencookie valuecsrftokencookie to be present in the next request, but the request fails due to an invalid value.Example Two:
X-CSRF-TOKENheader that modifies the existing value.X-CSRF-TOKENheader in the next request, but the request fails due to an invalid value.Ideally a mechanism would be put in place that supports sessions with a lifespan of at least the duration of the shellfire process itself. Since the utility is utilizing the requests library, it makes sense to instantiate a Session Object that is shared within the context of the active target session.
This mechanism should also allow the user to watch for specific HTTP response headers and change behavior or configuration if a match or value is found - think
X-CSRF-TOKEN. The ideal candidate for this would be to utilize the Requests Event Hooks API and wrap it in the plugin system that is currently located in theexperimentalbranch.