Web panel for an IaaS application called Openhuaca

Web panel for an IaaS application called Openhuaca A Degree Thesis Submitted to the Faculty of the Escola Tècnica d'Enginyeria de Telecomunicació de Barcelona Universitat Politècnica de Catalunya by Gerard Bernadó Cadenas In partial fulfilment of the requirements for the degree in TELEMATICS ENGINEERING Advisor: Jose Luís Muñoz Tapia Barcelona, June 2017 1 Abstract The purpose of this project then is to create an interactive web panel for a CLI application that is also being developed in this department called Openhuaca. Openhuaca is a BASH application that works in CLI, command line interface and it is dependent of Linux Containers(LXC). The LXC is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single host. With containers, a single Linux kernel is shared between the host and the virtual machines and thus containers can achieve higher densities of isolated environments than when using virtual machines. The scope of the project is to provide the users an easy and intuitive use of the main features of the Openhuaca CLI application without knowing the technical aspects of it. From within our application we should be able to perform all the basic actions from the CLI application: - Create/Destroy containers. - Start/stop/freeze existing containers. - Check the configuration of the containers. - Check the status of the network. - Create/Delete users in the application 2 Resum L’objectiu del projecte es el crear una plataforma web interactiva per una aplicació, que està essent creada en aquest mateix moment pel departament de Telemàtica, anomenada Openhuaca. Openhuaca es una aplicació en BASH que treballa en una interfície de consola de comandes i està basada en LXC. LXC és una tecnologia de virtualizació en el nivell de sistema operatiu (SO) que permet córrer diferents sistemes Linux aïllats entre sí, en la mateixa màquina. Am bels contenidors, un únic kernel Linux és compartit entre la màquina host i les màquines virtuals. L’objectiu del projecte és doncs, proveir al usuari una eina fácil i intuitiva per a poder fer servir les principals característiques de la aplicación Openhuaca sense la necessitat de conèixer els aspectes més tècnics d’aquesta. Desde la nostra aplicació, podrem ser capaços de portar a terme les següents accions: - Crear/Borrar contenidors. - Arrancar/Parar/Congelar un contenidor existent. - Comprovar la configuració dels contenidors. - Comprovar la informació de la xarxa. - Crear/Borrar usuaris a la aplicación. 3 Resumen El objetivo del proyecto es crear una plataforma web interactiva por una aplicación, que está siendo creada en este mismo momento por el departamento de Telemática, llamada Openhuaca. Openhuaca se una aplicación en BASH que trabaja en una interfaz de consola de pedidos y está basada en LXC. LXC es una tecnología de virtualizació en el nivel de sistema operativo (SONIDO) que permite correr diferentes sistemas Linux aislados entre sí, en la misma máquina. Am belios contenedores, un único kernel Linux es compartido entre la máquina hueste y las máquinas virtuales. El objetivo del proyecto es pues, proveer al usuario una herramienta fácil y intuitiva para poder usar las principales características de la aplicación Openhuaca sin la necesidad de conocer los aspectos más técnicos de esta. Desde nuestra aplicación, podremos ser capaces de llevar a cabo las siguientes acciones: - Crear/Borrar contenedores. - Arrancar/Parar/Congelar un contenedor existente. - Comprobar la configuración de los contenedores. - Comprobar la información de la red. - Crear/Borrar usuarios a la aplicación. 4 Revision history and approval record Revision Date Purpose 0 15/06 /2017 Document creation 1 20/06 /2017 Document first revision 2 27/06/17 Document second revision DOCUMENT DISTRIBUTION LIST Name e-mail Gerard Bernadó Cadenas ark[email protected] Jose Luis Muñoz Tapia jose.muno[email protected] Written by: Reviewed and approved by: Date 15/06/2017 Date 28/06/2017 Name Gerard Bernadó Cadenas Name Jose Luís Muñoz Tapia Position Project Author Position Project Supervisor 5 Table of contents The table of contents must be detailed. Each chapter and main section in the thesis must be listed in the “Table of Contents” and each must be given a page number for the location of a particular text. Abstract ............................................................................................................................ 1 Resum .............................................................................................................................. 2 Resumen .......................................................................................................................... 3 Revision history and approval record ................................................................................ 4 Table of contents .............................................................................................................. 5 List of Figures ................................................................................................................... 6 List of Tables: ................................................................................................................... 7 1. Introduction ................................................................................................................ 8 1.1. Work Plan ........................................................................................................... 9 1.1.1. Work Breakdown Structure .......................................................................... 9 1.1.2. Work Packages and Tasks .......................................................................... 9 1.1.3. Milestones ................................................................................................. 13 1.1.4. Gantt Diagram ........................................................................................... 13 1.2. Incidences ........................................................................................................ 14 2. State of the art of the technology used or applied in this thesis: ............................... 15 2.1. Flask................................................................................................................. 15 2.2. Bootstrap .......................................................................................................... 15 3. Methodology / project development: ........................... ¡Error! Marcador no definido. 4. Results .................................................................................................................... 16 5. Budget ..................................................................................................................... 21 6. Conclusions and future development: ...................................................................... 22 Bibliography: ................................................................................................................... 23 Glossary ......................................................................................................................... 24 6 List of Figures Figure 1-Work breakdown Structure………………………….…….Page 9 Figure 2-Gantt Diagram………………….…………………….…….Page 13 Figure 3-Home page………………………..………………….…….Page 16 Figure 4-Create container modal…………………………….……..Page 16 Figure 5-Check LXC configuration page…………….………..……Page 17 Figure 6-LXC Network page……………………………………..….Page 17 Figure 7-Domain admins page…………………………………...…Page 18 Figure 8-Certificates management page………………………...…Page 18 Figure 9-Container information page……………………………….Page 19 Figure 10-Profile page……………………………………………….Page 19 Figure 11-Panel users page………………………………………...Page 20 Figure 12-New user modal………………………………………….Page 20 7 List of Tables: Each table in the thesis must be listed in the “List of Tables” and each must be given a page number for its easy location. Table 1Work package 1 Task 1……………………………………..…..Page 9 Table 2-Work Package 1 Task 2……………………….…………………Page 10 Table 3-Work Package 1 Task 3…………………………………….……Page 10 Table 4Work Package 2 Task 1………………………………………...Page 10 Table 5Work Package 2 Task 2……………………………………..….Page 11 Table 6Work Package 2 Task 3………………………………….……..Page 11 Table 7Work Package 3 Task 1…………………………………………Page 11 Table 8Work Package 3 Task 2………………………………………...Page 12 Table 9Work Package 3 Task 3……………………………………...…Page 12 Table 10-Work Package 4 Task 1 ……………………………………….Page 12 Table 11-Milestones……………......……………………………………..Page 13 Table 12-Budget Table……………………………………………………Page 21 8 1. Introduction The project idea is born after the finding of an original web panel for the LXC virtualization method application management. As the network department in the school is already developing an application based in this virtualization method, it surges the idea of having its own web panel for manage the application. Even that this project is based in another web panel, it starts from scratch and is developed at the same time that the application on which it relies. So teamwork and the ability to work under an unstable version of an application will be crucial to develop the application in the estimated time. The purpose of this project then is to create an interactive web panel for a CLI application that is also being developed in this department called Openhuaca. The scope is to provide the users an easy and intuitive use of the main features of the Openhuaca CLI application without knowing the technical aspects of it. The original application in which this project is based is called LXC-Web-Panel originally developed by Claudio Mignanti. This application is built using a Python framework for web applications called Flask and also uses a front-end web framework called Bootstrap. The development of the project required then to learn all the programming languages used in the original application. We were forced to work with “black boxes”, as we knew the commands of the CLI application and their behavior but we have not had access to them until they were developed in the CLI application. We had to find the security flaws of the frameworks we issued and learned how to solve them to prevent undesired data introduced in the application. a. Work plan with tasks, milestones and a Gantt diagram. b. Description of the deviations from the initial plan and incidences that may have occurred. 15 2. State of the art of the technology used or applied in this thesis: 2.1. Flask Flask is a microframework for Python based on Werkzeug and Jinja2. Werkzeug is a toolkit for WSGI, the standard Python interface between web applications and a variety of servers for both development and deployment. The job of Jinja2 is to render the templates. The “micro” in microframework means Flask aims to keep the core simple but extensible. The meaning of this is that all the design decisions are up to you. By convention, in Flask, templates and static files are stored in subdirectories within the application’s Python source tree, with the names templates and static respectively. In a Flask application the handlers that respond to requests from web browsers or other clients are called views, this views are written as Python functions and each one is mapped to one or more request URLs. So for a simple application in flask, the following will be needed:  A script that creates the flask application’s instance, which will be the WSGI application, this could be done in the __init__.py of our package or in another python script.  A handler that responds to the requests of client. We have called it views in the previous code.  A script that starts up the development web server with our application. 2.2. Bootstrap Bootstrap is a free and open-source front-end web framework for designing websites and web applications. It contains HTMLand CSS-based design templates for typography, forms, buttons, navigation and other interface components, as well as optional JavaScript extensions. 16 3. Results The application behaviour can be seen from the functions in the main view handler. Here are defined all pages of the application and the functions associated to them. Next are explained the different pages of the application with a brief description of its behaviour • /home is binded to the home( ) function. This is the main page of the application. We show all the user containers and information about them. In this page we have set a timer that will check if the user is still admin of his domain and if he is not, we provide a way to solve it. From this page, we can create new containers. • /action/create-container is binded to the create_container( ) function. In this page we ask the user for input to create the desired container and in the create_container( ) function we check that the input of the user is correctly escaped before attempting the action 17 • /checkconfig is binded to the checkconfig( ) function. This provides information about the lxc configuration: • /hwp/<domain>/lxc-net is binded to the lxc-net( domain=None ) function. This provides information about the selected domain’s network: 18 • /hwp/<domain>/users is binded to the hwp_domainusers( domain=None ) function. This provides information about the domain’s current admins: • /hwp/<domain>/certificates is binded to the hwp_certificates( domain=None ) function. Here we can see the current certificates in the domain with their status, who they are associated to and the expiration date. From this page new certificates can be created and existing ones can be revoked/active: 19 • /hwp/<domain>/<container>/info is binded to the info( domain=None, container=None ) function. Here we can see the current status of the container with some information about it. We can also see what users are created in the container: • /hwp/account/<username> is binded to the hwp_accsettings( username=None ) function. Here is presented the user personal information and we provide the option to change some of them: 20 • /hwp/panelusers is binded to the hwp_users( ) function. This page is only accessible to the user Huaca. Here we can create new users for the Web Panel, delete existing users and modify the parameters of existing users From this page we can create new users in the web panel, we can choose the containers that this user will has Access. Note: Even if the user was created, we will have to add manually the certificate, from the certificates page, for this user in the desired domain, to give him access to the containers. 21 4. Budget Junior Engineer Salary per hour: €20 Duration hours Cost (€) Understanding original app structure 30 600 € Learning Python language 30 600 € Learning Flask Framework 20 400 € Refresh HTML / CSS knowledges 10 200 € Studying framework used in original application Bootstrap 20 400 € Planning Openhuaca structure 12 240 € Planning Openhuaca app behaviour 12 240 € Huacalxc library creation 80 1.600 € Creation of new templates in application 20 400 € Application Intelligence 80 1.600 € Injection testing 6 120 € Correct behaviour of the application 6 120 € Project Plan 2 40 € CDR 3 60 € Final report 15 300 € Total 346 6.920 € 22 5. Conclusions and future development: The Web Panel application is yet to become working at fully potential. There are still more features that can be added to the application as are:  The ability to create new domains from the application.  Add clone feature for the existing containers.  Add backup feature for containers. Furthermore, when Openhuaca will be more stable and the behaviour is as expected. We could:  Adapt the code so the use of the local database is not needed. 23 Bibliography: [1] Original author: Antoine Tanzilli, Élie Deloumeau. Modified by Claudio Mignanti and lwp community. Original LXC-Web-Panel application. [Online] Available: https://github.com/claudyus/LXC-Web-Panel. [2] Armin Ronacher. Flask official documentation. [Online] Available: http://flask.pocoo.org/ [3] Published on December 7, 2015 by Ryan Reid. The nVisium Blog. Injecting flask. [Online] Available: https://nvisium.com/blog/2015/12/07/injecting-flask/ [4] Mark Otto and Fatrick. Official Bootstrap 2.3.2 documentation. [Online] Available: http://getbootstrap.com/2.3.2/components.html [5] General coding questions [Online] Available: www.stackoverflow.com [6] Miguel Grinberg. The Flask Mega-Tutorial. [Online] Available: https://blog.miguelgrinberg.com/post/theflask-mega-tutorial-part-i-hello-world [7] Refsnes Data. HTML Tutorial. [Online] Available: https://www.w3schools.com/html/ [8] Arnaldo Pérez Castaño. “JavaScript fácil”. Marcombo, 2014 [9] Flanagan, David. “JavaScript : the definitive guide”. O'Reilly, 1998 [10] Python Software Foundation. The Python Standard Library. [Online] Available: https://docs.python.org/2/library/index.html 24 Glossary CLI-Command Line Interface LXC-Linux Containers HTML-HyperText Markup Language CSS-Cascading Style Sheets If -s is specified, the user will be added to the sudoers group. huaca-user delete -d D_NAME -n C_NAME -u U_NAME huaca-user list -d D_NAME -n C_NAME huaca-user delete -d D_NAME -u U_NAME •huaca-certification - Options for this command are: { ca | cert }. The ca option allows us to create a new CA for a domain, delete an existing CA and list all current CAs in the application. Usage: huaca-certification ca {create | destroy} -d D_NAME huaca-certification ca list The cert option is used to manage certificates. Options for this command are: { create | revoke | purge | list }. Usage for this options is: huaca-certification cert create -d D_NAME -n C_NAME -w WEEKS The -w option are the weeks that this certificate will remain active. huaca-certification cert revoke -d D_NAME -u U_NAME This will revoke the user’s certificate for the specified domain. huaca-certification cert purge -d D_NAME This will remove all the expired certs in the specified domain. 1.2 Openhuaca Web Panel 1.2.1 Definition The Openhuaca Web Panel is designed to provide the users an easy and intuitive use of the main features of the Openhuaca CLI application without the need to know the technical aspects of it. The idea of this panel is based in an existing frontend project for LXC called LXC Web Panel, though there are some major differences between the original project and the one we present. There will be three kind of users that can log into our application: • The Huaca user is the application admin, he has access to all domains and to all containers in the Openhuaca application. He is also the only one that can create new users into the panel application. • The domain admin user, is named after the domain he administers. He has access to all containers from his domain and he can interactuate with them (start/stop/freeze/destroy). He can also create new containers in his domain. • A regular user will have access to some containers, which will be granted previously by a domain admin. The regular user actions are restricted to start/stop/freeze the containers they have access to. They cannot destroy existing containers nor create new ones. 6 1.2.2 Installation To start we need to install the LXC Web Panel repository in our virtual machine. You have different options to install it. The easiest way to do it is by using the bash script that will install it automatically. We will install it manually, this way we will have a more in depth view. In order to install a deb repo, first you need to install the GPG key that used to sign repository metadata. You do that using a utility called apt-key: $ curl -L https://packagecloud.io/claudyus/LXC-Web-Panel/gpgkey | sudo apt-key add - After that we will have to update our package cache by running: $ sudo apt-get update We will need to install a package called apt-transport-https to make it possible for apt to fetch packages over https. $ sudo apt-get install -y apt-transport-https Now we create a file named /etc/apt/sources.list.d/claudyus_LXC-Web-Panel.list that contains the repository configuration below. deb https://packagecloud.io/claudyus/LXC-Web-Panel/ubuntu/ trusty main deb-src https://packagecloud.io/claudyus/LXC-Web-Panel/ubuntu/ trusty main Make sure to replace ubuntu and trusty in the config below with your Linux distribution and version. You can know which version you have by typping: $ cat /proc/version There is an issue with ubuntu 16.04 installation in which if you put your version as it corresponds(which would be xenial), it won’t fetch the repository. The workaround here is to put an older version(trusty in our case), which will make the trick. Again, update the package cache : $ sudo apt-get update Finally we can install lwp by typing: $ sudo apt-get install lwp Once it is installed, we will need to copy /etc/lwp/lwp.example.conf to /etc/lwp/lwp.conf $ mv /etc/lwp/lwp.example.conf /etc/lwp/lwp.conf This is the configuration file which will be explained more detailed in section Configuration directory. You can start the application now by starting the service: $ sudo service lwp start You can check that it is working properly from your favorite browser and you should see something like in Figure 1.1 1.2.3 File system distribution After installing the application there are four important directories worth mentioning: 7 Figure 1.1: Login Page. 1.2.3.1 Configuration directory The configuration directory is in /etc/lwp/. This directory contains basically two files that the application will read when started: lwp.conf and session_secret •lwp.conf: This is the configuration file and here you can modify the address and port in which the application will run, you can enable/disable debugging to have a more in-depth detail of the errors thrown in the web application and you can set the authentication method. Right now our Openhuaca Web Panel only works with database authentication for reasons that will be explained with more detail further in the document. •session_secret: The session_secret is a file that contains the key that Flask’s session will use to sign the cookies. If this file doesn’t exist, you should create it by passing --generate-session-secret parameter to the application. See section 1.2.5.1 1.2.3.2 Database directory The database directory is in /var/lwp/. It contains an SQLite file with the tables shown in figures 1.2,1.3 and 1.4: • Users table is where the user information is stored, it contains the username, the id of the user and the password securely hashed before storing. • The other two tables are created as temporal helpers. As we defined before, the domain admin will have a certificate for his user in his domain and all the containers on the domain will have the admin user created in them. By that definition, we could know if the user is admin of a domain just by checking in the openhuaca application if the user has an active certificate in the domain and if all the containers in the domain contain that user via the commands huaca-certification and huaca-user. Here arises a problem because when we create a new container with huaca-create, it does not create the users huaca and domainadmin which should be present by default. This causes that if we make the comprobation of the user privileges with the previous explained method. Users huaca and domainadmin will automatically stop being admins of the domain where the new container was created. This two databases help us show the correct behaviour of the application by storing in them the current containers in the application, the users that are present in these containers and the users that should be present. 8 Figure 1.2: Users table. Figure 1.3: Containers table. Figure 1.4: User/Container relation table. 1.2.3.3 Openhuaca configuration directory Openhuaca application has its own configuration directory, which is located in /etc/huaca. Here are the main huaca configuration file (huaca.conf), the directory in which are defined the domains available and the directory in which all the application’s certificates are stored. 1.2.3.4 Openhuaca containers directory Containers are stored in the machine under the /var/lib/huaca/ directory. Containers are organized by the domain to which each one belong, so the structure of the containers directory would be like the one that can be seen in 1.5: 1.2.4 Openhuaca web panel architecture 1.2.5 Languages As we have based our panel in the original LXC Web Panel the languages used are in consequence inherited from the original application. The application’s backend intelligence is programmed in Python with the help of a web framework called Flask (see section 1.2.5.1) and the frontend is programmed in html/css using a framework for css called Bootstrap. 1.2.5.1 Flask Flask is a microframework for Python based on Werkzeug and Jinja2. Werkzeug is a toolkit for WSGI, the standard Python interface between web applications and a variety of servers for both development and deployment. The job of Jinja2 is to render the templates. The “micro” in microframework means Flask aims to keep the core simple but extensible. The meaning of this is that all the design decisions are up to you. By convention, in Flask, templates and static files are stored in subdirectories within the application’s Python source tree, with the names templates and static respectively. In a Flask application the handlers that respond to requests from web browsers or other clients are 9 Figure 1.5: Containers directory tree. called views, this views are written as Python functions and each one is mapped to one or more request URLs. So for a simple application in flask, the following will be needed: • A script that creates the flask application’s instance, which will be the WSGI application, this could be done in the __init__.py of our package or in another python script and it will look like this: from flask import Flask app = Flask(__name__) from simpleapp import views • A handler that responds to the requests of client. We have called it views in the previous code. This view function will look like this: from simpleapp import app @app.route('/') @app.route('/index') def index(): return "Hello, World!" The view is pretty simple, it just returns a string that will be displayed on the client’s web browser. The two route decorators above the function create the mappings from URLs /and /index to this function. • Finally we will have to create a script that starts up the development web server with our application: #! usr/bin/python from simpleapp import app app.run(debug=True) The script simply imports the app variable (which contains the flask instance) from our app package and invokes its run method to start the server To start the app you just have to run this script, which will need execution permissions. There are some features in flask that are used in our application and thus are worth mentioning them here. 10 Routing In the previous simple application example, we have seen how URLs are binded to a function via the route decorator. There is still more, you could also have variable parts in the URL. For example, if we had a function that shows us information about a country we could bind its URL like this: @app.route('/country/<name>') def country(name): return "\{0\}".\format(name) The special section <name> is a variable part, and it is passed to the function as a keyword. Another useful thing that flask can do is to build URLs to specific functions using the url_for() function. It accepts the name of the function as first argument and a number of keyword arguments, each corresponding to the variable part of the URL rule. Unknown variable parts are appended to the URL as query parameters. So for instance to access to our previous index() function of the simpleapp we will use: url_for('index') And to access the country function it will be: url_for('country', name='Germany') Rendering Templates To render a template you can use the render_template() method. You have to provide the name of the template and the variables you want to pass to the template engine as keyword arguments. Here is a simple example of how to render a template: from flask import render_template @app.route('/country/<name>') def showcountry(name=None): return render_template('showcountry.html', name=name) As stated earlier, Flask will look for templates in the templates folder. The templates can use the Jinja2 template engine. As an example, our previous template showcountry.html could be: <!doctype html> <title>Country information</title> {% if name %} <h1>The chosen country is {{ name }}!</h1> {% else %} <h1>We don't know which country you chose.</h1> {% endif %} Templates are very useful when inheritance is used. The template inheritance allows us to keep common elements on each page (like header, navigation and footer). Automatic escaping is enabled, so if name contains HTML it will be escaped automatically. Escaping is a thing to take in account when there is possible injection by part of the user; we will discuss the flaws of Flask in this aspect and how to solve them in section The Request Object The data from a client’s web page is sent to the server as a global request object. Some important attributes of the request object are: •form - It is a dictionary object containing key and value pairs of form parameters and their values. •args - A dictionary with the parsed contents of the query string. (The part in the URL after the question mark). •method - The current request method (POST, GET etc.) An example of the request object usage can be seen in the login() function of an application: 11 from flask import request @app.route('/login', methods=['POST', 'GET']) def login(): error = None if request.method == 'POST': if authenticate(request.form['username'], request.form['password']): return render_template('home.html') else: error = 'Failed to authenticate, try it again.' return render_template('login.html', error=error) Sessions The session object allows us to store information of a specific user from one request to the next. The data remains in the session until explicitly removed. Sessions are implemented on top of cookies and it signs them cryptographically. In order to achieve this, a Flask application needs a defined SECRET_KEY; this secret key should be as random as possible. A good idea to generate a secret key would be using the urandom() method: import os os.urandom(24) The session object is also a dictionary object containing key-value pairs of session variables and associated values. For example, to store the ‘username’ of an user in the session variable we use session['username'] = 'Gerard' And to release this session’s variable we use pop() method. session.pop('username', None) Blueprint A blueprint defines a collection of views, templates, static files and other elements that can be used in an application. The usefulness for blueprints is to organize our application into distinct components. Each distinct area of the site can be separated into distinct areas of the code as well. This allows us to structure our app as several smaller "apps" in which each one does one thing. The basic concept of blueprints is that they record operations that will be executed when registered on an application. Flask associates view functions with blueprints when dispatching requests and generating URLs from one endpoint to another. To exemplify the use of Blueprint, we will show you the Openhuaca Web panel authentication view. mod = Blueprint('auth', __name__) @mod.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': request_username = request.form['username'] request_passwd = request.form['password'] user = authenticate(request_username, request_passwd) if user: session['logged_in'] = True session['token'] = get_token() session['last_activity'] = int(time.time()) session['username'] = user['username'] session['idUser'] = user['id'] flash(u'You are logged in!', 'success') 12 return redirect(url_for('main.home')) flash(u'Invalid username or password!', 'error') return render_template('login.html') @mod.route('/logout') def logout(): session.pop('logged_in', None) session.pop('token', None) session.pop('last_activity', None) session.pop('username', None) flash(u'You are logged out!', 'success') return redirect(url_for('auth.login')) To create a blueprint object, we import the Blueprint() class and initialize it with the arguments name and import_name. Usually import_name will just be __name__, which is a special Python variable containing the name of the current module. As you can see, the syntax is very similar to the one we used when we binded URL to functions directly into Flask’s application instance. 1.2.5.2 Security in Flask The template engine provided within the Flask framework may allow developers to introduce Server-Side Template Injection vulnerabilities. This vulnerability could lead into a malicious user injecting language/syntax into our templates. Consider the following example: from flask import Flask, request, render_template_string, render_template app = Flask(__name__) @app.route('/magicword') def magicword(): person = {'name':"Guest", 'magicword':"potato"} if request.args.get('name'): person['name'] = request.args.get('name') template = '''<h2>Hello %s!</h2> <p>Enter the Magic Word<p> <input id="password1" name="pass" type="password"><button onclick="document.location='{{ url_for("magicword") }}' + '?password='+ document.getElementById('password1').value + '&name=%s'"> Submit</button>'''% (person['name'], person['name']) if request.args.get('password'): success = '''<h1>Congratulations %s, you win!</h1>'''% person['name'] error = '''<h1>This is not the magic word!</h1>''' if request.args.get('password') == person['magicword']: return render_template_string(success) return render_template_string(error) return render_template_string(template, person=person) if __name__ == "__main__": app.run(debug=True) When you navigate to the application it looks like this: But what happen if the user gives his name like this? Gerard {{ person.magicword }} Looks like you did not need to know the magicword beforehand to win. The issue arises due to the use of string concatenation or substitution. Jinja2 uses curly braces {{}} to surround variables used in the template. So the fix here would be placing our output inside these braces; this way, we will prevent user entered data containing template syntax from executing within the context of our server. 13 Figure 1.6: Application page. Figure 1.7: Application page with injection. template = '''<h2>Hello {{person.name}}!</h2> <p>Enter the Magic Word<p> <input id="password1" name="pass" type="password"><button onclick="document.location='{{ url_for("magicword") }}' + '?password='+ document.getElementById('password1').value + '&name={{ person.name }}'">Submit</button>''' Now, the output in the template is like this: Figure 1.8: Injection solved. Another issue with flask is Cross-Site Scripting. Flask does have an autoescape feature, but it is only enabled in templates ending in .html, .htm, .xml as well as .xhtml. You have to pay special attention when you use string template or when your templates use an ’unsafe’ extension. In our previous example, a malicious user could execute the code shown in figure 1.9 In these cases, you can use the tag {% autoescape %} to enable autoescaping or just pipe the output through the manual escape filter |e (see Figure 1.10). Finally even if autoescaping is enabled, Cross-Site Scripting could be still an issue if there is output directly in an HTML attribute context. To prevent this, the output in the attribute context should always be encapsulated in single/double quotes. 14 Figure 1.9: Execution of undesired code. Figure 1.10: Escaped undesired code. 1.2.6 Application structure The application structure is very similar to most Flask applications. Taking a look to our application source tree you can see the similarities: Figure 1.11: Application source tree. • The app.py script is where we create the Flask application’s instance and configure it. Here, we also register our views as blueprints. • In exceptions.py we have defined some exceptions for error handling. • In utils.py we defined some helper methods our application needs, as are the connection to database, the parsing of a database query and the parsing of a configuration file. • The user_mg.py (see section 1.2.6.1) is a script that provides methods for the management of the user containers/domains which will help when passing the arguments to the template. 15 Figure 1.19: Profile page. •/hwp/panelusers is binded to the hwp_users( ) function. This page is only accessible to the user Huaca. Here we can create new users for the Web Panel, delete existing users and modify the parameters of existing users(figure 1.20). Figure 1.20: Panel users page for Huaca. From this page we can create new users in the web panel, we can choose the containers that this user will has access(figure 1.21). Note: Even if the user was created, we will have to add manually the certificate, from the certificates page, for this user in the desired domain, to give him access to the containers. 22 Figure 1.21: Panel users page for Huaca. 23