Electron and Angular2: simple App example

In our first post about Electron, we were covering the main topics about what is and how it works. This time we will cover how to create a dummy application using Electron and Angular2 as a front-end framework.

The application tree should be something like this picture:

tree

we can observe:

  • gulpfile and package.json: we will talk later about this 2 files, by now we can just say that are needed to build the application.
  • assets: The package.json is a file useful to give directives to Electron, with this method we can order show/hide the window borders, icon, maximized/minimized, etc.
  • frontend: here we got the content relative to the front end, more especifically all the Angular2 stuffs.
  • main: contains the index.js referenced by assets/package.json and is the start point of our electron application.
  • Tsconfig and typescript files are needed to transcode the typeScript code into javascript.

The main gulp tasks needed to build and “deploy” the application sources:

gulp_file_main_tasks

from this file, the most important tasks are frontend and electron. The first one copy all the content from the source path.

The principal Electron tasks to run the application:

main_electron_gulp_tasks

 

The  second task begins the transcoding and building of the application.

   The electron package.js, it is useful to pass directives at start time, the format of  is exactly the same as that of Node’s modules, and the script specified by the main field is the startup script of your app, which will run the main process. An example of your package.json might look like this:

package_electron

   We need to remember, if the main field is not present in, Electron will attempt to load an “index.js”.

The main index file loaded by electron at first time looks like a common js file:

main_electron

Then, the final product, the application up and running:

app_running

    we realize that is a common web application, the tick here is to work in the look & feel to “hide” that common details (relative to the chromium browser) and make an effort in order to show the appplication like a elaborated desktop app. It is possible to change icon, task bar, menus, system buttons etc. Even if you don’t like the squared and classical window you can hide the background and create a “floating” app with alpha and the shape you want.

   In the sample app we’ve created a minimal environment with an image background and a button in the middle. If you press the button, you will get as result a notification at the notification area, that position will be according to the SO where the app is running, in my case Im running ElementaryOs so the notification area is in the upper-right conner:

notification_electron

The cool part here is, that notification is executing in real native code. The Electron API does the hard work to communicate to the SO what we are trying to do, in our case, show a notification with a text and image.

That’s all for this second part of Electron, you can download the code from here thanks for reading!

 

Injection Flaws: Part 2

SQL Injection

How to detect and prevent

The only way to detect flaws in your system is through deep testing.

Fortunately, there’s a set of tools recommended by OWASP, that may help you on this task. W3AF (w3af is a Web Application Attack and Audit Framework), Web Scarab (WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server) and BURP (Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process), just to mention some examples from the top of my head.

The general rule is to clean up all inbound and outbound.

This means you should ensure, in the first step, that you’re rejecting or deleting invalid characters. To do that you can use any sanitise library, PHPSanitizer as example mentioned on a previous post (Security in Web-apps: Overview).

Following with the process of harden our system, lets continue with SQL Injection, that can be tackled with code best practices. (the others might need some server configuration as part of the solution)

We can follow the next steps as a cheat sheet that will help to prevent most of the attacks.

  • Use of Prepared Statements (Parameterized Queries)

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

  • Use of Stored Procedures

Stored procedures have the same effect as the use of prepared statements when implemented safely (this means without dynamic query generation) which is the norm for most stored procedure languages. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application.

  • Escaping all User Supplied Input

This technique is based on escape the inputs before put them in the query – I strongly recommend that use this technique in addition with other – for instance, using a library suggested at the top of this section.

For this technique, you should also take care on specific DBMS escaping character information, in the following link is an example of Oracle Escaping information

http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

In addition to

  • Principle of Least Privilege

In order to minimize  the potential damage of a success injection, you shouldn’t use a DBA privileged user, but instead, connect with a user that has the minimum privileges required by the system. You also shouldn’t run your DBMS as root, sometimes DBMS allow to execute OS instructions. This is not matter of data you store in your database only.

Examples

Based on the next statement I’m going to show the most common SQL vectors:

Based on 1=1 is Always True

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

SELECT * FROM Users WHERE UserId = 105 or 1=1

Result, this will list all records in Users table, no matter of the UserId.

Based on “”=“” is Always True

