The security concept is separated into two parts: the vulnerabilities of the Flarecast infrastructure and the protection of confidential resources.
Infrastructure valnerabilities
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 seperate 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. |
| 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 sesponse's header information | - | 0 | 0 | - |
| 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. Harmless, due the secured connection to the internal infrastructure. | - | 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. There is no link to an external site. (anyway harmless) | - | 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 targed web application, e.g. due 'header injection' or a DDoS attack. This may results in a XSS where the script's origin is equal to the targed's web application. | Dipends 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 victims 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 targed web application is overlayed with a transparent site provided by the attacker. Victim's interaction 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-midle 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 applcation inside his own frame. Hereby, if the web application e.g. uses the javascript object parent.location it access the attackers frame instead of it's own the 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 unintentially processed as statements due insufficient input filtering. E.g. a malicious script from XSS could produce a HTTP request for a recource 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 / | Vulnerabilities mainly relaited to web applications written in a low-level programming language such as C or C++. Hereby, the attacker tries to provoke an undesired behaviour 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. |
Authentification 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 convinient for end-users to authentificate themselves over a login page applications require an automated process. Hereby, we introduce two authentification machanisms for end-users and applications, such as Flarecast services and algorithms.
| Authentification Mechanism | Used By | Description | Protection Level |
|---|---|---|---|
| Session Login | End-Users | Restricts the permission on specific routes by validating the session ID of a request. If an end-user does not hold an approved session ID he has to authenticate himself over a login page with a username and password. If the login was successful the end-user's session ID becomes active. | Web pages with restricted functions. |
| oAuth2 | Applications | Restricts the permission on specific routes by validating an access token within the request's header. If an application does not hold an active access token it has to request a token from the oAuth2 authentification server. | Restricted REST resources. |
While it is convinient for an end-user to login