cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amos Jianjun Kong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13455) derangement in decoding client token
Date Wed, 19 Apr 2017 01:35:41 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973866#comment-15973866
] 

Amos Jianjun Kong commented on CASSANDRA-13455:
-----------------------------------------------

[~snazy] You are right, current code can split the client response bytes rightly with single
'\000'.

The only problem is that it only checked null points, but lost checking of none strings.

```
-            if (pass == null)
+            if (pass == null || pass.length == 0)
                 throw new AuthenticationException("Password must not be null");
-            if (user == null)
+            if (user == null || user.length == 0)
                 throw new AuthenticationException("Authentication ID must not be null");
```




> derangement in decoding client token
> ------------------------------------
>
>                 Key: CASSANDRA-13455
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13455
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: CentOS7.2
> Java 1.8
>            Reporter: Amos Jianjun Kong
>            Assignee: Amos Jianjun Kong
>             Fix For: 3.10
>
>         Attachments: 0001-auth-strictly-delimit-in-decoding-client-token.patch
>
>
> RFC4616 requests AuthZID, USERNAME, PASSWORD are delimited by single '\000'.
> Current code actually delimits by serial '\000', when username or password
> is null, it caused decoding derangement.
> The problem was found in code review.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message