Notes |
|
(0001332)
|
dloper
|
2015-01-15 13:30
|
|
Changing to public. Not exploitable. |
|
|
(0001333)
|
dloper
|
2015-01-15 13:35
|
|
This appears to be a failure of the browser to properly submit the % followed by two hexadecimally valid characters [0-9,a-f,A-F]. In the example above 'clear%54' is seen by the system as 'clearT'.
Passing the ascii code for '%' is a workaround for input. The input of 'clear%2554' would render as 'clear%54' in the form data using the fields that we use.
We will need to tweak the field to override this behavior in the web browser to eliminate this problem.
Confirmed on: Chrome, Safari, Firefox |
|
|
(0001334)
|
dloper
|
2015-01-15 15:57
|
|
|
|
|
Here are two similar issues we had in Tiki:
Password will not be accepted when using @ > or < in the password string (with or without LDAP)
https://dev.tiki.org/item4599 [^]
LDAP authentication doesn't support special characters like "æ,ø,å" in CN name.
https://dev.tiki.org/item3984 [^]
Since all kinds of apps can authenticate against ClearOS-LDAP, perhaps it would make sense to be able to restrict risky special characters in passwords? (and if so, have a JavaScript error message when the user tries to type that character)
Issues like this are hard to detect because most users are fine, and only some will have issues. And since the admin doesn't know the passwords, it's hard to detect the pattern. |
|