Page 48 - MSDN Magazine, November 2017

Figure 2 shows a bird’s-eye view of the Checks and the app code with which they interact. In the next three sections, I’ll explain the purpose and configuration of each of these Checks.
Configuring the Login Debugging Check
This first Debugging Check addresses the session hijacking sce- nario. It detects if a debugger is present during the authentication process and notifies the app if so. The app will report the incident to Application Insights and then later error in unintuitive ways.
I added this Check by clicking on the Add Debugging Check button, which brought up a new configuration window. I config- ured this Check as seen in Figure 3.
Location: I first picked where in the app code the Check should run. As this Check should detect debugging when the user logs in, I checked the LoginDialog.ConfirmLogin method from the Locations tree.
Note that the Check only runs when its location is called. If an attacker attaches a debugger later, this Check won’t detect it; but I’ll address this issue later with the Query Debugging Check.
Application Notification: After a Check runs, it can notify the app code so the app can report and react in a customized way. The code element that receives this notification is known as the Application Notification Sink, and is configured using the fol- lowing Check Properties:
• ApplicationNotificationSinkElement: The kind of code element (field, method and so on)
• ApplicationNotificationSinkName: The name of the code element
// In LoginDialog class
private void RunUserSession(AuthToken authToken) {
// ...
var customerWindow = new Windows.CustomerWindow(clients, isDebugged); // ...
}
Then, I made the CustomerWindow constructor set its own field, CustomerWindow.isDebugged, and then report the incident to Application Insights:
// In CustomerWindow class
public CustomerWindow(Clients clients, bool isDebugged) {
// ...
this.isDebugged = isDebugged; if (isDebugged)
{
// ClientAppInsights is a static class holding the Application // Insights telemetry client ClientAppInsights.TelemetryClient.TrackEvent(
"Debugger Detected at Login"); }
// ... }
Finally, I added code that reads this field to various event handlers. For instance:
// In CustomerWindow class
private void FilterButton_OnClick(object sender, RoutedEventArgs e) {
// ...
if (isDebugged) { throw new InvalidCastException(); } // ...
}
I’ll address the obviousness of the field name isDebugged later in this article.
• ApplicationNotificationSinkOwner: The type that defines the code element For all three Checks, I used this feature to report incidents to Application Insights. Additionally, for this Check, I decided that I wanted a custom response rather than a default response injected by Dotfuscator (which the other Checks will use). My response allows the login to succeed, but then crashes the app a few moments later. By separating the detection and response, I make it harder for an attacker
to discover and work around the control.
To accomplish this response, I added a Boolean field, isDebugged, to the Login- Dialog class and configured it as the Check’s Sink. When the Check runs (that is, when the app calls LoginDialog.ConfirmLogin), the result of the debugger detection is stored in this field: true for a debugger detected, and
false otherwise.
Note that the Sink must be accessible and
writable from the Check’s location. As both the location and Sink are instance members of the LoginDialog class, this rule is satisfied.
Next, I modified LoginDialog.RunUser- Session to pass this field to the Customer- Window constructor:
Data Flow
Control Flow
Sales Service
Sales Client
Entry Point
Login Dialog
Customer Window
Phone Window
Injected Check Location
SQL Database
Application Insights
Login Debugging Check
If debugger detected, report the incident and continue, but error in Customer Window.
Tamper Check
If modified binary detected, report the incident then exit the app.
E-mail Window
Credit Card Window
Query Debugging Check
If debugger detected, report the incident (with the associated query) then exit the app.
Utilities
(Helper methods called throughout the app.)
44 msdn magazine
Security
Figure 2 The Sales Client with Injected Runtime Checks