Security Concept

The security concept is separated into two parts: the vulnerabilities of the Flarecast infrastructure and the protection of confidential resources.

Infrastructure vulnerabilities

The first part concerns attacks against the infrastructure from external or internal sources. This includes any kind of vectors including data manipulation as well as service disruption.

Security vulnerabilities affects two aspects of the infrastructure:

• Internal infrastructure which is only available over a secure connection (SSH) and by authenticated users
• Infrastructure with public interfaces which obtains data by a read-only database

An attack on the internal infrastructure is very unlikely due the secure connection and the insensitive nature of space weather data. To reduce the vulnerability on the public interfaces we provide a separate database with read-only access which is periodically synchronized with the internal Flarecast database. Hereby, only attacks involving a service disruption are possible.

The following table gives a summary of possible attack vectors, there risk and impact level as well as possible countermeasures.

Attack Vector	Description	Security Notes	Risk Level (1 - 5)	Impact Level (1 - 5)	Recommended Countermeasure
Attacks concerning general web applications
Session hijacking	Attacker uses e.g. a man-in-the-middle attack while victim has an open connection to the web application. Hereby, the attacker obtains the authorized session ID of the victim.	Due a required SSH connection it is very unlikely as an attacker gets access to the internal infrastructure.	1	5	Keep informed about issues concerning secure connections (e.g. OpenSSL vulnerability CVE-2016-6304).
Cross-site request forgery (XSRF, CSRF)	Victim has an open connection to the web application and runs a malicious script downloaded from an attacker's server.	Depends on web browser. All modern browsers support same-origin-policy.	1	4	Use Nonce tokens.
Session fixation	Attacker provides a URL, e.g. by mail, with a pre-defined session ID to the victim. As soon as the victim logs into the trusted web application the attacker can use the same session ID for his own requests.	Due a required SSH connection it is very unlikely as an attacker gets access to the internal infrastructure.	1	3	Inform end-users about the risk. Verify provided URLs wherever they are manipulated.
Cross-site scripting (XSS)	Victim/Docker container uploads malicious script which is executed while visualizing data by a web service.	-	1	4	Use character escaping.
Open redirection	Attacker provides a URL, e.g. to a trusted login site, with a manipulated redirection parameter to the victim. After the victim logged into the system the trusted web application redirects the victim to the malicious web site, e.g. a copy of the original site.	This may be a problem with oAuth2 and the 'token' response type. Not trivial as oAuth2 validates the redirection URL.	1	2	Use character escaping.
Mixed content	Due the mix of resources partly available by HTTP and partly by HTTPS e.g. a man-in-the-middle attack is possible.	Due a required SSH connection it is very unlikely as an attacker gets access to the internal infrastructure.	1	0	-
Cross-site script inclusion (XSSI)	Victim has an open VPN session and forwards JSON responses due a malicious script downloaded from an attacker's server.	Possible but harmless, as all available resources are non-confidential.	0	0	-
Header injection (response splitting)	Victim/Attacker sends a request with a manipulated header field provided as query parameter which is then used within the response header.	There is no route which allows to set the response's header information.	0	0	-
Referer leakage	Victim calls an external link from a sensitive URL which is then published within the 'referer' header field of the request to the external site.	Harmless. There is no link to an external site.	0	0	-
Specific to the design of web applications
Denial-of-service (DoS) attacks	Attacker disrupt service by flooding it with requests.	Due a dedicated DDoS mitigation appliance.	4	4	-
Cache poisoning	Victim's browser cache or proxy gets poisoned with a malicious version of the target web application, e.g. due 'header injection' or a DDoS attack. This may result in a XSS where the script's origin is equal to the target's web application.	Depends on the client environment (browser, proxy, ...).	2	4	Keep informed about proxy/caching issues. However, cache poisoning is very hard to detect!
Content and character set sniffing	The victim's browser tries to 'correctly interpret' inconsistent content or character sets. E.g., an UTF-7 coded script may be interpreted as valid code also the website's character set is UTF-8. This may bypass the (UTF-8) character escaping on the server-side and allows XSS.	-	1	4	Check encoding of uploaded data.
Clickjacking	The target web application is overlayed with a transparent site provided by the attacker. Victim's interactions are undesirably send to the attackers site.	-	1	1	Use "frame-breaker" script.
Cookie forcing (cookie injection)	Attacker injects a cookie into the context of a web application, e.g. using a man-in-the-middle attack, which could be used with session fixation.	Unlikely, due a required SSH connection to the internal infrastructure.	1	1	Unknown
Framebusting	Attacker encloses the victims framed web application inside his own frame. Hereby, if the web application e.g. uses the javascript object parent.location it access the attackers frame instead of its own top-level document.	This is not an issue as no frame is used by any Flarecast service.	0	0	-
HTTP downgrade	Attacker forces victim, e.g. by DDoS, to use HTTP instead of HTTPS for connecting to a web application.	Harmless, due a required SSH connection to the internal infrastructure.	0	0	-
Specific to the server-side code
Command injection (SQL, shell, PHP, …)	Given URL parameters are unintendedly processed as statements due insufficient input filtering. E.g. a malicious script from XSS could produce a HTTP request for a resource which ID filter parameter is a masked SQL statements.	-	2	4	Use character escaping.
Directory traversal	An attacker or script travers systematically a web application's paths searching for files at arbitrary locations.	Harmless, as the Flarecast infrastructure do not provide sensitive files.	0	0	-
Parameter Tampering	An attacker or script manipulates systematically an URL's parameter to access arbitrary resources. E.g. incrementing the URL's filter ID on a page to view a specific resource.	Harmless, as the Flarecast infrastructure do not provide sensitive resources.	0	0	-
File inclusion	An attacker or script specifies a remote file to read from within a HTML request. E.g. a web application expects a language, e.g. 'en', as parameter which is used to load a local translation file but gets a URL.	Harmless, as the Flarecast infrastructure do not provide file related parameters.	0	0	-
Buffer overflow / Integer overflow / Pointer management vulnerability	Vulnerabilities mainly related to web applications written in a low-level programming language such as C or C++. Hereby, the attacker tries to provoke an undesired behavior by the web application due memory corruption.	Harmless, as the Flarecast infrastructure is written in Python; overflows produce exceptions.	0	0	-
Specific to Flarecast
Running malicious containers	Attacker or victim injects a malicious algorithm as Docker container within the Flarecast infrastructure.	-	3	4	Define reviewing process for Docker containers.

