SSRF to SSTI

Server-Side Request Forgery (SSRF) and Server-Side Template Injection (SSTI) are two separate vulnerabilities that can be exploited in web applications. However, in some cases, they can also be chained together to create a more dangerous attack that allows an attacker to execute arbitrary code on the server. In this blog, we will explore the details of both vulnerabilities and how they can be chained together to exploit a vulnerable application.

Server-Side Request Forgery (SSRF) SSRF is a vulnerability that allows an attacker to make requests on behalf of the server. The vulnerability exists when an application accepts user input that is used to construct a URL for a remote resource. An attacker can use this input to construct a URL that points to an internal resource, such as the server’s metadata endpoint, which contains sensitive information about the server, or other sensitive resources within the network. An attacker can also use SSRF to scan the internal network for vulnerable services or servers.

Here is an example of a vulnerable PHP code that accepts a URL parameter from the user and makes a request to that URL:

$url = $_GET['url'];
$contents = file_get_contents($url);
echo $contents;

In this code, the user can provide any URL, including internal URLs. An attacker can use this vulnerability to make requests to internal resources, such as the metadata endpoint:

http://example.com/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin

This request would return the access credentials for the server’s IAM role. An attacker can use these credentials to access other resources within the network.

Server-Side Template Injection (SSTI) SSTI is a vulnerability that allows an attacker to inject code into a template that is used to generate dynamic content. The vulnerability exists when an application accepts user input that is used to construct a template. An attacker can use this input to inject code into the template, which is executed when the template is rendered. This vulnerability can be used to execute arbitrary code on the server, such as reading sensitive files, accessing databases, or executing shell commands.

Here is an example of a vulnerable Flask code that accepts a name parameter from the user and renders a template:

from flask import Flask, render_template, request

app = Flask(__name__)
@app.route('/')
def index():
    name = request.args.get('name', 'World')
    return render_template('index.html', name=name)
if __name__ == '__main__':
    app.run()

In this code, the user can provide a name parameter, which is used to construct a template. An attacker can use this vulnerability to inject code into the template:

http://example.com/?name={{config.items()}}

This request would render the following output:

[('DEBUG', False), ('TESTING', False), ('PROPAGATE_EXCEPTIONS', None), ('PRESERVE_CONTEXT_ON_EXCEPTION', None), ('SECRET_KEY', None), ('PERMANENT_SESSION_LIFETIME', datetime.timedelta(31)), ('USE_X_SENDFILE', False), ('SERVER_NAME', None), ('APPLICATION_ROOT', None), ('SESSION_COOKIE_NAME', 'session'), ('SESSION_COOKIE_DOMAIN', None), ('SESSION_COOKIE_PATH', None), ('SESSION_COOKIE_HTTPONLY', True), ('SESSION_COOKIE_SECURE', False), ('SESSION_COOKIE_SAMESITE', None), ('SESSION_REFRESH_EACH_REQUEST', True), ('MAX_CONTENT_LENGTH', None), ('SEND_FILE_MAX_AGE_DEFAULT', datetime.timedelta(0, 43200))]

In this case, the injected code returns the application’s configuration, which can contain sensitive information, such as database credentials.

Chaining SSRF and SSTI When an application is vulnerable