A user's Oracle login password was identified from a Qualys vulnerability scan of a Network Prevent for Web (NPW) server in the FileReader log like this for example:
File: FileReader1.log
Date: 05/01/2024 10:23:56
Class: com.vontu.icap.prevent.PreventProcessor
Method: processConnectionRequest
Level: FINEST
Message: On connection ID=2341 with message ID=xxxxx-xxxxxxx-xxxxx-xxxxxxxx sending HTTP message for detection: POST https://login.oracle.com/oam/server/sso/auth_cred_submit HTTP/1.1
Host: login.oracle.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Cookie: s_fid=1E542D663753FF24-015B785E9D5499DC; .................
............................
Context=1.005uq3WXrat9xWw70Fr2EF0005SP00008e@kXhgv0ZGZKSULGSPXKTPJHSRo4USpLO
Origin: https://login.oracle.com
Referer: https://login.oracle.com/mysso/signon.jsp
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="102", "Google Chrome";v="102"
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Cache-Control: max-age=0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
X-Forwarded-For: xxx.xx.xxx.xxx
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
Content-Length: 2411
v=v1.4&request_id=-xxxxxxxxxxxxxxxxxx&xxxxxx_REQ=.............
.............................
&locale=&ssousername=firstname.lastname%40domain.com&password=X
The actual password (X) which was confirmed with the user to be accurate.
The Network Prevent for Web server will see whatever the proxy sends to it unencrypted.
The proxy is required to send decrypt HTTPS traffic before it sends it to the DLP Network Prevent for Web (NPW) server for content inspection as per design.
Encrypted traffic would not inspected as DLP has no way to decrypt it.
Enabling finest logging levels for the purpose of troubleshooting technical issues may be required from time to time if Support are to assist with troubleshooting and resolving issues.
The DLP application cannot obfuscate such passwords in logs that the proxy would send across unencrypted.
If there are passwords that should not be sent and visible in logs on the NPWs then it would be best to create a filtering rule on the proxy to avoid sending that particular login traffic (or any Single-Sign-On) traffic to eliminate any such risk.
DLP logging in Finest level should also be reverted back to the default Info level after all troubleshooting where it is no longer required.