JavaScript or SQL injection attacks in the Node.js platform?

; Date: Wed Dec 21 2011

Tags: JavaScript »»»» Node.JS »»»» JavaScript Injection

Traditionally the server side of web applications has been written in PHP, Perl, Python, Java, C/C++, etc. Javascript traditionally was implemented only in web browsers, and hence Javascript programming has been almost completely focused on the client end of web application development. It's arguably better to have the same programming language on both client and server sides of web application development, maybe. Several attempts have been made to implement javascript for server side web application development. A new javascript stack, Node.JS, is getting a lot of attention.

Alex Popescu writes about some having started to ponder how safe Node.js based servers are against injection attacks.  Traditionally injection attacks were targeting SQL commands being constructed from web queries, and various forms of cross site javascript injection attacks.  The cure for these attacks is to use a robust content filtering system as well as to follow sound software engineering practices.  But many Node.js tutorials and even some live systems apparently have injection attack vulnerabilities.

He refers to a paper by Bryan Sullivan (Senior Security Researcher, Adobe Secure Software Engineering Team) which goes over some Node.js examples of JavaScript injection into server side javascript.

He provides this example which he says is supposedly common practice for dealing with incoming JSON data:

var http = require('http');
http.createServer(function (request, response) {
    if (request.method === 'POST') {
        var data = '';
        request.addListener('data', function(chunk) {
            data += chunk;
        });
        request.addListener('end', function() {
            var stockQuery = eval("(" + data + ")");
            getStockPrice(stockQuery.symbol);
        });
    ...

The key vulnerability is the use of eval() to convert the JSON data string into an object.  Of course that's a bad idea because it lets JavaScript code execute in the server context, and an attacker could send any sort of JavaScript code in data that's supposed to be JSON.  Obviously it's much safer to use JSON.parse rather than eval() but apparently some code is using eval().

For example an attacker could launch a simple denial of service by sending while(1) { } as the data that's supposed to be JSON.

Bryan Sullivan's paper goes on to talk about injecting JavaScript into a NoSQL database via this same sort of vulnerability.  He ends with these suggestions:

• Avoid creating “ad-hoc” JavaScript commands by concatenating script with user input.
• Validate user input used in SSJS commands with regular expressions.
• Avoid use of the JavaScript eval command. In particular, when parsing JSON input, use a safer alternative such as JSON.parse.

http://nosql.mypopescu.com/post/14453905385/attacking-nosql-and-node-js-server-side-javascript

https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf