Web Security Summary

Sorry, but boiling.
Many cones are already stuffed on the topic of site security. Young professionals who have graduated from universities, although they can program, but on the site’s security issue, they are attacking the same rake.

This summary is a reminder of how to achieve relatively high security of applications on the web, as well as warn newbies against trivial errors. The list was compiled without a programming language, therefore it is suitable for everyone. And now let me, I will stay a little KO.


So what should be a secure site?
')

1. About server

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

   All that is battered, you need to close. If you have your own server and at least once looked at the logs, you probably noticed numerous attempts to authorize via SSH and FTP, coming from Chinese IP.

2. In the outside should look only really necessary ports, the rest is closed with the firewall.
3. We use always up-to-date software versions, we are updated in time.
   

   Recent history with openssl proof

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

   There were cases when archives with a database and a file in open access were left on client sites. The same thing with backups.

6. Set the minimum permissions on the files, no 777.
7. If possible, it is better to move the dynamics beyond 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 made and saved on another server.

2. About input data

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

3. About client

As Dr. House said, the patient always lies.
Most customers do not care 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 open access without a captcha, spammers will surely start writing to it.
4. Complicate the authorization, several unsuccessful attempts to enter - let them enter the captcha.
5. Want to make it harder? 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 difficult passwords.

4. About encryption

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

The list turned out quite confused. Something like this should look like a small summary of the student on the security of the website. Surely something missed, something can be added. Write in the comments what else you can add and we will create a general checklist of a really safe site.