Web Security Summary

Sorry, but boiling.
Many cones are already full on the topic of site security. Young specialists who graduate from universities, even though they know how to program, but on the issue of site security they step on the same rake.

This synopsis is a memo on how to achieve relatively high security of applications on the web, as well as to warn beginners from banal errors. The list was compiled without regard to the programming language, so it is suitable for everyone. And now let me, I will induce KO a little.


So what should be a secure site?

1. About the server

1. FTP is not a secure protocol, it transmits information in an encrypted form, so you should choose either FTPS or SFTP. Now on SSH, authorization by keys, ─ we use denyhost or its analogue, you can change the default port.
   

   Everything that is brutal needs to be closed. If you have your own server and at least once looked at the logs, you probably noticed numerous authorization attempts via SSH and FTP coming from Chinese IPs.

2. Outside, only really necessary ports should be watched, the rest is closed with a firewall.
3. We always use the latest software versions, updated on time.
   

   Recent history with OpenSSL confirms this

   
   
4. Be sure to configure the logs and monitor any suspicious activity.
5. There should not be any left folders and files a la .svn, .git, .idea, dump.tar.gz in the root of the project.
   

   There were cases when archives with the database and file were left openly available on client sites. The same thing with backups.

6. We set the minimum permissions for files, no 777.
7. Dynamics, if possible, is best taken out of the root.
8. Statics (js, css, image) should lie separately, ideally ─ on another server.
9. If we work with important data, we use https / ssl with a short expiration.
10. Error messages are not displayed on the screen ─ only prompts to the user.
11. Backups must be done and stored on another server.

2. About the input

1. In controllers:
   
   • Always filter input parameters
   • We use the minimum allowed value. For example, if we get a number, then we reduce to a number. You can validate on the client, and it is mandatory on the server.
   • Do not forget to check the variables for boundary values.
   • If the data is from the list, then be sure to match the set of valid values.
   • If possible, check the MIME type for files, do not trust extensions, this is easy to change.
   • We do not allow infinitely adding any data (for example, comments).
   • We do not allow loading long lines and heavy files.
   
   
2. In the model:
   
   • For SQL queries, use prepared statements.
   • We optimize database queries - no select in the loop.
   • Do not forget about indexes.
   • Sophisticated search? Use search engines (ElasticSearch, Sphinx, etc.).
   
   
3. In view:
   
   • We bring the data into the necessary entities. Check for xss, no html tags or js scripts from the client.
   • In submitting a form or state changes, we use unique tokens (csrf) for each user. Do not want tokens, then check HTTP_REFERER.
   • If you use AJAX, do not forget to check the data both at the input and at the output. In 99% of cases, eval in JS is evil.
   
   

3. About customer

As Dr. House said, the patient always lies.
Most customers don't give a damn about their safety.

1. Validation on the client - only for its convenience, be sure to recheck on the server.
2. POST is as easy to fake as GET.
3. If there is a form in the public domain without captcha, spammers will definitely start writing into it.
4. Complicate authorization, several unsuccessful login attempts - let them enter captcha.
5. Want to complicate things? We fasten two-factor authentication.
6. For confirmations, we use a one-time long token, tied to a specific user.
7. We force the client to make complex passwords.

4. About encryption

1. We do not store anything in the clear.
2. Passwords - in the form of hashes with salt, it is advisable to check for cryptographic strength and conflicts.
3. from ValdikSS Do not use either MD5 or SHA1. It is best for passwords to use specialized hash functions such as PBKDF2 or scrypt.
4. No data on the client, even in encrypted form, only id sessions in cookies.

The list turned out to be rather chaotic. This is what a student’s website security brief should look like. Surely missed something, something can be added. Write in the comments what else you can add and we will compile a general checklist of a truly secure site.