How to report a website security issue on Eventbrite

• What cookies are considered not related to authentication?
• What is self-inflicted cross-site scripting, and does Eventbrite consider it a vulnerability?
• Is brute-forcing passwords or password reset tokens considered a security issue?
• Is mass account registration a security issue? What about other denial of service attacks?
• What is Eventbrite’s logout supposed to do?
• What HTTP methods are considered security problems?
• What constitutes an Unvalidated Redirect, and are they a security threat?
• What protections does Eventbrite expect to get from its crossdomain.xml file?
• If I find Eventbrite.com does not conform to a security best practice, is that a security issue?
• To qualify

What cookies are considered not related to authentication?

The following is a list of cookies that we do not use for authentication. Therefore, the Eventbrite Security team does not consider it a security issue if you can share these cookies or if the app can leak them. If you discover these aren’t configured to be “httponly” or aren’t configured to be “secure,” we do not consider that an issue.

• AN

• G

• SERVERID

• SP

• SS

• csrftoken

• eblang

• mgemail

• mglts

• mgref

• mgrefby

• __ut*

• gpv_p8

• km_*

• kvcd

• mp_*

• s_cc

• s_sq

• sid

If you find insecure handling of other Eventbrite cookies, those could be a security issue and we encourage those reports.

What is self-inflicted cross-site scripting, and does Eventbrite consider it a vulnerability?

We welcome reports of issues on our end that enable cross-site scripting attacks that can be used to attack other users. Enthusiastic security reporters sometimes find situations where our website will execute arbitrary user-controlled Javascript without also showing that this can be used to attack third parties. We consider this kind of “self-inflicted cross-site scripting” to be not a security problem.

EXAMPLE: An attacker can create a carefully crafted URL or a store a page on *.eventbrite.com using our app, where another visitor to that page will execute Javascript controlled by the attacker. A non-security-impacting cross-site scripting issue is adding Javascript to the event description (when creating an event as an organizer). You can cause this Javascript to execute in your own browser. For this to become a security issue, you must be able to impact other users on the site. So if you can save an event description containing Javascript and another visitor to your event page will run the Javascript you saved, we would welcome a report.

Is brute-forcing passwords or password reset tokens considered a security issue?

We recognize that an attacker can attempt to generate random passwords to eventually find the password belonging to a particular user. We also recognize that attackers can automate use of the “password reset” feature to automatically generate new accounts. Our Integrity team monitors account creation, access, and recovery, through automated and manual tools, and will detect, flag, and in some cases block these attempts. Not a security issue: If you discover you can generate random passwords for a given user, and can test each guess one by one until you find the user’s password, and the act of testing one password does not give you any extra insight into the accuracy of other guesses. Security issue: If you discover that an attack that requires a large number of connections, but each new connection provides insight into the accuracy of other guesses, that would qualify as a legitimate issue. An example of this would be a timing attack in password checking.

Is mass account registration a security issue? What about other denial of service attacks?

Denial of service attacks are currently out of scope as security issues for a place on our Wall of Fame. We see mass account registration and other ways of filling up our database servers with data as a nuisance, not a security threat. With the help of automated tools, we can remove this data. However, we are interested in reports of possible denial of service vectors and how you might mount a denial of service attack against us. If you believe you have a plausible attack vector and need a place to test it, contact us. DO NOT perform the denial of service.

What is Eventbrite’s logout supposed to do?

Currently, when a user clicks “Log out” on eventbrite.com, we intend to provide the following property: the user’s browser can’t be used anymore to see pages that require the user to be logged in. If the user logs in to Eventbrite.com, saves their cookies to a file, clicks “log out,” and then restores the backed-up cookies into their web browser, they may find themselves logged in again. We recognize this and do not consider it a security vulnerability.

What HTTP methods are considered security problems?

HTTP methods, also known as verbs, have differing security properties. Researchers have helpfully alerted us to the possibility that we might be supporting a larger set of HTTP methods than we mean to. Currently, we intend to support:

• GET

• PUT

• POST

If we support the following method(s) as well, it is not considered a vulnerability:

• OPTIONS

The Eventbrite Security team considers the following definitely unsafe:

• TRACE

We may ignore reports about HTTP methods that are not considered vulnerabilities. We are enthusiastic about hearing reports that we support methods that we consider unsafe.

What constitutes an Unvalidated Redirect, and are they a security threat?

Under some circumstances, an Unvalidated Redirect can pose a threat, and we welcome reports. Per OWASP guidelines, in order to qualify as an unvalidated redirect, an Eventbrite-controlled URL must generate HTTP status 301 or 302 or otherwise change what URL the browser is visiting. We have received some reports of Unvalidated Redirects where the reporter has not demonstrated that the browser changes page to a possibly attacker-controlled URL, but we do welcome legitimate reports of this issue.

What protections does Eventbrite expect to get from its crossdomain.xml file?

Eventbrite has published a crossdomain.xml policy file that has a trusted set of partners including one wildcard domain. We understand the security tradeoffs regarding this wildcard domain and will not consider reports which simply indicate a wildcard is present. If you can exploit the crossdomain.xml policy via a partner site, we would be very interested in the details.

If I find Eventbrite.com does not conform to a security best practice, is that a security issue?

There are some common defensive practices that Eventbrite’s website does not follow, for historical or other reasons. In those cases, we may have other mitigation strategies in place. If the absence of a best practice creates a vulnerability, we welcome that report! Make sure to include a working proof-of-concept demonstration so we can confirm it creates a vulnerability. We’re interested in cases where one malicious user could affect the integrity of another user’s data.

To qualify

• Do not degrade service.

• Do not expose the data of other users.

• Provide reasonable time for the Eventbrite team to evaluate and fix your report before making your findings public.

If you need to test if an attack works, feel free to create two user accounts and use one to attack the other.

NOTE: The Eventbrite Security Wall of Fame exists to thank people who improve the safety of the product and customer data. We update the wall once a week (typically Tuesday) and honor people upon their first report. We don’t offer cash bounties or physical gifts at this time, and inclusion on the wall is entirely at the discretion of the Eventbrite Security Team.