Add Square Credentials Dynamic Validator#515
Conversation
Bpendragon
commented
Jul 29, 2021
- Adds a Dynamic Stripe Validator
- Adds a DynamicStripeValidatopr_Test class as well.
Ran BuildAndTest.cmd
|
|
||
| const string uri = "https://connect.squareup.com/oauth2/token"; | ||
| const string CodeNotFoundMessage = "Authorization code not found"; | ||
| const string CodeForRequest = "123"; |
There was a problem hiding this comment.
- order by string length
- Code* starts with uppercase and uri lowercase. Make everything lowercase, pls #Closed
There was a problem hiding this comment.
Fixed in iteration 3
| dict.Add("grant_type", "authorization_code"); | ||
| dict.Add("code", CodeForRequest); // Needs some value for call to work. | ||
| dict.Add("client_id", id); | ||
| dict.Add("client_secret", secret); |
There was a problem hiding this comment.
you can auto-initialize and order by string length #Closed
There was a problem hiding this comment.
Fixed in iteration 3
| .GetAwaiter() | ||
| .GetResult(); | ||
|
|
||
| string res = response.Content.ReadAsStringAsync().Result; // Actually runs synchronously when "Result" is called. |
There was a problem hiding this comment.
Fixed in iteration 3
| { | ||
| case HttpStatusCode.OK: | ||
| { | ||
| return ValidationState.Authorized; // This should theoretically never be hit, a "code" of 123 is much too short. But if we do get a 200, it's a valid Credential. |
There was a problem hiding this comment.
add the comments before the return and break in multiple lines #Closed
There was a problem hiding this comment.
Fixed in iteration 3
|
|
||
| // Credential not valid. | ||
| return ValidationState.Unauthorized; | ||
| } |
There was a problem hiding this comment.
add a new line here #Closed
There was a problem hiding this comment.
Fixed in iteration 3
| { | ||
| return ReturnUnhandledException(ref message, e); | ||
| } | ||
|
|
There was a problem hiding this comment.
remove extra new line #Closed
| var keyValuePairs = new Dictionary<string, string>(); | ||
|
|
||
| SquareCredentialsValidator.IsValidDynamic(ref fingerprint, | ||
| ref message, |
There was a problem hiding this comment.
[](http://example.com/codeflow?start=0&length=58)
align with the first argument #Resolved
There was a problem hiding this comment.
Resolved in iteration 4
| .GetAwaiter() | ||
| .GetResult(); | ||
|
|
||
| string res = response.Content.ReadAsStringAsync().Result; // Actually runs synchronously when "Result" is called. |
There was a problem hiding this comment.
Fixed in iteration 3
|
|
||
| try | ||
| { | ||
| HttpClient client = CreateHttpClient(); |
There was a problem hiding this comment.
let's rename in a new pr. but, yes, we should rename it :)
| // This should theoretically never be hit, a "code" of 123 is much too short. | ||
| // But if we do get a 200, it's a valid Credential. | ||
| return ValidationState.Authorized; | ||
| } |
There was a problem hiding this comment.
You need to have the courage of your comment's convictions here. If this code should never be hit, you should be throwing an exception or throwing an error condition.
Since I agree with you this code shouldn't be hit, it seems like any execution through this code path, in fact, would be a bug and not flag an actual find.
In general, it doesn't help us to code defensively. Instead, aggressively fail unexpected code paths and our test process (if we are testing properly) should flush those out. #Resolved
There was a problem hiding this comment.
My specific suggestion is to use unexpected response code for this code path. Because that's what it is, right?
There was a problem hiding this comment.
Makes sense, just going to remove the block entirely and we can have it fall to 'Unexpected Response Code'
| .ReadAsStringAsync() | ||
| .GetAwaiter() | ||
| .GetResult(); | ||
| if (content.Contains(codeNotFoundMessage)) |
| Dictionary<string, string> options, | ||
| ref ResultLevelKind resultLevelKind) | ||
| { | ||
| string id = fingerprint.Id; |
There was a problem hiding this comment.
It looks like this code doesn't return any asset information, i.e., the identifier for the compromised thing. Please see other rules for examples of proper reporting. I think 'id' is the thing we should be surfacing that we are not.
Please make sure to review actual user-facing strings returned by this change.
@eddynaka, enough is enough: we need proper unit and functional testing that forces testing through the dynamic validation piece. :)
There was a problem hiding this comment.
We need to report the id for this code path but can delay getting the additional testing out there. But the very next thing we should do is implement an approach for this.
Basically, for every dynamic validator, we need a way to exercise/validate all possible code paths. This will be tricky/likely require a mocked HTTP client/other things to accomplish.
There was a problem hiding this comment.
Added asset information to retrun messages.
There was a problem hiding this comment.
Can you provide an example of what the user-facing string looks like for authorized/unauthorized access? I think there's another overload for some helpers that allow you to provide a descriptor of the id, when helpful. to clarify the output. So looking at current example would help understand whether we need to do something like that.
There was a problem hiding this comment.
For successfully validating the response is
The compromised asset is 'a'
For a credential that doesn't validate it's
The provided secret is not authorized to access 'a'.
In both cases 'a' is replaced with the client_id of the Square app that was detected. (which normally looks like sq0idp-<alphanumeric-identifier>
…com/microsoft/sarif-pattern-matcher into users/bpendragon/AddStripeValidator