Companies in the physical security world often seem to have awful virtual security.
This site – “Apprentices for Fire & Security” – is a prime example of absolutely awful virtual security. And once again, these are not subtle issues – they are indicative of incompetent developers working on the security aspects of a website. Stop entrusting your security to people who do not know what they are doing.
Let us go through the obvious issues:
No HTTPS anywhere
The site handles passwords, emails, addresses, names, CVs, job postings. This is confidential information.
None of this is protected by HTTPS. It is all sent in the plain.
This is not forgiveable in 2015. It is embarrassing that anyone can deploy a site handling logins and CVs without it.
Update: as of mid-morning 9/11, HTTPS has been turned on for apprentices4fs.com and some other domains. You have to ask, why was this not done in the first place?
Passwords are emailed to users
When you setup your account, you chose a password. This password is immediately emailed to you.
This means that your password has now been sent in the plain across the Internet.
This is not good practice for very obvious reasons.
Passwords are stored in the plain
When you fill in the password reminder, your original password is emailed to you. This means the passwords are not hashed.
This means that if the database was to leak, it would reveal all the passwords.
This is terrible practice and it is widely known that it is terrible practice.
Passwords are truncated
Enter a 100 character password, and send a password reminder. The plain text password is now only 20 characters long.
This is a side effect of plain text password storage. If you store the password in the plain, you have to limit the password length to something. If you hash the password, the password could be “War & Peace” and the hash would still be of a fixed length.
This is terrible practice.
Passwords are not case sensitive
If you set your password to AAAAAA, you can login to the system with aaaaaa.
Even if you are using plain text storage, you don’t need to do this.
This massively reduces the number of different passwords available.
This is terrible practice.
Detailed error logging is turned on
If an error occurs, you are given a detailed error log.
This leaks information such as the directory structure, what attack mitigation rules are in place and so on. Sometimes these error logs can even leak things like usernames and passwords.
They should be turned off on a production server. This is web admin 101.
Open redirect on login form
Often when you access a page that requires authentication, a site will pass a referrer (i.e. the page you were on) to to the login page. This is so you are seamlessly returned to the page you wanted to access, after logging in.
It’s absolutely vital that this referrer URL is not a free choice.
Why? Picture this attack.
The attacker sends this URL to the victim:
The victim logs in to the real site, and are redirected to the attacker’s fake login page. This fake page says that the victim has entered their password incorrectly.
The victim logs in again. His credentials are stored by the attacker, and he is returned to the genuine site.
This is a glaringly obvious issue and very serious.
No protection against cross-site request forgery
There is no evidence of any protection against cross-site request forgery (CSRF). This includes pages used to change passwords and other details.
Cross-site request forgery means I can send a crafted link to a user (e.g. by email), and if they click on the link, the action will be carried out as the user.
A very simple example would be something like:
And the logged in user would have their password changed to ABCDEF.
The actual mechanics are more complex than this. Regardless, you cannot deploy a public facing website dealing with logins or confidential information without CSRF protection.
Cookies don’t have HTTPOnly flag set.
Cookies are used to remember that you are logged into a site using something called a session token. If you get hold of someone else’s session token, you can act as if you were logged in as them.
Again, this is basic stuff.
An arsehole security warning
Do anything they don’t like, and you get this. (which has since been made 403).
There’s a strong correlation, in my experience, between OTT warnings like this and incompetence.
Overzealous XXS filters
There are a number of ways of doing this. You can detect basic attempts and warn a user that there is an issue, probably logging the issue and alerting admins. If there is persistent and realistic threat, start banning IPs.
Immediately locking the IP out and issuing them with a ridiculous warning it not how to do XSS protection.
This has since been hidden, but someone had kindly screenshotted it:
In my experience of looking at over 100 sites, the ones that react to XSS like this tend to have wholly ineffective XSS filters – they only deal with the very obvious, and can be subverted. It’s like putting up a “Warning – Guard Dogs” sign, without the guard dogs.
Totally ineffective banning
If you trigger the overzealous XSS filters, you are banned. Or so it says.
That is, unless you use another browser. Or just manually change the user agent.
I suspect they have done this because otherwise you could easily perform a denial-of-service attack by blocking from many IPs.
This banning is token at best, and provides no extra security.
No security contact
Well, no contact at all. What do you have to do to get these people to respond to a security issue?
The security of this site is about as bad as it can get without just leaving everything in the open. There has been little to no regard to the security of the data or users. This is to the level that it is either extreme incompetence or negligence.
What is more worrying is that the people who developed this sell it as a product.
And, of course, who is behind this particular site? CSL Dualcom.
99 other sites running software by the same company.
They have 99 problems, but their HTTPS configuration isn’t one, because they don’t use it.