Change Details

"Server-Side Request Forgery" (SSRF) is a type of security vulnerability which allows an attacker to cause a server to make a request, and usually return the response or some metadata to the attacker. The server may have access to resources that the attacker does not, usually because it is on the other side of a firewall or other network partition. By making requests with elevated permissions, the attacker can execute commands or read information they should not be able to. For example, if a company hosts a plaintext list of passwords on their internal corporate network at `http://intern.corp.net/passwords.txt`, an attacker may be prevented from accessing this resource directly (that is: over the internet, by just typing the URL into their browser) by a firewall. However, if the attacker can convince some other service which is hosted on the internal corporate network to make this request on their behalf (and return the response), they could use that service to read the password list. Obviously, this example is pretty silly because no reasonable company would put a list of plaintext passwords at `http://intern.corp.net/passwords.txt`. Instead, every EC2 server using "IAM Roles" hosts the plaintext list of passwords at `http://169.254.169.254/passwords.txt`. In some cases, SSRF may not need to return data to be dangerous. For example, if a service exposes an endpoint at `http://intern.corp.net/delete-all-data.php` which deletes all data when accessed, the access itself may cause damage. In other cases, attackers may use the response success/error code, even without any response data, to simply search for servers they may be able to attack. Generally, SSRF can be mitigated with these techniques: # Do not expose endpoints, particularly HTTP endpoints, which respond to unauthenticated requests with plaintext lists of credentials. # Do not expose endpoints, particularly HTTP endpoints, which perform destructive actions in response to unauthenticated requests. # Do not use IAM Roles, because their design violates (1). # Do not expose services which can make requests to internal resources. Phabricator is a service which can make requests to other resources, and makes an effort to prevent users from making requests to internal resources and performing SSRF attacks. However, Phabricator must balance concerns between two competing pressures: preventing SSRF attacks on the one hand; and allowing Phabricator to interact with internal resources on the other. It is extremely common to reasonably want to configure Phabricator to interact with internal services. Some common internal services that are likely to be hosted in private IP space and which many Phabricator administrators expect Phabricator to be able to interact with are: build servers, repository servers, authentication servers, and webhook receivers. Phabricator generally balances these concerns by (in the default configuration) allowing administrators configure Phabricator to make requests to internal servers, but disallowing requests from unprivileged users. These rules can be changed in configuration. In particular: ...