Authentication mechanisms

The second part concerns a user and client management system for preventing undesired data manipulations within the internal infrastructure as well as protecting administrative operations.

While it is convenient for end-users to authenticate themselves over a login page applications require an automated process. Hereby, we introduce two authentication mechanisms for end-users and applications, such as Flarecast services and algorithms.

Depending on the use-case, oAuth2 provides multiple authentication and administration methods, called grant types, which are given in the following table. Hereby, an application, called client, can request an access token for a specific scope set.

* The redirect_uri is validated by oAuth2 due open redirection vulnerabilities. (see previous section)

In some scenarios, e.g. with the grant type "Authorization Code", a client probably would like to verify its received access token. As the RFC6749 for oAuth2 does not define such a scenario we adapted a common implementation, e.g. used by Google and Amazon, which provides a separate URL:

The following examples show concrete use-cases where the session login and oAuth2 mechanisms are used within the Flarecast infrastructure.

1. InfraViewer
   

   Request	Description	Response
   POST /login	The end-user performs a login with his username and password.	The InfraViewer verifies the user's authentication and, if successful, requests an access token from the oAuth2 server (using the 'password' grant type). The end-user is then redirected to his original page either with or without a valid session ID and access token cookie. Depending on those cookies the end-user gets access to restricted operations, depending on his session ID, or can request secured resources, using his access token.
   GET /resource_1	The end-user requests a non-secured resource from the InfraViewer.	The InfraViewer response with the requested JSON object, without requiring any authentication.
   POST /resource_1	The end-user requests a secured resource from the InfraViewer.	The InfraViewer response either with the requested JSON object, given a valid access token, or with an error page.

2. Swagger UI
   

   Request	Description	Response
   GET /oauth/authorize	The end-user requests an access token for the Swagger UI which then can access secured resources.	If the end-user holds a valid session ID he is redirected to an authorization page from the oAuth2 server where he can grant Swagger UI to request an access token (using the 'authorization code' grant type). Otherwise, the user is redirected to a login form where he needs to authenticate himself before accessing the authorization page.
   GET /resource_1	The end-user requests a non-secured resource from the Swagger UI.	The Swagger UI response with the requested JSON object, without requiring any authentication.
   POST /resource_1	The end-user requests a secured resource from the Swagger UI.	The Swagger UI response either with the requested JSON object, given a valid access token, or with an error page.

3. Algorithms within a Docker container
   

   Request	Description	Response
   GET /resource_1	The algorithm requests a non-secured resource from the Swagger UI.	The service response with the requested JSON object, without requiring any authentication.
   POST /resource_1	The algorithm requests a secured resource from the Swagger UI.	The service response either with the requested JSON object, given a valid access token, or with an error page. The algorithm's access token is injected by the Workflow Management Service during startup. Hence, only algorithms running on the cluster obtain a valid access token to manipulate data within the infrastructure.

Technical Details

