The verification portal seems to depend on keycloak as an authentication provider. It would be helpful for development if there was an easy way to start up a preconfigured local keycloak instance.
Could you maybe provide a docker compose file to start up a dockerized keycloak instance? Or at least document the necessary configuration steps for setting up keycloak. Thank you!

Current Implementation

Current version does not contain any running unit/integration Test.

Suggested Enhancement

Write unit + integration tests.

Expected Benefits

Verify correct behavior of functionality.

Describe the bug

Security risks from inside an organisation are often underestimated. Let's see how this may be a problem for the Corona app.

Quote from https://www.chip.de/news/Corona-App-steht-kurz-vor-dem-Start-Scheitert-das-Warn-Tool-an-einem-einfachen-Problem_182639402.html
_

Knapp 1.000 Anrufe soll die Hotline pro Tag bewältigen können. Nach Spiegel-Informationen sollen bereits Probeläufe gezeigt haben, dass das System funktioniert. Das Call-Center betreibt ein externen Dienstleister. Ob dieser in Deutschland sitzt, ist unklar.

_

A hotline agent currently is a trusted person who may create teleTans. Problem : is it correct to trust him if one even doesn't know if he works in Germany, Croatia, India or even a prison in the US?

Currently a hotline agent can create teleTans without the knowledge of a supervisor. It is not even possible to trace who created which teleTan.

Expected behaviour

It is easy to create teleTans that could be misused. Don't ask for a misuse scenario - as long as it is possible there will be an invalid use.

Possible Fix

Log teleTan creation with hotline agent id and date/time.

See also CWA_Documentation issue #129

Problem description

TeleTan Portal for WRU works unstable, generating new teletan is unresponsive and leads to error message that 'due to internal error, new teletan cannot be generated'

Error messages appear
Time limitations appear
See attached pictures

Link to Tester's Jira

https://jira.itc.sap.com/projects/EXPOSUREAPP/issues/EXPOSUREAPP-1680

The README.MD says:

In other words: For all People who are willing to join the tracing process, but have not been tested by one of the participating laboratories, there will be a service hotline one can call to get a temporary Transaction Authentication Number (TAN) to join the process. The agents at the service hotline will ask the caller some questions to verify his status and then provide one with a TAN.

To me that sounds as if teleTANs can be generated by hotline users without a positive test to aid the tracing process.

While I welcome this feature, I am confused as it was declared out of scope so far in cwa-documentation.

If this is part of the first release, great! Will the teleTAN without test be of a separate kind as other teleTANs? If yes, that process is missing in the solution architecture document. If not, how would a second-degree contact be able to differentiate between a real exposure notification and a notification for contact tracing with confirmed test?

If this paragraph does not talk about teleTANs before positive test or second-degree contact tracing, what else does it mean?

Current Implementation

Suggested Enhancement

Expected Benefits

Rating: High

Description:
The application is vulnerable to Cross-Site Request Forgery (CSRF/XSRF)
attacks.

A CSRF attack leverages the fact that in many cases browser requests
automatically include any credentials associated with the requested site, such
as the session cookies. This leaves no way for the application to distinguish
between forged and legitimate requests. Attacks typically target requests that
change the state of victim's data on the server (e.g. change password and
email address functionalities). The attack can be performed by sending a URL
to a victim. Visiting this URL will then execute an action on behalf of the
user.

In this case, a CSRF attack can be used to generate TeleTANs on behalf of a
logged in user. The nature of a CSRF attack does not allow the attacker to
retrieve the generated TANs. However, as the generation of TeleTANs is not
rate limited, an attacker can force a user, using a CSRF attack, to create a
large number of TeleTANs. This results in a strongly decreased search space
for the available TeleTANs. In a second step, this circumstance simplifies
brute-force attacks on a valid TeleTAN. The more TeleTANs are created, the
higher the probability to brute-force a correct one.

A recent change in the code adapted the requests verbs for the TeleTAN
retrieval from GET to POST requests, with the POST requests implementing CSRF
protection. However, this change was only applied on the client-side, not on
the server side. The server still accepts GET requests for generating a
TeleTAN. Therefore, this issue can be solved by disabling the GET verb on
these requests (see

Proof of Concept:
The following request-response pair shows that the TeleTAN can be obtained via a GET request:

GET /cwa/teletan HTTP/1.1
Host: verification-portal-0cebc62a.coronawarn.app
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://verification-server/cwa/start
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Connection: close
Cookie: JSESSIONID=[REDACTED]; OAuth_Token_Request_State=[REDACTED]
Upgrade-Insecure-Requests: 1

HTTP/1.1 200
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Date: Mon, 08 Jun 2020 18:15:03 GMT
Connection: close
Content-Length: 1948

[...]

An attacker can craft, for example, a form that triggers this request on behalf of a user as follows:

<html>
  <body>
    <form action="https://verification-server/cwa/teletan">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Similar to the description in the issue cwa-app-ios#149 there exists on fossies.org also a regularly updated codespell report for "cwa-verification-portal":

  https://fossies.org/linux/test/cwa-verification-portal-master.tar.gz/codespell.html

It is advised by the docker community to not run processes inside a docker container as root, as it may give additional freedom to a successful attacker.

The dockerfiles listed should change the executing user to something else than root especially the one running mvn:

https://github.com/corona-warn-app/cwa-verification-portal/blob/master/Dockerfile
https://github.com/corona-warn-app/cwa-verification-portal/blob/master/DockerfilePaaS

Problem description:

When a user logs in (via the cwa-verification-iam), the cwa-verification-portal creates a session which is stored:

• in the cwa-verification-portal's session store (this is handles by Spring Boot)
• and in the user's browser as a cookie (SESSION).

For the further HTTP requests (e.g., generate TeleTan), the cwa-verification-portal verifies the created session, which is sent along with the requests. The cwa-verification-portal does not redirects the user to the cwa-verification-iam for authentication and authorization, unless the session has expired or is invalid.

The above described scenario works well, when only one instance (Pod) of the cwa-verification-portal is active in the OpenShift environment. As soon as more Pods become active, a session created by one Pod can end up in a different Pod. This causes the cwa-verification-portal redirecting the user to the cwa-verification-iam for authentication, since the session is invalid for that Pod. This can trigger an endless loop. Moreover, when loading resources such as images or CSS stylesheets, the redirection to the cwa-verification-iam violates Content-Security-Policy default-src 'self', causing the browser not loading the requested resources.

Possible Solution:

There are several approaches (e.g., sticky sessions, stateless application, session container) that can be implemented. The following links provides some insights to solve this problem:

https://www.haproxy.com/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/

https://developers.redhat.com/blog/2018/05/04/externalized-http-session-in-openshift-3-9/

https://golb.hplar.ch/2019/05/stateless.html

Rating: Low

Description:
The Verification Portal does not offer the possibility for a user to change
their password. This limits the user to the password they initially chose. In
case a user's password leaks in any way, the affected user will not be able to
change the password.

Feature description

Additional to the Hotline the Gesundheitsamt Köln shall be enabled to access the Verification Portal to be able to generate teleTANs