![]() The administrative interface might be listening on a different port number than the main application, and so might not be reachable directly by users. The assumption here is that only a fully trusted user would be coming directly from the server itself. This provides a way for an administrator to recover the system in the event they lose their credentials. When a connection is made back to the server itself, the check is bypassed.įor disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. The access control check might be implemented in a different component that sits in front of the application server. Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons: The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.ĪPPRENTICE Basic SSRF against the local server However, when the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed. So an attacker who simply visits the URL directly won't see anything of interest. But the administrative functionality is ordinarily accessible only to suitable authenticated users. Now of course, the attacker could just visit the /admin URL directly. StockApi= Here, the server will fetch the contents of the /admin URL and return it to the user. In this situation, an attacker can modify the request to specify a URL local to the server itself. This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user. So when a user views the stock status for an item, their browser makes a request like this:Ĭontent-Type: application/x-www-form-urlencoded The function is implemented by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. ![]() To provide the stock information, the application must query various back-end REST APIs, dependent on the product and store in question. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).įor example, consider a shopping application that lets the user view whether an item is in stock in a particular store. In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. These trust relationships might exist in relation to the server itself, or in relation to other back-end systems within the same organization. SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.Īn SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application. View all SSRF labs What is the impact of SSRF attacks?Ī successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with. If you're already familiar with the basic concepts behind SSRF vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |