Security Policy

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 not 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 a mix of PaaS, VPS platforms, and are therefore sharing resources and service 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. Directly attacking other people using the platform in a targeted manner is not cool. Even if you report it to us afterward.
• 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 it.

You may report the vulnerability 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 of2588 13F5 3A16 EBB4, and can also be found on most key servers 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, as an open source project, we are unable to offer any sort of financial reward for confirmed security reports. XIVAuth is run by a single person, and while we would love to offer some sort of compensation, it's just not something we can do. That being said, anyone who submits a valid security report is eligible for a small set of goodies, as well as recognition in our Hall of Fame (whenever we finally get a confirmed report). These goodies will include a custom-printed JavaCard ID card personalized with your character and some other information, as well as a couple stickers. If we ever change our bounty policies, we will reach out to all prior reporters to make them whole.

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 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).