Summary

Summary

The embedded_submission_form_uuid parameter in the /graphql endpoint was vulnerable to a SQL injection. This allowed an attacker to extract information from the public and secure schema. We have determine that the vulnerability was not exploited. A thorough explanation can be found in the report below.

Timeline

Impacted Data

We have determine that the vulnerability was not exploited. A thorough explanation can be found in the report below.

Root cause

HackerOne.com has a GraphQL endpoint that the frontend uses to query its backend. When the embedded submission form feature was introduced, a design decisions was made to leverage a GraphQL parameter rather than an input field. Input fields are properly sanitized. However, GraphQL parameters, were not. These GraphQL parameters were not designed to take raw user input. Here's the vulnerable piece of code:

unless database_parameters_up_to_date
  safe_query = ''

  new_parameters.each do |key, value|
    safe_query += "SET SESSION #{key} TO #{value};" # <-- 😮
  end

  begin
    connection.query(safe_query)
  rescue ActiveRecord::StatementInvalid => e
    # NOTE: when the transaction is aborted, we cannot set or reset any parameters.
    # Changes of previous SET statements are undone as well, so we can safely do
    # nothing here
    raise e unless e.cause.is_a? PG::InFailedSqlTransaction
  end
end

The reason why we have to pass down these parameters to the PostgreSQL query level, is because HackerOne.com's database has two separate schemas. The public schema, which is where all the data resides and what we call the secure schema. The latter is a set of derived views from the public schema that returns data based on the currently signed in user (or signed out, for that matter). By default, GraphQL queries the secure schema. These derived views are automatically generated based on authorization logic we define in our GraphQL layer. This reduces the changes of information disclosure vulnerabilities, such as IDOR and SQL injections. Even when an attacker were to be able to query the secure schema, it'd reduce the number of exposed records significantly.