By the above section we described the workflows of a session login and oAuth2 authentication. The concrete implementation is given by two Flask-add-ons which are built on the top of our web servers used within the Flarecast infrastructure.

The integration of the two packages can be found within the python-base image. Hereby, the following files are involved:

1. flask_login:

   File	Description	Highlights
   /flarecast/service/flarecast_service.py	Wrapper class for the Connexion framework (including Flask & Swagger).	Expand source # Initialize flask_login login_manager = flask_login.LoginManager() login_manager.init_app(app.app) # set login view which is used for unauthorized # users which access protected ressources login_manager.login_view = "/login" # callback used for reloading a user based on # the request's session information @login_manager.user_loader def load_user(user_id): with AdminDAO() as ctx: return ctx.get_user_by_id(user_id) return None
   /flarecast/service/models.py	Module which holds all models required by flask_login and flask_oauthlib.	Expand source # class which holds all user related information class User(UserMixin): def __init__( self, id, name, password_hash, is_authenticated=False, is_active=False, is_anonymous=True ): self.id = id self.name = name self.password_hash = password_hash self.authenticated = is_authenticated self.active = is_active self.anonymous = is_anonymous def set_password_hash(self, password): self.password_hash = md5(password+self.name).hexdigest() def is_correct_password(self, password): return self.password_hash == md5(password + self.name).hexdigest() # ...
   /flarecast/service/users/views.py	Blueprint of the user login and logout pages.	Expand source @blueprint.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': form = LoginForm(request.form)  with AdminDAO() as ctx: # load user from database user = ctx.get_user_by_name(form.username.data) if ( user is not None and user.is_correct_password(form.password.data) ): # set flag as user was authenticated user.set_authenticated(True) with AdminDAO() as ctx: ctx.update_user_is_authenticated( user.id, user.is_authenticated ) # create session cookies with user and session IDs login_user(user) return redirect(redirect_url('ui')) return render_template('login.html', form=form)
   /flarecast/service/admin_dao.py	The data access object (DAO) which maps requests and database cursers to database queries and python objects.	Expand source # ...

2. flask_oauthlib

   File	Description	Highlights
   /flarecast/service/flarecast_service.py	Wrapper class for the Connexion framework (including Flask & Swagger).	Expand source # Initialize provider from flask_oauthlib oauth = FlarecastProvider() oauth.init_app(app.app) app.app.config.update( # set default error page OAUTH2_PROVIDER_ERROR_ENDPOINT='/error', # set expire time in seconds for access tokens (86400s = 1d) OAUTH2_PROVIDER_TOKEN_EXPIRES_IN=86400 )
   /flarecast/service/models.py	Module which holds all models required by flask_login and flask_oauthlib.	Expand source # ...
   /flarecast/service/oauth/views.py	Blueprint for authorize, access, revoke and validate access tokens. Each route is wrapped by a function provided by flask_oauthlib which implements the authorization flow.	Expand source # authorization route where the end-user grant's an access token for a client @blueprint.route('/oauth/authorize', methods=['GET', 'POST']) @flask_login.login_required # route req. session login @oauth.authorize_handler def authorize(*args, **kwargs): if request.method == 'GET': with AdminDAO() as ctx: client = ctx.get_client_by_id(int(kwargs.get('client_id'))) return render_template('confirm.html', **kwargs) confirm = request.form.get('confirm', 'no') return confirm == 'yes' # request route for access tokens @blueprint.route('/oauth/token', methods=['POST']) @oauth.token_handler def access_token(): return {'version': '1.0.0'} # route for revoke access tokens @blueprint.route('/oauth/revoke', methods=['POST']) @oauth.revoke_handler def revoke_token(): pass # route for verifying access tokens @blueprint.route('/oauth/tokeninfo') def get_tokeninfo(): if "access_token" in request.args: with AdminDAO() as ctx: bearer_token = ctx.get_bearer_token_by_access_token( request.args.get("access_token") ) if bearer_token is not None: return jsonify( {'uid': bearer_token.id, 'scope': bearer_token.scopes} ) return 'No such token', 401
   /flarecast/service/admin_dao.py	The data access object (DAO) which maps requests and database cursers to database queries and python objects.	Expand source # ...

A last missing fragment is the database schema which persistently stores the users, clients and tokens referred above:

The central entity is the user which, by assumption, owns resources he grants access to. A client can then define reliable clients and administrate there grant as well as bearer (access) tokens. This workflow however is not defined by the above database schema nor oAuth2. Flarecast do not provide corresponding functionalities for managing users at the moment, so each user has to be manually added to the database. Furthermore, a fine-grained user management system may add some user roles which could then be mapped to specific scopes. An example is given by the following table: