pci compliance issue

D

DenRomano

Verified User
Joined
Jan 30, 2011
Messages
28
Location
Vegas and So California
The scan service we use reported the following

Description: HTML page uses cleartext form-based authentication (/)
www.domain-name.com xxx.xxx.xxx.xxx Feb 23 17:31:02 2011newS everity: Potential
Problem 2.62736new11Impact: Poor authentication practices may leave the web
application vulnerable to authentication attacks. Background: Some web applications
perform authentication by requiring a user to enter a login and password into an
HTML form. This type of authentication is achieved using the HTML INPUT element with
the type attribute set to password. Resolution To use HTML form-based authentication
more securely in web applications , do the following: Remove the value attribute from
the INPUT tag corresponding to the password field. Submit all forms to an SSL enabled
(https ) service using the form's action attribute. Place all protected web
directories on an SSL-enabled (https ) service. Use the autocomplete="off" attribute in
the INPUT tag corresponding to the password field. Vulnerability Details: Service:
2222:TCP Received: <input type=password name=password></td></tr>
 
I believe I've found his problem: to get PCI compliance on a DirectAdmin server, user DenRomano, and in fact all of us, should be using a Secure Cert and secure access to DirectAdmin. From my own experience I can tell you that my own PCI compliance checker tells me if it's private Certificate and recommends a commercial Certificate.

Jeff
 
Sorry zEitEr I should have explained better.

The problem is not only that if we do not bring up the browser under a SSL connection that the username and password are transmitted in plain text that anyone with a network sniffer can see but what I think the main issue the PCI scan is finding is the way the DirectAdmin programmers created the form to which we enter their CP. As you can see by my first post they found this line in there code

<input type=password name=password>

and the complaint would be that they did not use parameters

autocomplete="off"

in the input tag. Now they found this by triggering port 2222 and only concider this a LOW issue and my server did pass but I was wondering if someone should not force a redirect from none SSL to SSL request of this page?
 
Use Google to search these forums and also to search http://help.directadmin.com and you'll find how to set your server to force a redirect from non-SSL to SSL.

The reason DirectAdmin doesn't do that by default is many of us want to offer both secure and insecure access; to use secure for ourselves, and insecure for users and/or resellers.

The main issues to consider is the cost of the Certificate and the possible need for a generic domain name, since your resellers won't want their customers to visit your domain name to log in.

I guess I don't understand the autocomplete="off" paramater with the password field. I've never seen a password try to autocomplete. I'm not really an html programmer. What am I missing?

Jeff
 
I followed the instrutions from the help file that jlasman (thanks by the way) pointed me to. I changed SSL to 1 and added

ssl_redirect_host=secure.wadeindustries.com

but it does not work, it does not redirect. Do I need to restart something?

I see in service monitoring a "direct admin" do I need to restart that?
 
Yes you have to restart directadmin after changing anything in directadmin.conf
 
You must log in or register to reply here.
Back
Top