(NOTE) **Summary**: In Phabricator, administrators can make requests to internal resources by configuring Auth and other services (builds, repositories, etc). This is expected behavior, necessary for Phabricator to function the way most users expect it to work, and is not an SSRF vulnerability. **What is SSRF?** "Server-Side Request Forgery" (SSRF) is a type of security vulnerability which allows an attacker to cause a server to make a request, and usually return the response or some metadata to the attacker. The attacker could just make this request themselves (by typing the URL into their browser), but the server may have access to resources that the attacker does not, usually because it is on the other side of a firewall or other network partition. By convincing a remote server to make these requests with its elevated permissions, the attacker can execute commands or read information they should not be able to. For example, if a company hosts a plaintext list of passwords on their internal corporate network at `http://intern.corp.net/passwords.txt`, an attacker may be prevented from accessing this resource directly (that is: over the internet, by just typing the URL into their browser) by a firewall or VPN. However, if the attacker can convince some other service which is hosted on the internal corporate network to make this request on their behalf (and return the response to them), they could use that service to read the password list. Obviously, this example is pretty silly because no reasonable company would put a list of plaintext passwords at `http://intern.corp.net/passwords.txt`. Instead, every EC2 server using "IAM Roles" hosts the plaintext list of passwords at `http://169.254.169.254/passwords.txt`, which is completely different. In some cases, SSRF may not need to return data to be dangerous. For example, if a service exposes an endpoint at `http://intern.corp.net/delete-all-data.php` which deletes all data when accessed, the access itself may cause damage. In other cases, attackers may use the response success/error code (even without any response data) to simply search for servers they may be able to attack. **How do you prevent SSRF attacks?** Generally, SSRF can be mitigated with these techniques: # Do not expose endpoints, particularly HTTP endpoints, which respond to unauthenticated requests with plaintext lists of credentials. # This effectively includes "do not use IAM Roles", as their design is largely indistinguishable from `passwords.txt`. # Do not expose endpoints, particularly HTTP endpoints, which perform destructive actions in response to unauthenticated requests. # Do not expose services which can make requests to internal resources. Most discussion of SSRF mitigation focuses on (3), because achieving (1) and (2) are not remotely realistic in a modern network environment. **What qualifies as an SSRF vulnerability in Phabricator?** Phabricator is a service which can make requests to other resources, and makes an effort to prevent users from making requests to internal resources and performing SSRF attacks. However, Phabricator must balance concerns between two competing pressures: preventing SSRF attacks on the one hand; and allowing Phabricator to interact with internal resources that administrators reasonably expect it to be able to interact with on the other. It is extremely common to reasonably want to configure Phabricator to interact with internal services. Some common internal services that are likely to be hosted in private IP space and which many Phabricator administrators expect Phabricator to be able to interact with are: build servers, repository servers, and authentication servers. Phabricator generally balances these concerns by (in the default configuration) allowing administrators configure Phabricator to make requests to internal servers, but disallowing requests from unprivileged users. Some of these rules can be changed in configuration. In particular: - Requests that unprivileged users can make are restricted by the `security.outbound-blacklist` Config setting, which defaults to standard private IP space. - Services which often need to make requests into private IP space (builds, repositories, Auth) can only be edited by administrators. - Some services can be additionally locked to reduce access: notably, Auth configuration can be locked with `bin/auth lock`, and a banner in the application reminds you to lock it once you're done with setup. - Phabricator generally does //not// limit the responses shown to users when they make a request they are authorized to make. For example, if you configure an invalid Auth provider, you may be able to get an entire HTTP response body. Phabricator could just say "an error occurred" instead, but this would be less useful for identifying and resolving the problem, and the user is nominally authorized to make the request (they have Administrator permission, or the appropriate reconfigured permission, and Auth is not locked). Requests that follow these rules are working as designed and not considered SSRF vulnerabilities. For an attack to represent an SSRF vulnerability in Phabricator, it must generally satisfy this requirement: (WARNING) **SSRF Vulnerabilities**: In Phabricator, a request to an internal resources represents an SSRF vulnerability **only if**: in the default configuration, an unprivileged (non-Administrator) user can make the request. These are //not// SSRF vulnerabilities, since they are Phabricator working as designed: - By design: Administrators can configure Phabricator to make requests to internal resources. - By design: Phabricator can be configured to allow more users (not just administrators) to make requests to internal resources (for example, by emptying `security.outbound-blacklist` or changing policies from "Administrators" to "All Users"). - By design: Users who are authorized by other rules to make a request can get complete information about errors and responses, even in cases where this information disclosure isn't strictly necessary: this is generally desirable to make troubleshooting easier. Opaque errors are often fairly hostile and hard to figure out and fix. **DNS Rebinding Attacks** Phabricator also includes protections against SSRF via DNS rebinding attacks. This is a larger topic (and a more complex attack), and discussed in greater detail in T6755.

