The datasource password is contained in the response received by an authenticated administraive user. If SSL is not configured/used, this password may be exposed on the wire.
Statement: This issue is not a security flaw as, on its own, it does not cross a trust boundary in the system. In order to access the datasource password, you must be logged in to jopr as an administrative user, that has permission to (among other things) execute code, deploy applications and reset the password in question. The administrative user has the privileges to reset the password, hence, this does not expose any information that is not otherwise visible. As administrative interfaces often display or allow the transmission of sensitive information, it is recommended best-practice that SSL is configured for the administrative console, regardless of this issue.
I generally do not debate security for many reasons but there seems to be a misunderstanding here. SSL is not the real problem. That is a side issue. Of course, if a company is not using SSL then it can be captured. Yes, encourage the use of SSL as a compensating control for that. Very good. However, as a vendor, all efforts should be made to ensure that the application and its data is secure, even in lieu of user configurations. The bigger problem is that this allows an attacker to pivot and gain access to other systems NOT controlled or managed by JBoss. If console credentials are obtained through brute forcing or other means, the EXTERNAL database (SQL and alike) credentials are returned on the page. The database passwords are masked so it seems secure but if the attacker views the page source then the credentials can be obtained anyway. Why mask the password at all if it’s not sensitive? Imagine this (which really happened): 1. An attacker gains access to the JBoss admin console. The ability to upload applications is disabled so not that big of a deal. 2. The attacker views the data sources and the password is masked so again no big deal. 3. The attacker views the page source and finds the database password even though it’s hidden in number 2. 4. The attacker then uses these credentials to dump the entire external database containing very sensitive client data. In the above real life scenario if that password was not returned the attack would have stopped there and no real data would have been compromised. Masking the password is pointless if it is still returned in plaintext. Just don't return it at all. Furthermore, best practices dictates that under no circumstances should password data be returned to the end-user, especially a plaintext password. A security in-depth approach would also consider other factors, such as a potential XSS vector which could allow a user to exploit an XSS flaw and retrieve the value from the DOM and alike. Reference: CVE-2013-3734: Password Returned in Later Response