-
Notifications
You must be signed in to change notification settings - Fork 2
Profiling Guide
This is a guide toward putting together the most complete profile for a site possible. Each of these steps can be skipped if not applicable or straightforward, obviously.
The wording in this assumes you've already got a pretty good feel for what profiles normally look like by looking at the other YAML files in https://github.com/opensets/domainprofiles/tree/master/profiles - it's not a complete introduction to everything. When in doubt, consult the canonical documentation, and look for examples in the existing profiles.
Go to the domain being profiled in an incognito window, along with https://github.com/opensets/domainprofiles/new/master/profiles for the domain profile, and sharklasers.com for creating on-the-fly email addresses.
For starters in the file, fill in the site's domain name + .yaml as the file name and the site's name as a name: line.
If the site uses accounts from a different primary domain (ie. Flickr using Yahoo accounts), enter that domain as the profile's use: value and skip ahead to the "Finalize with review date" section.
Find the site's registration page, and put its URL down as a url: value under a registration: section.
Write down if the site has a CAPTCHA on registration (captcha:), as well as a usability: section with an email: for whether they ask for a single or double entry of your email address. (If they allow for a single and/or showable password entry, mark that alongside the email usability as password:.)
Create a password: section in the file, with a rules: subsection underneath it.
If the site lists any password restrictions (specifically allowed ranges for the length), mark them down in a length: section as min: and max:.
If they don't describe any limitations, see if you can submit the registration with the password field(s) empty: if the response is rejected, they have a minimum password length of at least 1 character. If the error only comes back as "Password can't be blank", try entering a single space. If that doesn't give a different error listing the minimum size, they probably have bad space handling: try just 'a'. If there still isn't a clearer description of the password being too short, try entering 'aa' and so on until the password isn't rejected for being too short.
(If the password ends up getting accepted, further steps here can be revisited when profiling the password change facilities: it can also be profiled by creating a new sharklasers email and trying account creation again.)
Try passwords consisting entirely of spaces (some sites can't handle this, meaning the rules need to have a contain: section with - nonletters: 1 at least). Try passwords with only the character a (this is usually enough to detect if the site demands a certain amount of complexity). Try passwords starting with a a (this will detect if the site can't handle spaces in passwords, meaning a blacklist: section with a - spaces item). Try other naughty strings to test for other blacklisted values.
If the site doesn't list a maximum password length, right-click the password input, select "Inspect element", and enter $0.value='Aa'+new Array(9001).join('A') to fill it with a password over nine thousand characters long. (If this password isn't rejected, it's possible the site legitimately does not limit password lengths, and you can leave the min: field out of password.rules.length.)
Write down any other rules about how passwords must or must not be as must: and mustnot: sections, where each item is in a list prefixed with en: (for example, if the rule is in English).
This basically works the same way as password vetting above. Usually, sites will be more forthcoming with username restrictions, but some vetting procedures may be necessary. Follow the procedure above, but for a rules: subsection under username: instead of password:.
Find the page where you can change your password once you're logged in and create a change: subsection under the password: section. Write the URL of the page for changing the password as the url: value for this section (adding a hash fragment for the section of the page dealing with passwords, if there's an ID for it and the page concerns many other settings).
If you have to reenter your old password to change your password, add reauth: password to this subsection: if not, add reauth: no.
If the page accepts a single or showable password input, put this down as a password: field in a usability: subsection of this change: section.
(If you want to be really rigorous, see the bit about "Testing session invalidation" below when making a password change.)
Find the site's "forgot password" page, and put its URL down as a url: value under a reset: subsection of the password: section.
Make a request: subsection of this subsection for profiling the initial password reset request. If the site accepts an email address to send a password reset email to, add an accepts: email value. If the site accepts a username, use accepts: username, or accepts: email username if it accepts either (or accepts: username+email in the rare case that it requires both). Also include a captcha field if the site requires a CAPTCHA to request a password reset.
Once the password reset response comes, create a response: subsection of password.reset, with a sender: field containing the address the email comes from, and a body: field describing the things included in the email (like url for a URL to visit, or link for an opaque link to click, without a URL).
Once you've clicked through, add a steps: list, detailing that you change the password, and if the site then presents you with a stub, a form to login, or if resetting the password performs an autologin (or if that autologin occurs before the change).
If the site mentions at what point its password reset tokens expire, create an expiration: subsection under reset:, and write the value down as timeout: 48h (for example, if the timeout is 48 hours).
If the site has a page for sending the user a reminder of their username (separate from password reset), create a subsection under username: for reminder: and list the URL of the page there.
Follow the rules above for the password reset request: section, but under the username.reminder subsection.
Find the site's login page, and put its URL down as a url: value under a login: section.
If the site has a checkbox for keeping the user logged in, make a persist: subsection, and add checked: yes or checked: no to describe that checkbox's default value.
If the site's login form allows for the password to be shown, create a usability: subsection and add password: showable to it.
See the documentation in docs/fields.md about:
- thirdparty.auth.providers
- sessions.management.url
- api.key.retrieval.url
- report.beach.url
- totp
- questions
You can describe any non-form-fitting behaviors with a notes: section within any section, and can describe particularly dangerous-looking behaviors under a redflags: section. (Remember that these should be in the form of an array of objects for localizable statements, with a field for the language the statement is drafted in, eg - en: Site shows your password to anybody who looks up your email.)
Log in with multiple browsers simultaneously (make sure different incognito windows in the same browser aren't sharing cookies / sessions) and try changing and/or resetting a password. If doing one of these things in one browser causes you to be logged out of the other browser, put a sessions: section with an invalidate: field under that respective section (password.reset or password.change), with a value of all if the session that made the reset or change was logged out, and others if only the other section was logged out.
Also, when resetting a password, try clicking the link again before and after each step, seeing at what point the site refuses to load the form, or rejects submitting it. The point that causes the token to expire goes under password.reset.expiration.trigger. If the site never expires the reset token (allowing it to be used more than once), this goes under redflags: (and probably deserves a heads-up to their support team).
Create a reviewed: section with a date: value of the current content of https://www.isotimestamp.com/.
Commit the profile and click through to submit a pull request upstream. Tests will run in CircleCI to ensure that there aren't any errors in the profile: once it's been verified, the pull request can be merged.