Along with this discussion forum, we also provide a traffic analysis tool (called BRM Traffic Analyzer), which can be very helpful in the analysis of an SSO mechanism. To understand that why the BRM Traffic Analyzer is valuable, it is strongly recommended that you read our paper, which detaily described how the BRM analyzer was used to uncover a number of significant SSO flaws in Facebook, Google, and other serious websites. After reading the paper, you can start to follow this documentation to learn how to use this tool.
How to use the traffic analyzer?
Step 1: capture raw web traffic of the SSO mechanism
The first step is to capture the raw web traffic of an SSO mechanism. There are a lot of 3rd party tools which can be used to capture the raw traffic, such as Live HTTP Headers, Fiddler, and others. Currently, our BRM Analyzer supports the output format of Live HTTP headers. We will soon include the support for Fiddler.
Capture the traffic using Live HTTP Headers
Live HTTP Headers is an addon for Firefox browser. After installing it on Firefox, go to the website from which we want to capture the traffic. Then choose "Tools->Live HTTP headers" from the menu. A traffic capturing window will pop up, and begins recording all traffic going through the browser. You can then do the SSO login in the browser. After this is done, we come back to the window, and deselect 'Capture' checkbox, which stops Live HTTP headers record extra unnecessary traffic. Then we click "Save All..." to save the traffic to a file. Feel free to use any file name. Our recommendation is something like "google-a.com-user1machine1test1.txt", meaning that this traffic file is captured on testing a.com's using of google ID with user 1, machine 1. Because Live HTTP headers will record all traffic of the browser, so it is good to close all other webpages before the test to avoid noise traffic.
The BRM Analyzer requires at least three traffic files. To capture the traffic, you need to register two user accounts on the identity provider, which we call User1 and User2. Then you start the browser, log User1 into the identity provider website (i.e., google). Keep you identity provider website in login status during the whole test. Then we start the traffic capture, do an SSO login, and save the traffic to a file. The second traffic is a repeat of the first test. A simple way is to log out the user from relying party website, and do the SSO login again while recording. The third traffic is also simple: just replace User1 with User2, and redo the SSO login.
Step 2: upload web traffic, and generate SSO model
Once the traffic files are generated, you can upload them through this webpage.
By following a simple wizard, you should be able to generate the SSO model, which can be viewed from viewModel.html with corresponding arguments. More specifically, this web API supports the arguments shown below. An argument name ends with a "*" means it is required.
modelFile*: the file name of the model. It will be automatically generated by the wizard.
showFormatLabel: boolean to determine that whether to show the format of data fields
showSemanticLabels: boolean to determine that whether to show the semantic labels
showAccessLabels: which access labels to show. There are three types of access labels: MaliciousBrowser, MaliciousRP, and MaliciousSite. If you don't want to show any labels, set this value to be None.
accessLabelType: the type of access labels to show. You can choose among "readable", "writable", and "both".
disableEditing: boolean to determine whether to disable user editing of the model.
showRawTrafficLink: boolean to determine whether to show the download links to raw traffic files
Step 3: edit the model
The generated model is derived from our BRM Analyzer with three pieces of raw web traffic. Human analyst can then improve this model by incorporating more human knowledge. You are provided with following editing capabilities:
Step 4: find attack cases with BRM Analyzer
You can then open a thread here to discuss the SSO mechanism with others. By including the link to your model in the thread, others can understand the SSO mechanism more easily. If they think they know a piece of knowledge of the model, they can quickly edit the model to incorporate that knowledge. Once their editing is done, everyone can see their change immediately.