71 lines
4.4 KiB
XML
71 lines
4.4 KiB
XML
|
<chapter id="security_vulnerabilities">
|
||
|
|
<title>Security Vulnerabilities</title>
|
||
|
|
<para>
|
||
|
|
This chapter discusses possible security vulnerabilities Keycloak could have, how Keycloak mitigates those
|
||
|
|
vulnerabilities, and what steps you need to do to configure Keycloak to mitigate some vulnerabilities. A good list
|
||
|
|
of potential vulnerabilities and what security implementations should do to mitigate them can be found in the
|
||
|
|
<ulink url="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Thread Model</ulink> document put out by the IETF. Many of those vulnerabilities are discussed here.
|
||
|
|
</para>
|
||
|
|
<section>
|
||
|
|
<title>SSL/HTTPS Requirement</title>
|
||
|
|
<para>
|
||
|
|
If you do not use SSL/HTTPS for all communication between the Keycloak auth server and the clients it secures
|
||
|
|
you will be very vulnerable to man in the middle attacks. OAuth 2.0/OpenID Connect uses access tokens for
|
||
|
|
security. Without SSL/HTTPS, attackers can sniff your network and obtain an access token. Once they have an
|
||
|
|
access token they can do any operation that the token has been given permission for.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Keycloak has <link linkend="ssl_modes">three modes for SSL/HTTPS</link>. SSL can be hard to set up, so out of the box, Keycloak allows
|
||
|
|
non-HTTPS communication over private IP addresses like localhost, 192.168.x.x, and other private IP addresses.
|
||
|
|
In production, you should make sure SSL is enabled and required across the board.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
On the adapter/client side, Keycloak allows you to turn off the SSL trust manager. The trust manager ensures
|
||
|
|
identity the client is talking to. It checks the DNS domain name against the server's certificate. In production
|
||
|
|
you should make sure that each of your client adapters is configured to use a truststore. Otherwise you are vulnerable
|
||
|
|
to DNS man in the middle attacks.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
<section>
|
||
|
|
<title>CSRF Attacks</title>
|
||
|
|
<para>
|
||
|
|
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP
|
||
|
|
requests are transmitted from a user that the web site trusts or has
|
||
|
|
authenticated (e.g., via HTTP redirects or HTML forms). Any site that uses
|
||
|
|
cookie based authentication is vulnerable for these types of attacks. These attacks are mitigated
|
||
|
|
by matching a state cookie against a posted form or query parameter.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
OAuth 2.0 login specification requires that a state cookie be used and matched against a transmitted state
|
||
|
|
parameter. Keycloak fully implements this part of the specification so all logins are protected.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
The Keycloak adminstration console is a pure Javascript/HTML5 application that makes REST calls to the
|
||
|
|
backend Keycloak admin API. These calls all require bearer token authentication and are made via Javascript
|
||
|
|
Ajax calls. CSRF does not apply here. The admin REST API can also be configured to validate CORS origins
|
||
|
|
as well.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
The only part of Keycloak that really falls into CSRF is the user account management pages. To mitigate this
|
||
|
|
Keycloak sets a state cookie and also embeds the value of this state cookie within hidden form fields or
|
||
|
|
query parameters in action links. This query or form parameter is checked against the state cookie to verify
|
||
|
|
that the call was made by the user.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
<section>
|
||
|
|
<title>Clickjacking</title>
|
||
|
|
<para>
|
||
|
|
With clickjacking, a malicious site loads the target site in a
|
||
|
|
transparent iFrame overlaid on top of a set of dummy
|
||
|
|
buttons that are carefully constructed to be placed directly under
|
||
|
|
important buttons on the target site. When a user clicks a visible
|
||
|
|
button, they are actually clicking a button (such as an "Authorize"
|
||
|
|
button) on the hidden page. An attacker can steal a user's authentication credentials and
|
||
|
|
access their resources.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
By default, every response by Keycloak sets some specific browser headers that can prevent this from happening
|
||
|
|
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</chapter>
|