Knowledgebase
I think I've found an XSS or CSRF hole in DirectAdmin!
We get these reports on occasion, but DirectAdmin has had a referrer checking tool for quite some time now:
http://www.directadmin.com/features.php?id=1050
Since this was added, none of the external XSS/CSRF reports have been valid.
People who think they've found one often are testing with a form in the DA skin, on port 2222 on the same IP.
This means the form is in the skin, which is exactly where it lives usually for it's intended purpose. So of course, the form submission passes, as one would expect. So this test is only possible if they've got access to editing the skins, which means they've already got root access on your server, so the XSS test doesn't mean anything.
An external form, using any different variable, either IP or port will fail the check_referer=1 test.
In DA debug mode, a sample might look like this, where 1.2.3.4 is the server IP, and we actually put the hacking test on the same IP. In real life, the attacking IP would typically be on a different IP, but that only adds one more thing for the referer check to find. This just proves that even just the variance in the port is sufficient to stop the attack.
This test has http://1.2.3.4/hack.html with any standard form you want, DA on http://1.2.3.4:2222, with the client IP being 5.6.7.8:
So please before submitting your security report, please check to ensure that you're not actually testing your form in 2222, that's where it's going to be valid. Test with your form on any different port or IP.
http://www.directadmin.com/features.php?id=1050
Since this was added, none of the external XSS/CSRF reports have been valid.
People who think they've found one often are testing with a form in the DA skin, on port 2222 on the same IP.
This means the form is in the skin, which is exactly where it lives usually for it's intended purpose. So of course, the form submission passes, as one would expect. So this test is only possible if they've got access to editing the skins, which means they've already got root access on your server, so the XSS test doesn't mean anything.
An external form, using any different variable, either IP or port will fail the check_referer=1 test.
In DA debug mode, a sample might look like this, where 1.2.3.4 is the server IP, and we actually put the hacking test on the same IP. In real life, the attacking IP would typically be on a different IP, but that only adds one more thing for the referer check to find. This just proves that even just the variance in the port is sufficient to stop the attack.
This test has http://1.2.3.4/hack.html with any standard form you want, DA on http://1.2.3.4:2222, with the client IP being 5.6.7.8:
Checking referer http://1.2.3.4/hack.html to 1.2.3.4:2222
Referer check failed for 5.6.7.8. See error.log
2016:03:31-15:49:00: Referer port (80) does not match DA's (2222): http://1.2.3.4/hack.html
2016:03:31-15:49:00: Referer check failed for 5.6.7.8
So please before submitting your security report, please check to ensure that you're not actually testing your form in 2222, that's where it's going to be valid. Test with your form on any different port or IP.