Server-less Architecture - To MVC or not MVC is indeed a choice now

As a student developer at EdPlus at Arizona State University, I had the opportunity to work on project that involved to display analytic information of the ASU website. A colleague prior to me was involved in building the entire application. He decided to use a web application MVC framework Express - Node.js. We'll its a good choice easy to manage as each of the component is pretty decoupled, the model view and the controllers as known as routes in NodeJS. The entire project was deployed on a HTTP server on Amazon. The project was basically displaying google analytic data. There was no session database etc. Just a simple application that uses data from google analytics and displays content using various charts.

I was given the opportunity to work on it take it further. I was hard stuck that MVC is the best existing model to decouple your project and have easier code management.
Perhaps this discussion changed it all:

Chandi: Hey! you've got to work on dashboard
Me: Sounds good! What's it built on ?

Chandi: Its a MVC Node JS application and there is no sessions management, database etc just an API calls to google analytics and display in charts.
Me: MVC in node JS wow that's nice!

Chandi: No!! MVC is not needed here, have a look at AWS lamda - API gateway model ?
Me: MVC is good! I don't see any point here ?

Chandi: Check it out and you'll know!

<after a while | after reading>

Me: Whaaaatt! No server ?
Chandi: Haha

All credits to the Tim Wagner, AWS Lambda General Manager. This write up is just an inspiration from his blog so that others developer folks out there can decide " To MVC or not MVC "

 Lets begin with understanding a simple MVC application irrespective of any programming language. There are 3 components involved Model-View-Controller.

