From 0b8b31a3ea7d8d7ac8b14a020613fc32aa5e9d9d Mon Sep 17 00:00:00 2001 From: Bill Burke Date: Fri, 19 Sep 2014 10:00:47 -0400 Subject: [PATCH 1/3] KEYCLOAK-705 --- pom.xml | 2 +- .../java/org/keycloak/services/resources/AccountService.java | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index 445508e35e..d6a86f6182 100755 --- a/pom.xml +++ b/pom.xml @@ -16,7 +16,7 @@ 1.9.9 4.2.1 2.3.7.Final - 3.0.8.Final + 3.0.9.Final 1.0.15.Final 2.7.0.Beta1 1.0.2.Final diff --git a/services/src/main/java/org/keycloak/services/resources/AccountService.java b/services/src/main/java/org/keycloak/services/resources/AccountService.java index 3c918cfec9..4ceb9f3e60 100755 --- a/services/src/main/java/org/keycloak/services/resources/AccountService.java +++ b/services/src/main/java/org/keycloak/services/resources/AccountService.java @@ -436,13 +436,15 @@ public class AccountService { @Path("totp-remove") @GET - public Response processTotpRemove() { + public Response processTotpRemove(@QueryParam("stateChecker") String stateChecker) { if (auth == null) { return login("totp"); } require(AccountRoles.MANAGE_ACCOUNT); + csrfCheck(stateChecker); + UserModel user = auth.getUser(); user.setTotp(false); From 53943f82468d3bb162fe0e3dc9a14e3eaf11b9e2 Mon Sep 17 00:00:00 2001 From: Bill Burke Date: Fri, 19 Sep 2014 11:03:08 -0400 Subject: [PATCH 2/3] KEYCLOAK-705 --- .../modules/security-vulnerabilities.xml | 71 +++++++++++++++++++ .../en/en-US/modules/server-installation.xml | 2 +- 2 files changed, 72 insertions(+), 1 deletion(-) create mode 100755 docbook/reference/en/en-US/modules/security-vulnerabilities.xml diff --git a/docbook/reference/en/en-US/modules/security-vulnerabilities.xml b/docbook/reference/en/en-US/modules/security-vulnerabilities.xml new file mode 100755 index 0000000000..e62b4635b9 --- /dev/null +++ b/docbook/reference/en/en-US/modules/security-vulnerabilities.xml @@ -0,0 +1,71 @@ + + Security Vulnerabilities + + 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 + OAuth 2.0 Thread Model document put out by the IETF. Many of those vulnerabilities are discussed here. + +
+ SSL/HTTPS Requirement + + 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. + + + Keycloak has three modes for SSL/HTTPS. 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. + + + 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. + +
+
+ CSRF Attacks + + 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. + + + 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. + + + 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. + + + 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. + +
+
+ Clickjacking + + 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. + + + By default, every response by Keycloak sets some specific browser headers that can prevent this from happening + + +
+ \ No newline at end of file diff --git a/docbook/reference/en/en-US/modules/server-installation.xml b/docbook/reference/en/en-US/modules/server-installation.xml index 4a0a34ed46..aadfba845f 100755 --- a/docbook/reference/en/en-US/modules/server-installation.xml +++ b/docbook/reference/en/en-US/modules/server-installation.xml @@ -404,7 +404,7 @@ keycloak-war-dist-all-&project.version;/ ]]> -
+
SSL/HTTPS Requirement/Modes From ef60e176415ecb1bc64b4bb0cabd565853170a23 Mon Sep 17 00:00:00 2001 From: Bill Burke Date: Fri, 19 Sep 2014 11:35:15 -0400 Subject: [PATCH 3/3] security vulnerability doc --- docbook/reference/en/en-US/master.xml | 2 + .../modules/security-vulnerabilities.xml | 86 ++++++++++++++++++- 2 files changed, 87 insertions(+), 1 deletion(-) diff --git a/docbook/reference/en/en-US/master.xml b/docbook/reference/en/en-US/master.xml index f591cfc9b4..39515eff45 100755 --- a/docbook/reference/en/en-US/master.xml +++ b/docbook/reference/en/en-US/master.xml @@ -31,6 +31,7 @@ + ]> @@ -119,6 +120,7 @@ This one is short &UserFederation; &ExportImport; &ServerCache; + &SecurityVulnerabilities; &Migration; diff --git a/docbook/reference/en/en-US/modules/security-vulnerabilities.xml b/docbook/reference/en/en-US/modules/security-vulnerabilities.xml index e62b4635b9..246cfd0954 100755 --- a/docbook/reference/en/en-US/modules/security-vulnerabilities.xml +++ b/docbook/reference/en/en-US/modules/security-vulnerabilities.xml @@ -65,7 +65,91 @@ By default, every response by Keycloak sets some specific browser headers that can prevent this from happening - + specifically X-FRAME_OPTIONS and Content-Security-Policy. You + should take a look at both of these headers. In the admin console you can specify the values these headers will + have. By default, Keycloak only sets up a same-origin policy for iframes. + +
+
+ Compromised Access Codes + + It would be very hard for an attacker to compromise Keycloak access codes. Keycloak generates a cryptographically + strong random value for its access codes so it would be very hard to guess an access token. + An access code can only be turned into an access token once so it can't be replayed. In the admin console + you can specify how long an access token is valid for. This value should be really short. Like a seconds. + Just long enough for the client to make the request to turn the code into an token. + +
+
+ Compromised access and refresh tokens + + There's a few things you can do to mitigate access tokens and refresh tokens from being stolen. + Most importantly is to enforce SSL/HTTPS communication between Keycloak and its clients and applications. + Short lifespans (minutes) for access tokens allows Keycloak to check the validity of a refresh token. Making + sure refresh tokens always stay private to the client and are never transmitted ever is very important as well. + + + If an access token or refresh token is compromised, the first thing you should do is go to the admin console + and push a not-before revocation policy to all applications. This will enforce that any tokens issued + prior to that date are now invalid. You can also disable specific applications, clients, and users if you + feel that any one of those entities is completely compromised. + +
+
+ Open redirectors + + An attacker could use the end-user authorization endpoint and the + redirect URI parameter to abuse the authorization server as an open + redirector. An open redirector is an endpoint using a parameter to + automatically redirect a user agent to the location specified by the + parameter value without any validation. An attacker could utilize a user's trust in an authorization + server to launch a phishing attack. + + + Keycloak requires that all registered applications and clients register at least one redirection uri pattern. + Any time a client asks Keycloak to perform a redirect (on login or logout for example), Keycloak will + check the redirect uri vs. the list of valid registered uri patterns. It is important that clients and + applications register as specific a URI pattern as possible to mitigate open redirector attacks. + +
+
+ Password guess: brute force attacks + + A brute force attack happens when an attacker is trying to guess a user's password. Keycloak has some + limited brute force detection capabilities. If turned on, a user account will be temporarily disabled + if a threshold of login failures is reached. The downside of this is that this makes Keycloak vulnerable + to denial of service attacks. Eventually we will expand this functionality to take client IP address into + account when deciding whether to block a user. + + + Another thing you can do to prevent password guessing is to point a tool like Fail2Ban to the Keycloak + server's log file. Keycloak logs every login failure and client IP address that had the failure. + + + In the admin console, per realm, you can set up a password policy to enforce that users pick hard to guess passwords. + + + Finally, the best way to mitigate against brute force attacks is to require user to set up a one-time-password (OTP). + +
+
+ Password database compromised + + Keycloak does not store passwords in raw text. It stores a hash of them. Because of performance reasons, + Keycloak only hashes passwords once. While a human could probably never crack a hashed password, it is very + possible that a computer could. The security community suggests around 20,000 (yes thousand!) hashing iterations + to be done to each password. This number grows every year due to increasing computing power (It was 1000 12 years ago). + The problem with this is that password hashing is a huge performance hit as each login would require the entered + password to be hashed that many times and compared to the stored hash. So, its up to the admin to configure the + password hash iterations. This can be done in the admin console password policy configuration. Again, the default + value is 1 as we thought it might be more important for Keycloak to scale out of the box. There's a lot of + other measures admins can do to protect their password databases. + +
+
+ SQL Injection attacks + + At this point in time, there is no knowledge of any SQL injection vulnerabilities in Keycloak
\ No newline at end of file