internal/appsec: add support for http.request.path_params address #1106
Conversation
Hellzy
force-pushed
the
francois.mazeau/appsec-http-path-params
branch
from
f07f24e to
0b84c4e
Compare
Hellzy
changed the title
Julio-Guerra
changed the base branch from
julio.guerra/appsec-event-span-tags
to
julio.guerra/appsec-http-status-code-address
Hellzy
force-pushed
the
francois.mazeau/appsec-http-path-params
branch
from
0b84c4e to
05a98ab
Compare
|
Rebased on |
Julio-Guerra
force-pushed
the
julio.guerra/appsec-http-status-code-address
branch
2 times, most recently
from
9f7b023 to
91767d3
Compare
…dress Add an "optional" parameter to httpsec.MakeHandlerOperationArgs to keep track of the name/values map for path params since the data is not retrievable through http.Request. Also edit waf_test.go to add a small test to check e2e soundness.
Add an AppSecParam field to router trace config to pass parameters to AppSec wrap handler that can't be retrieved from request only. This allows in this case to pass down path parameters. Also add waf_test.go to check e2e soundness.
Julio-Guerra
force-pushed
the
francois.mazeau/appsec-http-path-params
branch
from
05a98ab to
bc9b9b2
Compare
contrib/net/http/trace.go
Outdated
| @@ -28,6 +28,9 @@ type ServeConfig struct { | |||
| Resource string | |||
| // QueryParams specifies any query parameters that be appended to the resulting "http.url" tag. | |||
| QueryParams bool | |||
| // RouteParams specifies framework-specific route parameters (e.g. for route /user/:id coming | |||
| // in as /user/123 we'll have {"id": "123"}). This field is optional and monitored by appsec. | |||
There was a problem hiding this comment.
| // in as /user/123 we'll have {"id": "123"}). This field is optional and monitored by appsec. | |
| // in as /user/123 we'll have {"id": "123"}). This field is optional and is used for monitoring | |
| // by AppSec. |
It's also worth mentioning that it's used specifically for that. In the current form we are saying that it's "monitored by appsec" but it's not clear if it has other uses to.
Is there any point in mentioning more details, as in how AppSec monitors these? I'm thinking that maybe some people who may be using TraceAndServe independently for their own handlers, might be able to benefit from AppSec by using these fields with some other framework which is not supported by us. Is it also worth mentioning that AppSec must be enabled for these to be taken into consideration? For example: if someone passes RouteParams but has AppSec disabled, will it be taken into account?
There was a problem hiding this comment.
I did a simple addition here: 7ff222d
No need to further explain how AppSec monitors them, as it depends on the security rules, that are exposed and detailed in our UI.
This set of commits adds support for the http.request.path_params address in AppSec.
Add a field to tracer config to relay data that AppSec can't necessarily retrieve through the http.Request framework context only. This is used for Gorilla specifically, to pass URL variables down to the tracer and in turn to httpsec.
Pass the path parameters down to the waf and add a case to run matching on the new address
Add/Edit existing tests to make sure the path parameters can be caught/retrieved and trigger the waf matches as expected.
Support Echo
Support Gorilla
Note: no support for net/http (framework doesn't handle path parameters)