Page 50 - MSDN Magazine, November 2017

Configuring the Query
Debugging Check
Because a debugger can be attached to the Client at any time during its execution, the Login Debugging Check alone is insufficient. The Query Debugging Check fills this gap by checking for a debugger when the app is about to query sensitive data, such as credit card numbers. The sensitivity of this data also means I can’t afford to separate the detection, reporting and response as with the Login Debugging Check, because that would let an attacker see the data. Instead, the Query Debugging Check will report the incident and then immediately exit the app when a debugger is detected.
I added the second Debugging Check the same way I added the first one, but this time, I config- ured the Check as seen in Figure 4.
Locations: There are three
kinds of sensitive data in my
scenario: e-mail addresses, phone
numbers and credit cards. Luckily,
you can select multiple loca-
tions for a single Check. In
this case, those locations are EmailWindow.UpdateData, PhoneWindow.UpdatePhones and CreditCardWindow.Update- Data. The Check runs whenever any of these are called, which means I have to configure only one set of Check Properties for all three kinds of sensitive data.
Application Notification: Having multiple locations modifies how the Application Notification Sink works. In the Login Debug- ging Check, I could specify the LoginDialog.isDebugged field as the Sink, because that field was accessible from the Check’s only location, LoginDialog.ConfirmLogin. This time, each location must be able to access a Sink.
Figure 3 Configuration for the Login Debugging Check
Figure 4 Configuration for the Query Debugging Check Showing the CreditCardWindow.UpdateData Location—Other Locations Aren’t Shown
// In EmailWindow class
private void ReportDebugging(bool isDebugging) {
if (isDebugging) {
ClientAppInsights.TelemetryClient.TrackEvent(
"Debugger Detected when Querying Sensitive Data",
new Dictionary<string, string> { { "Query", "Email Addresses" } });
ClientAppInsights.Shutdown(); }
}
When the app calls the EmailWindow.UpdateData method, the Check runs and then calls this ReportDebugging method with
Notably, if the Application- NotificationSinkOwner property is blank, the Sink defaults to using the type that defines the Check’s location. Because this Check has multiple locations, the Sink will thus vary depending on the loca- tion that triggered the Check. In this case, I left this property blank and set the other ApplicationNotifi- cationSink properties to a method named ReportDebugging.
Consider the EmailWindow.Re- portDebugging method:
Figure 5 Configuration for the Tamper Check Showing the LoginDialog.ConfirmLogin Location—Other Locations Aren’t Shown
46 msdn magazine
Security