-
Notifications
You must be signed in to change notification settings - Fork 145
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
[ASM] Context disposed related exceptions when calling the WAF #6529
Changes from 9 commits
fb7e2b7
89a71fa
3574cae
eb62379
059d261
6aa4691
874b3c0
52c48ae
79538c6
059a891
0180f67
6e786c3
bd28929
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,6 +10,7 @@ | |
using Datadog.Trace.AppSec.Waf; | ||
using Datadog.Trace.Logging; | ||
using Datadog.Trace.Util; | ||
|
||
#if !NETFRAMEWORK | ||
using Microsoft.AspNetCore.Http; | ||
#else | ||
|
@@ -45,8 +46,15 @@ internal readonly partial struct SecurityCoordinator | |
|
||
public IResult? RunWaf(Dictionary<string, object> args, bool lastWafCall = false, bool runWithEphemeral = false, bool isRasp = false) | ||
{ | ||
if (_httpTransport.ContextUninitialized) | ||
{ | ||
Log.Debug("Trying to call the WAF with an unitialized context."); | ||
return null; | ||
} | ||
|
||
SecurityReporter.LogAddressIfDebugEnabled(args); | ||
IResult? result = null; | ||
|
||
try | ||
{ | ||
var additiveContext = _httpTransport.GetAdditiveContext(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. isn't the problem potentially still here? If the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that the context can be disposed at anytime while we use it. With this change, we are handling most of the errors that we are encountering, but it could happen what you just mentioned. On the other hand, checking for a disposed context anytime that we use it would have some performance impact and even that could not guarantee 100% that we are not getting more exceptions (if the context is disposed right after checking and before actually using it). We could also try/catch any access to the context features (which includes almost every property associated to the context, request and response). In my first approach, I was doing that, but many code changes were required and, being practical, all the detected exceptions are happening in the same place, so I decided to protect just the problematic section. Do you think that try/catching any access to the context would be a better solution? In the end, we probably will need to do a big refactor of our code to avoid accessing the context so often. |
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we could log here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!