There are quite a number of MVC frameworks out there. Some of them back of mind would be spring MVC in Java, Express in Node.js. When a request arrives to the server it first lands on the front controller as shown in the figure above. In spring MVC its the dispatcher servlet or Node.js its app.js/server.js (the file that declare itself as a server application. There a various controllers/routes registered on to the front controller. Based on the URL path the front controller dispatches the request to the entity specific controller.
 So lets take an example https://www.domain.com/app_name/entity_path/entity_api_method
Now as soon as the request arrives to Front Controller it checks for the entity_path registered with it and forwards the request to the entity specific controller. Then in that controller it scans for the API that matches 'entity_api_method' and renders the specific view or returns model for service/data access layer or any 3rd party API can be consumed here. All of this is deployed on a server.

My application did not have a database, no session management, no user access etc. Why do I need a server? Well I only realized when I read that blog by Tim Wagner.

How do I refactor my MVC application to a server-less architecture and avoid the overhead of an explicit server management

Now lets understand AWS API gateway - Lambda execution model.

Amazon provides EC2 or Elastic bean stalk (an environment to configure n instances of EC2) that can help you deploy your web application. However these configurations still host a server or is a server. But we decided a server-less architecture.
Here, AWS Lamda comes to the rescue!

Q: What is AWS Lambda?
"AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app " - AWS faq.

Lets start breaking down the application built in NodeJS MVC.
Here are some of the steps not in details but just an overview:
1. Upload HTML and static contents to a S3 bucket and expose an public url
2. Create REST api's in AWS API gateway that would serve as your controllers to your AWS lambda function that will be accessed from your javascript in your html pages. On access theses API's pass the data and invoke the appropriate AWS Lambda function.
3. The major part is converting yours service and data access layers to lambda functions.
These would be quite challenging but depending on your architecture you can now indeed make a choice.

It is as simple as the figure shown below,

If you have a well built MVC application you can convert your entire application to AWS API gateway - Lambda execution model and make your services deploy in Lambda without the need to maintain an explicit server.

If you want to go more in depth of AWS Lambda here are some links that will give a direction and moreover you can run lambda locally and then deploy on AWS.
1. Get started with AWS Lambda on cloud
2. AWS SDK are available in quite a number of tools

This is just a representation of my experience to leverage API gateway - lambda execution model to have a server-less and easy deployment strategy for micro services. One can always decide which model is the right fit for their application.
MVC or not-MVC is indeed a choice now.

I hope this article provides an overview of how you can consider this model to MVC and change a server deployed application to server-less.

Cheers.

KO'd the damn SQL injection

SQL Injection Prevention Framework in PHP 

A student of Arizona State University, I decided to take Software Security CSE 545 as one of my courses. The course covered a variety of topics one of them being SQL Injection. Those who are not familiar with it I suggest going through SQL Injection OWASP

Prior to enrolling in this course I took 'Principles of Programming Language CSE 340'. This course taught me how programming languages evolved and why the work, semantics, syntax and lexical analysis. The course was fun and so the instructor Assistant Professor Dr. Adam Doupé. He took keen interest in teaching with answering questions of 'WHY programming? HOW they work? in a clear crisp way.

He is an expert in web application security thus I decided to take his course 'Software Security'. As thecourse continued I decided to take up SQL injection as my semester project. Well I'm aware there are a lot of solutions out there and many prevention techniques, but guess I had learned something very useful 'semantics of a programming language' and thus decided to put it to use. SQL being structured query language and has its own syntax and semantics. I decided to work on it with another friend of mine expert in web security Tejas Khairnar.

"The purpose of this project is used to introduce a framework that prevents SQL injection in any PHP web application with minimum changes. We go to the root cause of the injection ‘malicious user supplier input’ that changes the original query"

Our approach is to put an end to SQL injection flaws in any PHP application with a framework that is fairly simple to integrate with minimum changes and robust. We describe our approach in three sections architecture, integration and simulation.

I. Architecture:

Each query written in a PHP file has certain semantics and is intended for a specific purpose for convenience we say ‘before Query semantics’. Now the malicious user input changes the intention or behavior of the original query as given below.

Thus we can say that the original query is modified and the semantics of the query has changed for convenience we say ‘after Query semantics’. The semantics of SQL queries is formally defined by stating a set of rules that determine a syntax-driven translation of an SQL query to a formal model [4]. Some of the highlights of the semantics of SQL query is given by table name(s), number of columns, type of query, column references etc. These attributes define the structure of the semantic model of the query representation.

" Our framework is based on the comparison the semantic model of ‘before Query’ and ‘after Query’ "

The detailed steps describe the detail flow of the web application request through the firewall to the database.

1. SQLFirewall has a component ‘SQL Firewall DB Proxy Connector’ that connects to the database. Thus all queries pass through this proxy connector. Typically a wrapper over the existing connectors.
2. The SQL Firewall DB proxy connector then passes the query to the ‘PHP SQL Parser’ component to generate the semantic model of the query that has been received for execution with user supplied input. For simpler purpose we define it as after Query.
3. It then finds out the calling function in a PHP file recursively to identify the query that was used with supplied user input. We use the back trace functionality in PHP. All these functions are loaded in the component ‘PHP SQL Query Extractor’ which extracts the query defined in the PHP file before the supplied user input. We can say that this is a static analysis of a certain SQL query defined in a PHP file. For simpler purpose we define this as before Query.
4. It then stores the semantic model of the before query in the ‘SQL Firewall Cache’ with key as a hash of combination of filename where the SQL query is defined, line number of that file name and function that was invoked with the SQL query parameter name. This uniquely identifies the after Query to this before Query stored in the cache.
5. After which both the semantic models are then passed to the SQL Firewall validator which performs a deep check on the semantic model attributes of the after Query and the before Query.
6. If any change is found the ‘SQL Injection Exception Handler’ component is called to determine the type of injection.
7. If no change then the ‘SQL Firewall’ resumes execution of the actual flow and returns the result.

II. Integration:

These are the following two changes the developer needs to do to integrate our framework.

1.  Use our ‘SQL Firewall DB Proxy Connector’ as the source to connect to MySQL.
2.  include_once ‘application/application.php’ in any PHP startup loader page.

III. Simulation:

Limitations
Currently our framework is written in PHP and compatible with MySQL. The another drawback in our framework is during static analysis we get the semantic model of the ‘before Query’ we try to trace the callback to the appropriate SQL query defined in the PHP file using file name, line number of invocation and function name. Then we use the SQL query extractor to extract the SQL query related to this database call. However, there could be a situation where there are two variables with the same name are defined in the same file. We tackled this by throwing a warning to the developer to make appropriate changes.

Future Work
We look forward the incorporate the idea with other web applications technologies and databases. We could also extend our framework to include access controls on tables thereby adding an extra layer of protection. This framework could be part of bigger idea for a web application firewall.

References

1.  OWASP SQL injection. Available: https://www.owasp.org/index.php/SQL_Injection
2.  PHP SQL injection manual. Available: http://php.net/manual/en/security.database.sql-injection.php
3.  PHP SQL Parser incorporated in the framework. Available at https://github.com/greenlion/PHP-SQL-Parser.
4.  Formal semantics of SQL queries. Available at http://dl.acm.org/citation.cfm?id=111212/

I hope the article highlighted some key aspects how semantics can play a role in preventing SQL injection. Your comments and suggestion are most welcome.