Open Bounty Program

Vulnerabilities in authentication or session management could manifest themselves in a number of ways. This could be a gap or bug in authentication logic, password reset flows, or SSH key validation. A vulnerability in one of these components could range in impact, from assisting in a social engineering attack to a full compromise of user accounts.

Our applications support a number of authentication methods. On webhostingmagic.com, this includes our login form, authentication to other applications with OAuth, authentication between Web Hosting Magics with signed tokens, and maintaining authentication state through session cookies. Each of these methods is a complex system and requires serious security scrutiny.

To bolster the security of authentication, our web-based and API logins supports two-factor authentication to minimize the impact of compromised user credentials. Additionally, to limit the impact of a compromised session, we require re-authentication for sensitive tasks with what we call sudo mode.

More about authentication and session management vulnerabilities from OWASP’s Top 10:

Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

Cross-site request forgery, or CSRF, takes advantage of a user’s authenticated browser state to make requests on their behalf from a malicious website. For request handlers that do not require an additional piece of authenticating information (e.g. a CSRF token) this could lead to the unauthorized modification of a user’s data or settings.

On webhostingmagic.com, we utilize unique session token with the authenticated returned response to protect against CSRF attacks. All state changing requests require validation of this parameter, which is sent via an HTTP header or POST parameter.

More about CSRF vulnerabilities from OWASP’s Top 10:

CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action. Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.

Cross-site scripting, or XSS, is one of the most common vulnerabilities within web applications. When an application reflects unsanitized user input from data stores, external systems, or HTTP requests into HTML responses, an attacker can trick the application into executing malicious JavaScript in a victim’s browser. The use of user-controlled elements within insecure JavaScript functions can lead to the same effect.

Our usage of Rails and markup rendering pipelines allows us to escape untrusted data by default during HTML rendering. However, there are always edge cases that could pop up. Read Rails’ security guide about XSS for more specific examples.

We employ various browser features to help mitigate the risk of XSS for our users. For Web Hosting Magic.com we set Content-Security Policy (CSP) HTTP headers to prevent the execution of arbitrary JavaScript within the webhostingmagic.comdomain. Additionally, we set the X-XSS-Protectionheader to instruct the browsers to activate proactive XSS mitigation. To prevent an XSS exploit from compromising user sessions, access to sensitive cookies is disallowed by settings the HTTPOnlyflag.

More about cross-site scripting vulnerabilities from OWASP’s Top 10:

XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS.

Injection vulnerabilities could introduce a high level of risk, modifying the commands or queries used by the systems that our applications depend on. Ranging from SQL, file path, HTTP headers, or even gitcommands, injection vulnerabilities would usually fetch a large bounty.

More about injection vulnerabilities from OWASP’s Top 10:

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.

Direct object reference vulnerabilities occur when there are insufficient authorization checks performed against object identifiers used in requests. This could occur when database keys, filenames, or other identifiers are used to directly access resources within an application. These identifiers would likely be predictable (an incrementing counter, the name of a file, etc), making it easy for an attacker to detect this vulnerability class. If further authorization checks are not performed, this could lead to unauthorized access to the underlying data.

More about direct object reference vulnerabilities from OWASP’s Top 10:

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.

Function level access control vulnerabilities could result from insufficient protection of sensitive request handlers within an application. An application may simply hide access to sensitive actions, fail to enforce sufficient authorization for certain actions, or inadvertently expose an action through a user-controlled request parameter. These vulnerabilities could be much more complex and be the result of subtle edge-cases in the underlying application logic.

More about function level access vulnerabilities from OWASP’s Top 10:

Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Security misconfiguration vulnerabilities could occur if a component is susceptible to attack due to an insecure configuration option. These vulnerabilities often occur due to insecure default configuration, poorly documented default configuration, or poorly documented side-effects of optional configuration. This could range from failing to set a useful security header on a web server, to forgetting to disable default platform functionality that could grant administrative access to an attacker.

Web Hosting Magic uses hundreds of different software components, including server software, libraries, and application frameworks. Each of these components has complex configuration options. We rely on extensive automation (configuration management, automated deployment, unit testing) to minimize our risk of mis-configuring a security critical component. If an insecure configuration is identified, we can make a centralized change and add a new test case to ensure we do not regress in the future.

More about security misconfiguration vulnerabilities from OWASP’s Top 10:

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

Sensitive data exposure vulnerabilities can occur when an application does not adequately protect sensitive information from being disclosed to attackers. For many applications this may be limited to information such as passwords, but it can also include information such as credit card data, session tokens, or other authentication credentials.

Some of the features Web Hosting Magic has implemented to protect our users’ sensitive data include: securely hashing passwords, enabling Strict Transport Security, using a third-party payment processor, and not allowing users to view personal access tokens after they are generated.

More about sensitive data exposure vulnerabilities from OWASP’s Top 10:

The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.

Unvalidated redirect vulnerabilities could allow an attacker to redirect a user to an untrusted site using functionality in a trusted site. This could lend credibility to various social engineering attacks that may try to trick a user to follow a link to a legitimate Web Hosting Magic page, only to have that page redirect them to an untrusted site.

To prevent this vulnerability within Web Hosting Magic, all user-controlled redirects are funneled though validation logic to restrict the locations that users can be forwarded to.

More about unvalidated redirect vulnerabilities from OWASP’s Top 10:

Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page. Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.

Vulnerabilities in third-party libraries and software are extremely common and could be used to compromise the security of systems using the software. Over the last several years approximately 4500 CVEs have been published per year. Only some of these vulnerabilities are relevant to Web Hosting Magic, but it can be quite a challenge to keep track of these on a day-to-day basis.

Our applications use a large number of third-party and open source libraries and software. It is no secret that Web Hosting Magic is built on Rails, and that we take full advantage of the tremendous number of gems published by the Rails community. Each of these gems may introduce a flaw that could impact the security of Web Hosting Magic. But, it isn’t just Ruby libraries we need to concern ourselves with. We also use software such as HAProxy, Nginx, libgit2, and many others to help make Web Hosting Magic possible.

Fortunately, Web Hosting Magic contributes to a large number of the projects that we rely on. This helps us keep track of critical vulnerabilities in these components. However, we also rely on following mailing lists, word of mouth, and other manual means of keeping track of vulnerabilities. Regardless of how we are made aware of a vulnerability, the way we deploy at Web Hosting Magic lets us put a fix in place as quickly as possible.

More about using components with known vulnerabilities from OWASP’s Top 10:

Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.

Vulnerabilities are never limited to a set list. Any bug that escalates a user’s privileges or causes unexpected behavior with an impact to the integrity or confidentiality of our users’ data will be considered.

It is often the types of vulnerabilities we haven’t thought about that are the most interesting!