DirectAdmin v1.670

fln said:
A full release change log is here:

DirectAdmin 1.670​

The update should be automatically available for all installations subscribed to the current release channel.
Click to expand...


Hello,

Thank you for your hard work. Not going to complain, but still don't want to keep a silence. Users will for sure find the things broken. So I'm curious how do you comment the idea of removing a user password from a session file /usr/local/directadmin/data/sessions/da_sess_*? What made you to do it? We have developed a number of plugins for DirectAdmin (and I believe so did the other developers) where we rely on a password stored in the user session file. We use the password to do API calls to Directadmin. So what is behind the scene? What is the logic?
 
Storing a plain-text password in the session file was a big legacy security hole. We are really happy that we finally managed to restructure DirectAdmin to the point where we can eliminate it. It completely defeats the purpose of storing encrypted passwords and allows system admins, rogue plugins, or any other high-privilege process to just collect user passwords in plain text. Since some of the end users re-use the same password for different services, this makes them extremely vulnerable. There is absolutely no justification for bringing this anti-feature back.

Unfortunately, some integrations might have abused this anti-feature for easy access. But this is also an opportunity to upgrade them and make them more secure. Any plugin that already has access to the session hash does not need to know the user password to make API calls. The plugins can use the session hash to make requests with session-based authentication. In the same way as a user browser makes requests without a user password after the user has successfully logged in.

Historically, plugins using session-based authentication had to fight against the referrer checks. So DA has multiple mechanisms to bypass it (passing the key from the session file as a cookie or adding the X-DirectAdmin-Session-ID header). However, we are working on improving the referrer checks to the point where all these extra hoops will no longer be necessary.
 
LawsHosting said:
If someone has an EOL OS, why doesn't DA alert them of the fact - it used to when CB was its own entity IIRC..... #justanidea
Click to expand...
(y) We already expose the EOL flag in the DA version API endpoint. In next DA version it will be visible on the GUI as well.
 
fln said:
Any plugin that already has access to the session hash does not need to know the user password to make API calls. The plugins can use the session hash to make requests with session-based authentication. In the same way as a user browser makes requests without a user password after the user has successfully logged in.
Click to expand...

Thank you.

It is true for widgets only, correct? Server side's plugins can not authenticate without a password, can they?
 
The same mechanism can be used in server-side plugin widgets and in server-side plugin pages. The session ID is exposed via the environment variables. Without it, it would not be possible to read session files. The plugin scripts that used to lookup the user password in the session file should use the session ID in the request instead of using it to find the file.
 
A new hot-fix release is pushed out. It fixes two issues reported in the ticketing system:
  • A bug in File Manager compress and download dialog not showing up.
  • On older systems loading plugins fails when tickets.conf file does not have a html=... line, newer systems had this line present in the config file.
 
You must log in or register to reply here.
Back
Top