On the user management webpage: http://localhost:8080/admin/user-management, it is possible to sort columns and the following URL can be observed when sorting by Login:
http://localhost:8080/admin/user-management?page=1&sort=login,desc
The data displayed on the screen is from the generators/server/templates/src/main/java/package/domain/User.java.ejs which contains data from the jhi_user database table. The issue is that some properties of the model contain security related data and that an administrator can sort them out. For example:
http://localhost:8080/admin/user-management?page=1&sort=password,desc
In this case, the password property is the password_hash column of the database.
Even if this feature is supposed to be only for administrative purpose, thus requiring a high privilege account, the password and resetKey properties should not be exposed.
Indeed, the resetKey of any user could be retrieved with the following methodology:
resetKey with a user we want to retrieve its resetKeyresetKey of a certain userThis technique would require a lot of requests to generate resetKey that would allow retrieving the resetKey of another user because of its 20 character lengths. It is pretty unlikely that a working attack could be made.
This technique can not be applied to the password as the bcrypt hashing algorithm is used and contains a random salt that is unkown to an attacker.
Moreover, this technique could be applied to any other data exposed by the model.
Explains on last paragraph
N/A
Security related elements specific to a user should not be present in a model used for arbitrary sorting to a user/administrator.
[email protected] /home/laxa/Documents/blog
└── [email protected]
##### **JHipster configuration**
{
"generator-jhipster": {
"promptValues": {
"packageName": "org.jhipster.blog"
},
"jhipsterVersion": "6.10.1",
"applicationType": "monolith",
"baseName": "blog",
"packageName": "org.jhipster.blog",
"packageFolder": "org/jhipster/blog",
"serverPort": "8080",
"authenticationType": "jwt",
"cacheProvider": "ehcache",
"enableHibernateCache": true,
"websocket": false,
"databaseType": "sql",
"devDatabaseType": "mysql",
"prodDatabaseType": "mysql",
"searchEngine": false,
"messageBroker": false,
"serviceDiscoveryType": false,
"buildTool": "maven",
"enableSwaggerCodegen": false,
"jwtSecretKey": "YourJWTSecretKeyWasReplacedByThisMeaninglessTextByTheJHipsterInfoCommandForObviousSecurityReasons",
"embeddableLaunchScript": false,
"useSass": true,
"clientPackageManager": "npm",
"clientFramework": "react",
"clientTheme": "none",
"clientThemeVariant": "",
"creationTimestamp": 1598011041769,
"testFrameworks": [],
"jhiPrefix": "jhi",
"entitySuffix": "",
"dtoSuffix": "DTO",
"otherModules": [],
"enableTranslation": false,
"blueprints": []
}
}
entityName.json files generated in the .jhipster directory
N/A
Not applicable here
Thanks for opening this issue @laxaa
cc @jhipster/developers : we need to take a look to this important ticket and confirm this issue
cc @avdev4j @nassimerrahoui @adilabed
I must admit I don't understand the attack vector here completely (but I trust you here @laxaa), but I totally agree we should not allow sorting by password(hash) or reset keys. I can reproduce it by the way (sorting by password).
+1 to remove the sort. If I understand well, by looking at the position of your own account compared to the others, you can get reduced intervals of possible reset keys which would lower the barrier for a brute force attack. It would still be hard to get a reset keys that way but as it's easier than a brute force over the full key space, a fix is required.
I'm taking this one
Thanks @avdev4j
Can you do 2 PR, for master and maintenance branch plz ?
+1 to remove the sort. If I understand well, by looking at the position of your own account compared to the others, you can get reduced intervals of possible reset keys which would lower the barrier for a brute force attack. It would still be hard to get a reset keys that way but as it's easier than a brute force over the full key space, a fix is required.
Hello everyone, thank you for the reply. Indeed, my explication is not the best and @cbornet explained exactly what I meant :). This attack vector is really improbable considering the amount of requests that would be needed.
Thanks for spotting this vulnerability @laxaa . This is clearly one that only someone with very good security background can spot !