XIVAuth Security Policy

This is a draft! The contents of this document will change, possibly in significant ways.

As an open source and a relatively high-trust project, XIVAuth holds security in the highest regard. To that end, we have decided to publish a security policy to answer most questions about penetration testing, reporting security vulnerabilities, and how to interact with the site.

Pentesting Ground Rules

We strongly encourage that any security tests are run on a local version of XIVAuth. The software is open source and freely available, and should be simple to set up even for non-Ruby developers.

If you are performing a pentest against the production servers, we ask you to please keep other users in mind. If you find something that crashes XIVAuth, don't do it forty times to make a point. If you're trying to access a resource that isn't owned by you, create a second account and try to access those. If you're trying to break in to an account or bypass MFA, please attack your own account. XIVAuth is used by other people too; please don't inconvenience them for hacker cred.

In addition, please refrain from performing any of the following activities:

  • Testing the underlying infrastructure. We're hosted on Heroku right now, and are sharing resources and server space with other people. They're (probably) innocent, so please don't make their day bad. This includes denial of service attacks.
  • Directly attacking our providers. A CAPTCHA bypass is cool, but only if you actually get the server to not care about the CAPTCHA. Outsourcing solves to a click farm is boring and has been done before.
  • Attacking other people on the platform. Attacking the platform is cool. Specifically attacking other people using the platform in a targeted manner is not cool. Even if you report it to us afterwards.
  • Performing brute-force attacks. Anyone can guess a password with enough tries. Please don't waste our servers' time by testing the top 50,000 passwords list.

Reporting A Vulnerability

If you've found a vulnerability, congratulations! Please follow standard Responsible Disclosure procedures for submitting issues to us. Put simply, please report the vulnerability to us first (before any sort of public blog post or social media message) so that we can fix it before anyone has a chance to abuse the reported bug.

You may report the bug by sending an email to [email protected] or by DMing Kaz on Discord through his username, kazwolfe. Please be sure to include the steps to reproduce the bug, as well as your specific expectations and what you saw instead. If your report includes sensitive or confidential information, please encrypt it using PGP. Kaz's PGP key has an ID of 2588 13F5 3A16 EBB4, and can also be found on most keyservers or GitHub. It's okay to send content encrypted with this key to the above email as well, even though it's not listed on the key.

What Not To Report

While we appreciate all kinds of reports, there are a select few things that we don't need to be informed about. Please don't submit security issues related to the following:

  • Any attacks that rely on social engineering, including leaked or stolen credentials.
  • Any attacks that rely on physical or virtual access to a victim's computer or network.
  • Any reports of publicly accessible XIVAuth API Keys.
  • Any CSRF issues that do not modify state (e.g. logout commands).
  • Any attacks that require the use of brute force, denial of service attacks, or similar.
  • Any security issues in a specific API client (e.g. a plugin or web service).
  • Any of the following without demonstrable widespread or significant impact:
    • Any plain text reflection, including non-persistent self-XSS.
    • Any missing or invalid HTTP headers or settings.
    • Anything related to CORS.
    • SPF, DMARC, or DKIM misconfigurations.
    • Attacks that rely on a specific browser or system configuration.

If you find any code-level issues that don't qualify for a security report, you are welcome to report them via GitHub Issues as a standard bug or code defect.

Do I Get Rewarded?

Unfortunately, no. XIVAuth is an open source project and is currently run by a single person. While rewards are awesome (and we'll likely make a Hall of Fame at some point), it's just not currently feasible. If we ever do offer a bounty, anyone who has previously submitted a valid report will be contacted as well.

You are permitted to publish information about your findings to personal blogs or portfolios provided that you have received confirmation that the bug has been fixed, and that any and all sensitive information is redacted. We may request that certain security issues not be published elsewhere - if this is the case, we will communicate the exact reason and motivation behind our request to you.

Will We Be In Touch?

We will follow up on any security reports as quickly as reasonably possible based on the report type and severity. If we need additional information, we will reach out to discuss and ask questions; please make sure you are submitting reports from a monitored mailbox. If you'd like for us to contact you over PGP as well, please ensure that your public key is published or attached to your initial report.

You will also be notified about our findings. If the report is accepted, you will be notified when the fix has been pushed to the codebase in case you would like to verify our fix, although you are not obligated to do so. If the report is rejected, we will include detailed information about our justifications and any mitigations that we have in place (if necessary).