OVE-20191021-0001: Multiple vulnerabilities in the mysqljs API and code
Published on , 859 words, 4 minutes to read
Within Security Advisory
Multiple vulnerabilities in the mysqljs API and code.
Security Warning Level: yikes/10
Summary
There are multiple issues exploitable by local and remote actors in mysqljs. These can cause application data leaks, database leaks, SQL injections, arbitrary code execution, and credential leaks among other things.
Mysqljs is unversioned, so it is very difficult to impossible to tell how many users are affected by this and what users can do in order to ensure they are patched against these critical vulnerabilities.
Background
Mysqljs is a library intended to facilitate prototyping web applications and mobile applications using technologies such as PhoneGap or Cordova. These technologies allow developers to create a web application that gets packaged and presented to users as if it was a native application.
This library is intended to help with developers creating persistent storage for these applications.
Issues in Detail
There are at least seven vulnerabilities with this library, each of them will be outlined below with a fairly vague level of detail.
mysql.js is NOT versioned
The only version information I was able to find are the following:
- The
Last-Modified
date of Friday, March 11 2016 - The
ETag
of80edc3e5a87bd11:0
These header values correlate to a vulnerable version of the mysql.js file.
An entire copy of this file is embedded for purposes of explanation:
var MySql = {
_internalCallback : function() { console.log("Callback not set")},
Execute: function (Host, Username, Password, Database, Sql, Callback) {
MySql._internalCallback = Callback;
// to-do: change localhost: to mysqljs.com
var strSrc = "http://mysqljs.com/sql.aspx?";
strSrc += "Host=" + Host;
strSrc += "&Username=" + Username;
strSrc += "&Password=" + Password;
strSrc += "&Database=" + Database;
strSrc += "&sql=" + Sql;
strSrc += "&Callback=MySql._internalCallback";
var sqlScript = document.createElement('script');
sqlScript.setAttribute('src', strSrc);
document.head.appendChild(sqlScript);
}
}
Fundamental Operation via Cross-Site Scripting
The code operates by creating a <script>
element. The Javascript source of
this script is dynamically generated by the remote API server. This opens the
door for many kinds of Cross-Site Scripting attacks.
Especially because:
Credentials Exposed over Plain HTTP
The script works by creating a <script>
element pointed at a HTTP resource in
order to facilitate access to the MySQL Server. Line 6 shows that the API server
in question is being queried over UNENCRYPTED HTTP.
var strSrc = "http://mysqljs.com/sql.aspx?";
Credentials and SQL Queries Are Not URL-Encoded Before Adding Them to a URL
Credentials and SQL queries are not URL-encoded before they are added to the
strSrc
URL. This means that values may include other HTTP parameters that
could be evaluated, causing one of the two following:
Potential for SQL Injection from Malformed User Input
It appears this API works by people submitting plain text SQL queries. It is likely difficult to write these plain text queries in a way that avoids SQL injection attacks.
Potential for Arbitrary Code Execution
Combined with the previous issues, a SQL injection that inserts arbitrary Javascript into the result will end up creating an arbitrary code execution bug. This could let an attacker execute custom Javascript code on the page, which may have even more disastrous consequences depending on the usage of this library.
Server-Side Code has Unknown Logging Enabled
This means that user credentials and database results may be logged, stored and leaked by the mysql.js API server without user knowledge. The server that is running the API server may also do additional logging of database credentials and results without user knowledge.
Encourages Bad Practices
Mysql.js works by its API server dialing out an UNENCRYPTED connection to your MySQL server over the internet. This requires exposing your MySQL server to the internet. This means that user credentials are vulnerable to anyone who has packet capture abilities.
Mysql.js also encourages developers commit database credentials into their application source code. Cursory searching of GitHub has found this. I can only imagine there are countless other potential victims.
Security Suggestions
- Do not, under any circumstances, allow connections to be made without the use of TLS (HTTPS).
- Version the library.
- Offer the source code of the API server to allow users to inspect it and ensure their credentials are not being stored by it.
- Detail how the IIS server powering this service is configured, proving that it is not keeping unsanitized access logs.
- Ensure all logging methods sanitize or remove user credentials.
- URL-encode all values being sent as part of a URL.
- Do not have your service fundamentally operate as a Cross-Site Scripting attack.
- Do not, under any circumstances, encourage developers to put database credentials in the source code of front-end web applications.
In summary, we label this a solid yikes/10 in terms of security. It would be advisable for current users of this library to re-evaluate the life decisions that have lead them down this path.
GReeTZ
Über thanks to jadr2ddude for helping with identifying the unfortunate scope of these massive security issues.
Hyper thanks to J for coming up with a viable GitHub search for potentially affected users.
Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.
Tags: security, release, javascript, mysql, oh-dear-god