uName = getRequestString("UserName");
uPass = getRequestString("UserPass");

sql = "SELECT * FROM Users WHERE Name ='" + uName + "' AND Pass ='" + uPass + “'"

Result, this will list all records in Users table, no matter of the UserName nor UserPass.

Based on Batched SQL Statements

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers

Result, you will lost Suppliers table.

This is just a quick start on Injection prevention, security should be implemented in layers.

In our next post, we will talk about Cross Site Scripting (XSS), definition and tips to dealing with it.

Security in Web-apps: Overview

Introduction

This blog entry intends to bring an overview about security and an introduction of usual mistakes and some tips.

Overview

What does Web application security means?

There are several definitions for this questions, but we can shorten them like:

A process that aims to address and fulfill the four principles of security:

  • Confidentiality: States that the sensitive data stored in the Web application should not be exposed under any circumstances.
  • Integrity: States that the data contained in the Web application is consistent and is not modified by an unauthorized user.
  • Availability: States that the Web application should be accessible to the genuine user within a specified period of time depending on the request.
  • Nonrepudiation: States that the genuine user cannot deny modifying the data contained in the Web application and that the Web application can prove its identity to the genuine user.

How to start working on this

As I mentioned before, security is process not just a patch that we can apply at the end of the project. This process should be transversal to the project, starting on the design phase and following, develop, tests and enhancements.

There’s an international non-profit organization that focus on software security improvements, Open Web Application Security Project (OWASP) that has identified the top 10 vulnerabilities:

  • Injection flaws
    • Injection is an entire class of attacks that rely on injecting data into a web application in order to facilitate the execution or interpretation of malicious data in an unexpected manner.
  • Broken authentication and Session Management
    • This is a vulnerability associated with the complex process of User’s authentication. This can happens in all web servers, application servers, and web application environments.
  • Cross Site Scripting (XSS)
    • XSS occurs when an attacker is capable of injecting a script, often Javascript, into the output of a web application in such a way that it is executed in the client browser.
  • Insecure direct object references
    • Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
  • Security misconfiguration
    • This is a set of potential flaws can be caused by a wrong configuration of web server or application server. There are a wide variety of server configuration problems that can plague the security of a site.
  • Sensitive data exposure
    • This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions.
  • Missing function level access control
    • This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed.
  • Cross site request forgery (CSRF)
    • This is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
  • Using components with known vulnerabilities
    • This flaws usually happens when 3rd party pieces of code are included in a system even when there are some vulnerabilities reported by the developers or any community.
  • Unvalidated redirects and forwards
    • We will talk about each item in later posts.

Basic Tips

A common expression between experts is “Never blindly trust the user! they don’t care about the problems can be caused to the system after an invalid input”. To avoid accidental or malicious issues caused by input, always sanitize data that will be used by your system.

Is very important you validate not only the inbound data, but also the output one. There are some threads used by hackers that try to inject redirections in large inputs the can be executed by client on output.

Here’s a small snippet that can show how to validate inputs:

...
require_once(dirname(__FILE__).’/<path_to_classes>/PHPSanitizer.php’);
$sanitizer = PHPSanitizer::getInstance();
$sanitizer->setType(PHPSanitizer::PARANOID);
$sanitizer->validate($string); //return a boolean
$sanitizer->cleanup($string); //returns an string with all invalid characters removed
...

Implementation of PARANOID type:

require_once(dirname(__FILE__).'/AbstractSanitizer.php');
require_once(dirname(__FILE__).'/ISanitizer.php');


class SanitizerParanoid extends AbstractSanitizer implements ISanitizer{
   private $pattern = "/[^a-zA-Z0-9]/";
   private $replacement = "";


   public function validate($string){
       return (preg_match_all($this->pattern, $string)===0);
   }


   public function cleanup($string){
       return preg_replace($this->pattern, $this->replacement, $string);
   }
}

Full code can be forked on  PHPSanitizer

Use prepared SQL statement every time you can, this way RDBMS will compile the query and reject invalid type parameters.

Also take care about your server hardening.

  • Avoid list directories on your server
  • Remove banners of your server
  • Add authentications methods
  • Use SSL across all your sensitive URLs