Skip to main content

Technical information leak - Console functions

Need​

Secure logging mechanism

Context​

  • Usage of Dart for building cross-platform mobile, web, and desktop applications
  • Usage of Shelf for managing and organizing data in a Node.js application

Description​

Non compliant code​

import 'package:shelf/shelf.dart' as shelf;

void main() {
  var handler = const shelf.Pipeline().addMiddleware(shelf.logRequests()).addHandler(_echoRequest);

  io.serve(handler, 'localhost', 8080);
}

shelf.Response _echoRequest(shelf.Request request) {
  print('Received request: ${request.method}');
  print('Request url: ${request.url}');
  print('Request headers: ${request.headers}');

  console.log('This is a console log message');
  console.info('This is a console info message');
  console.warning('This is a console warning message');

  return shelf.Response.ok('Request for "${request.url}"');
}

The above code represents a backend application written in Dart using the Shelf framework. This application is serving requests on localhost on port 8080.

The application logs every request it receives. It logs the request method, URL, and headers. This is done in the _echoRequest method. This method is called for every request the application receives.

In addition, the application also uses console functions: console.log(), console.info(), and console.warning(). These functions are used to log messages, information, and warnings respectively.

The usage of these console functions in production environments can lead to information leakages. This is because they can reveal sensitive information like the methods being used, the URLs being accessed, and the headers being sent. This information can be used by an attacker to understand the application's logic, the technologies being used, and to find potential vulnerabilities.

Moreover, the usage of these console functions can also reveal the application's internal state. This can be used by an attacker to understand the application's behavior and to predict its future behavior.

Therefore, the usage of console functions in production environments is a potential security vulnerability and should be avoided.

Steps​

  • Remove or comment out all console.log, console.info, and console.warning statements from the production code. These statements are typically used for debugging and should not be present in production code.
  • If you need to log information, consider using a logging library that can be configured to log only certain levels of information in different environments. For example, you might configure the logger to log all messages in a development environment, but only errors in a production environment.
  • Ensure that any sensitive information, such as user credentials or personal data, is never logged, even in a development environment.
  • Consider implementing a centralized logging system that can securely store and manage logs. This can help prevent information leakage and provide a useful tool for monitoring and debugging.

Compliant code​

import 'package:shelf/shelf.dart' as shelf;

void main() {
  var handler = const shelf.Pipeline().addMiddleware(shelf.logRequests()).addHandler(_echoRequest);

  io.serve(handler, 'localhost', 8080);
}

shelf.Response _echoRequest(shelf.Request request) {
  print('Received request: ${request.method}');
  print('Request url: ${request.url}');
  print('Request headers: ${request.headers}');

  // console.log('This is a console log message');
  // console.info('This is a console info message');
  // console.warning('This is a console warning message');

  return shelf.Response.ok('Request for "${request.url}"');
}

The updated code removes the usage of console.log, console.info, and console.warning functions. These functions are typically used for debugging and should not be present in production code as they may lead to information leakages and reveal vulnerable methods, technologies, or logic.

If you need to log information, consider using a logging library that can be configured to log only certain levels of information in different environments. For example, you might configure the logger to log all messages in a development environment, but only errors in a production environment.

Ensure that any sensitive information, such as user credentials or personal data, is never logged, even in a development environment.

Consider implementing a centralized logging system that can securely store and manage logs. This can help prevent information leakage and provide a useful tool for monitoring and debugging.

References​

Last updated on