-
Notifications
You must be signed in to change notification settings - Fork 68
Tilee/fix sdl injection bug #810
Changes from all commits
c5a5189
4727852
3801881
a0f7017
58d370e
347cfd5
3454d9e
a4c3475
115923f
499ddd8
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 |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| namespace Microsoft.ApplicationInsights.Common | ||
| { | ||
| /// <summary> | ||
| /// These values are listed to guard against malicious injections by limiting the max size allowed in an HTTP Response. | ||
| /// These max limits are intentionally exaggerated to allow for unexpected responses, while still guarding against unreasonably large responses. | ||
| /// Example: While a 32 character response may be expected, 50 characters may be permitted while a 10,000 character response would be unreasonable and malicious. | ||
| /// </summary> | ||
| public static class InjectionGuardConstants | ||
| { | ||
| /// <summary> | ||
| /// Max length of AppId allowed in response from Breeze. | ||
| /// </summary> | ||
| public const int AppIdMaxLengeth = 50; | ||
|
|
||
| /// <summary> | ||
| /// Max length of incoming Request Header value allowed. | ||
| /// </summary> | ||
| public const int RequestHeaderMaxLength = 1024; | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| namespace Microsoft.ApplicationInsights.Common | ||
| { | ||
| using System.Diagnostics; | ||
|
|
||
| /// <summary> | ||
| /// Generic functions to perform common operations on a string. | ||
| /// </summary> | ||
| public static class StringUtilities | ||
| { | ||
| /// <summary> | ||
| /// Check a strings length and trim to a max length if needed. | ||
| /// </summary> | ||
| public static string EnforceMaxLength(string input, int maxLength) | ||
| { | ||
| Debug.Assert(input != null, $"{nameof(input)} must not be null"); | ||
| Debug.Assert(maxLength > 0, $"{nameof(maxLength)} must be greater than 0"); | ||
|
|
||
| if (input != null && input.Length > maxLength) | ||
|
Member
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. We seem to have assert on maxLength > 0 but still execute code with that value - is it intentional?
Author
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. I saw this design pattern used in other places.
Author
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. Discussed with Dmitry offline. |
||
| { | ||
| input = input.Substring(0, maxLength); | ||
| } | ||
|
|
||
| return input; | ||
| } | ||
| } | ||
| } | ||
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.
Should we just drop the AppId if it does not satisfy the expected length and/or format? However, let's see if it's actually consuming less resources than to pass it around after it's been cut to MaxLength and write once into the item.
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.
I don't understand your "less resources" comment.
If we drop the AppId, the sdk will keep making appId requests (after brief timeout). I think either approach could be valid, but lets discuss what's best for this use case.
Uh oh!
There was an error while loading. Please reload this page.
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.
There are two ways we can go about appId if we think it's wrong (e.g. does not satisfy length or format):
Both cases have their own pros, so I was interested in which one is "cheaper" from CPU/Memory perspective - trying out for new appId or keep re-using the wrong one on related code paths.
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.
Discussed offline with Dmitry.
We are deciding to truncate the value and accept it as is.
Assuming that if an attacker injected a fraudulent value, that attacker would continue to inject fraudulent values on retry attempts. Best to quit and wait until app pool recycles to try again.