the patch looks good. this is exactly what is needed. I applied this to my setup and have scanned for compliance. It has now passed. I look forward to this being part of the main distribution.

actually, the autocomplete needs to be disabled for the username field as well as the password field. Please use this patch which adds the autocomplete=off to the username field as well. Both these fields need to be disabled to comply with penetration tests uses for compliance.

The security concern in this context is to prevent foreign users to authenticate and logon to an application, when having direct access to the computer/browser of a legitimate user and not to prevent revealing the user name.
There is no serious need to extend the autocomplete prevention to the user name from a security point of view, since the user name should actually be obvious in most cases.

So, to comply with the Payment Card Industry Data Security Standard it's enough to disable autocomplete for password fields, that's all what I had to care about

Is this still doable in Zabbix 4.x? I looked through 

include/views/general.login.php

But there doesn't appear to be a similar line.

Implemented in development branch feature/ZBXNEXT-2480-4.0 and feature/ZBXNEXT-2480-5.0.

Documentation updated:

• What's new in 4.0.27
• What's new in 5.0.6
• What's new in 5.2.2

Implemented in:

• 4.0.27rc1 d056d924cbd, a9b74cb7087
• 5.0.6rc1 9e436b23f8c, 9aa843047ef
• 5.2.2rc1 0f783c5028d
• 5.4.0alpha1 (master) a58dcb15cd

It doesn't appear this patch was merged into the 6.4.1rc1 branch. Is this something that can be done? Our scanners are detecting the following: 

dpcahill can you supply form page name or better URL where scanner detects this error?

@gcalenko 
Sure thing, nessus plugin outputted the following:
Page : /
Destination Page: /index.php

I'm assuming it's the login password field.

dpcahill our security team uses Nessus Professional 10.5.2 and do not detect such error, can you share with more information?

Here is the full Nessus plugin details. We are scanning against 6.4.1rc1

Plugin Details

PLUGIN ID: 42057
FAMILY: Web Servers
PLUGIN NAME: Web Server Allows Password Auto-Completion

Description

The remote web server contains at least one HTML form field that has an input of type 'password' where 'autocomplete' is not set to 'off'.
While this does not represent a risk to this web server per se, it does mean that users who use the affected forms may have their credentials saved in their browsers, which could in turn lead to a loss of confidentiality if any of them use a shared host or if their machine is compromised at some point.

Solution

Add the attribute 'autocomplete=off' to these fields to prevent browsers from caching credentials.
CVSS V2 SEVERITY: Low
PLUGIN PUBLISH DATE: Oct 7, 2009
PLUGIN LAST MODIFICATION DATE: Jul 17, 2023
SOURCE FILE: www_autocomplete_passwords.nasl
VERSION: 1.11

For reference, the issue is right here:

File to update likely appears to be this one:

include/classes/html/CPassBox.php:              $this->setAttribute('autocomplete', 'new-password');

@gcalenko 
Any other questions or updates on this one? Will the update be merged into the 6.x branches?

autocomplete value just needs to be set from ‘new-password’ to ‘off’. 

The goal of changes made in this development was to prevent browsers to auto fill stored passwords, setting autocomplete attribute to "off" will enable auto fill again because modern browsers ignore "off".

I think this is a bit more nuanced than that. Chrome appears to ignore only when no other autocomplete values are present in the form. This behavior seems to vary from browser to browser and would also depend on the configuration or organization settings of said browsers. 

For us since we are under strict compliance standards our browsers do obey this. In the meantime, in order to meet compliance, we had to manually edit this file (which will be overwritten next update).

I'm really not sure what the solution is here but would appreciate any input or consideration.

Recommendation here in my mind would still be to abide by the HTML autocomplete specification as that should effect the most browsers overall: HTML Standard (whatwg.org)

With a potential workaround for edge cases to also set autocomplete for the username field to off to see if more browsers would respect it then? I'll do some html testing across stock browsers and report back findings for the major ones.

Regardless appreciate your update here.

dpcahill thank you for additional information.

I don't have permission to view DEV-2624 unfortunately.

But I did run a check on the main three top browsers and have the following findings:

Browser	Autocomplete State	Browser Result (Default)
Microsoft Edge	on	Negative (autocomplete defaults to off but can be changed in preferences to use html setting.)
Microsoft Edge	off	Respects Setting
Google Chrome	on	Respects Setting
Google Chrome	off	Respects Setting
Firefox	on	Respects Setting
Firefox	off	Respects Setting

I set autocomplete to off at the form level itself, not individual fields. But it does appear to work in all three major browsers.

I used the following code to test against:

Off Test
========
<form action="/action_page.php" autocomplete="off">
   <label for="fname">First name:</label>
   <input type="text" id="fname" name="fname"><br><br>
   <label for="lname">Last name:</label>
   <input type="text" id="lname" name="lname"><br><br>
   <label for="email">Email:</label>
   <input type="email" id="email" name="email" autocomplete="off"><br><br>
   <input type="submit">
</form>

On Test
=======
<form action="/action_page.php" autocomplete="on">
  <label for="fname">First name:</label>
  <input type="text" id="fname" name="fname"><br><br>
  <label for="lname">Last name:</label>
  <input type="text" id="lname" name="lname"><br><br>
  <label for="email">Email:</label>
  <input type="email" id="email" name="email" autocomplete="off"><br><br>
  <input type="submit">
</form>

W3 Schools lists the following compatibility:

dpcahill thank you for detailed investigation. Change add autocomplete="off" to form element itself.
Setting "off" on form element itself is enough to prevent security scanner from reporting such form as having autocomplete enabled, right?

gcalenko yes that is correct. Sorry for the delay. Can we get this on the roadmap for a patch in the 6.4+ branches?

To clarify, the fix is the following:

In include/classes/html/CPassBox.php

replace

$this->setAttribute('autocomplete', 'new-password');

to

$this->setAttribute('autocomplete', 'off');

Question is, will it be enough to set autocomplete="off" on login form itself only and do not alter CPassBox.php at all?

Hey again Greg, I'm not sure how to answer your question. But we haven't notices any ill effects from this change outside of the system no longer being flagged in our scanner. Will this be merged in some way soon into the main codebase?

gcalenko Just checking in again, to answer your question:
Question is, will it be enough to set autocomplete="off" on login form itself only and do not alter CPassBox.php at all?
Provided the HTML returned for that field had the autocomplete="off" attribute, we should be golden.
Is it possible to merge this into the next update? Thanks!

dpcahill thank you for reply, login form password field will have attribute autocomplete "off". Changes will be available in nearest future, at the moment changes are in "review" phase.