"Server-Side Request Forgery" (SSRF) is a type of security vulnerability which allows an attacker to cause a server to make a request(NOTE) **Summary**: In Phabricator, administrators can make requests to internal resources by configuring Auth and other services (builds, and usually return the response or some metadata to the attacker.repositories, The server may have access to resources that the attacker does not,etc). usually because itThis is on the other side of a firewall or other network partition.expected behavior, By making requests with elevated permissionsnecessary for Phabricator to function the way most users expect it to work, the attacker can execute commands or read information they should not be able toand is not an SSRF vulnerability. For example, if a company hosts a plaintext list of passwords on their internal corporate network at `http://intern.corp.net/passwords.txt`, an attacker may be prevented from accessing this resource directly (that is: over the internet, by just typing the URL into their browser) by a firewall. However, if the attacker can convince some other service which is hosted on the internal corporate network to make this request on their behalf (and return the response), they could use that service to read the password list.**What is SSRF?** Obviously"Server-Side Request Forgery" (SSRF) is a type of security vulnerability which allows an attacker to cause a server to make a request, this example is pretty silly because no reasonable company would put a list of plaintext passwords at `http://intern.corp.net/passwords.txt`.and usually return the response or some metadata to the attacker. The attacker could just make this request themselves (by typing the URL into their browser), Insteadbut the server may have access to resources that the attacker does not, every EC2 server using "IAM Roles" hosts the plaintext list of passwords at `http://169.254.169.254/passwords.txt`usually because it is on the other side of a firewall or other network partition. By convincing a remote server to make these requests with its elevated permissions, the attacker can execute commands or read information they should not be able to. For example, if a company hosts a plaintext list of passwords on their internal corporate network at `http://intern.corp.net/passwords.txt`, an attacker may be prevented from accessing this resource directly (that is: over the internet, by just typing the URL into their browser) by a firewall or VPN. However, if the attacker can convince some other service which is hosted on the internal corporate network to make this request on their behalf (and return the response to them), they could use that service to read the password list. Obviously, this example is pretty silly because no reasonable company would put a list of plaintext passwords at `http://intern.corp.net/passwords.txt`. Instead, every EC2 server using "IAM Roles" hosts the plaintext list of passwords at `http://169.254.169.254/passwords.txt`, which is completely different. In some cases, SSRF may not need to return data to be dangerous. For example, if a service exposes an endpoint at `http://intern.corp.net/delete-all-data.php` which deletes all data when accessed, the access itself may cause damage. In other cases, attackers may use the response success/error code, (even without any response data,) to simply search for servers they may be able to attack. **How do you prevent SSRF attacks?** Generally, SSRF can be mitigated with these techniques: # Do not expose endpoints, particularly HTTP endpoints, which respond to unauthenticated requests with plaintext lists of credentials. # This effectively includes "do not use IAM Roles", as their design is largely indistinguishable from `passwords.txt`. # Do not expose endpoints, particularly HTTP endpoints, which perform destructive actions in response to unauthenticated requests. # Do not use IAM Rolesexpose services which can make requests to internal resources. Most discussion of SSRF mitigation focuses on (3), because achieving (1) and (2) are not remotely realistic in a modern network environment. **What qualifies as an SSRF vulnerability in Phabricator?** Phabricator is a service which can make requests to other resources, and makes an effort to prevent users from making requests to internal resources and performing SSRF attacks. However, Phabricator must balance concerns between two competing pressures: preventing SSRF attacks on the one hand; and allowing Phabricator to interact with internal resources that administrators reasonably expect it to be able to interact with on the other. It is extremely common to reasonably want to configure Phabricator to interact with internal services. Some common internal services that are likely to be hosted in private IP space and which many Phabricator administrators expect Phabricator to be able to interact with are: build servers, repository servers, and authentication servers. Phabricator generally balances these concerns by (in the default configuration) allowing administrators configure Phabricator to make requests to internal servers, but disallowing requests from unprivileged users. Some of these rules can be changed in configuration. In particular: - Requests that unprivileged users can make are restricted by the `security.outbound-blacklist` Config setting, because their design violates (1)which defaults to standard private IP space. # Do not expose services which can make requests to internal resources- Services which often need to make requests into private IP space (builds, repositories, Auth) can only be edited by administrators. - Some services can be additionally locked to reduce access: notably, Auth configuration can be locked with `bin/auth lock`, and a banner in the application reminds you to lock it once you're done with setup. - Phabricator generally does //not// limit the responses shown to users when they make a request they are authorized to make. For example, if you configure an invalid Auth provider, you may be able to get an entire HTTP response body. Phabricator could just say "an error occurred" instead, but this would be less useful for identifying and resolving the problem, and the user is nominally authorized to make the request (they have Administrator permission, or the appropriate reconfigured permission, and Auth is not locked). Phabricator is a service which can make requests to other resources, and makes an effort to prevent users from making requests to internal resources and performing SSRF attacks. However,Requests that follow these rules are working as designed and not considered SSRF vulnerabilities. Phabricator must balance concerns between two competing pressures: preventing SSRF attacks on the one hand;For an attack to represent an SSRF vulnerability in Phabricator, and allowing Phabricator to interact with internal resources on the other.it must generally satisfy this requirement: It is extremely common to reasonably want to configure Phabricator to interact with internal services. Some common internal services that are likely to be hosted in private IP space and which many Phabricator administrators expect Phabricator to be able to interact with are: build servers, repository servers(WARNING) **SSRF Vulnerabilities**: In Phabricator, authentication serversa request to an internal resources represents an SSRF vulnerability **only if**: in the default configuration, and webhook receiversan unprivileged (non-Administrator) user can make the request. Phabricator generally balances these concerns by (in the default configuration) allowing administrators configure Phabricator to make requests to internal servers, but disallowing requests from unprivileged users. These rules can be changed in configuration.These are //not// SSRF vulnerabilities, In particular:since they are Phabricator working as designed: .. - By design: Administrators can configure Phabricator to make requests to internal resources. - By design: Phabricator can be configured to allow more users (not just administrators) to make requests to internal resources (for example, by emptying `security.outbound-blacklist` or changing policies from "Administrators" to "All Users"). - By design: Users who are authorized by other rules to make a request can get complete information about errors and responses, even in cases where this information disclosure isn't strictly necessary: this is generally desirable to make troubleshooting easier. Opaque errors are often fairly hostile and hard to figure out and fix. **DNS Rebinding Attacks** Phabricator also includes protections against SSRF via DNS rebinding attacks. This is a larger topic (and a more complex attack), and discussed in greater detail in T6755.