Web application security: Difference between revisions
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Definitions == | |||
Know the difference between: | |||
* Encryption / Decryption | |||
* Encoding / Decoding | |||
* Hashing | |||
* Message authentication | |||
There are some overlaps and sometimes the terms are used interchangeably, but ultimately they are different tools for different use cases (e.g. don't use a hash if you need to retrieve the original input). | |||
== TLS == | |||
Use TLS (yes TLS, not SSL), at least v1.2. Every inbound and outbound (to APIs, databases etc.) request should go over a secure connection (you can get away without TLS for your database connections if you are using the same host and a dedicated server, but this is still not ideal). | |||
HSTS improves things somewhat, as it forces browsers to use HTTPS on everything except the first connection. However, if you get this wrong, you can accidentally break your site. | |||
== Peppers == | |||
Like salts, but global to the application (and only known to the application, not the database). Don't bother with these, because: | |||
* They provide limited extra 'security' | |||
* You can't easily rotate the pepper as it is effectively embedded in password hashes etc. | |||
If your passwords are salted, a pepper adds very little and causes extra maintenance and the problem of rotating keys. Also, on the vast majority of web applications - especially small ones - the application and database are on the same server anyway. | |||
== Articles == | == Articles == | ||
* [https://github.com/blog/1466-yummy-cookies-across-domains Yummy cookies across domains] | * [https://github.com/blog/1466-yummy-cookies-across-domains Yummy cookies across domains] | ||
* [https://martinfowler.com/articles/web-security-basics.html The Basics of Web Application Security] | * [https://martinfowler.com/articles/web-security-basics.html The Basics of Web Application Security] | ||
* [https://portswigger.net/research/web-storage-the-lesser-evil-for-session-tokens Web Storage: the lesser evil for session tokens] | |||
* [https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html HTTP cookies, or how not to design protocols] | |||
* [https://blog.ircmaxell.com/2014/11/its-all-about-time.html It's all about time] | |||
Latest revision as of 16:00, 8 April 2023
Definitions
Know the difference between:
- Encryption / Decryption
- Encoding / Decoding
- Hashing
- Message authentication
There are some overlaps and sometimes the terms are used interchangeably, but ultimately they are different tools for different use cases (e.g. don't use a hash if you need to retrieve the original input).
TLS
Use TLS (yes TLS, not SSL), at least v1.2. Every inbound and outbound (to APIs, databases etc.) request should go over a secure connection (you can get away without TLS for your database connections if you are using the same host and a dedicated server, but this is still not ideal).
HSTS improves things somewhat, as it forces browsers to use HTTPS on everything except the first connection. However, if you get this wrong, you can accidentally break your site.
Peppers
Like salts, but global to the application (and only known to the application, not the database). Don't bother with these, because:
- They provide limited extra 'security'
- You can't easily rotate the pepper as it is effectively embedded in password hashes etc.
If your passwords are salted, a pepper adds very little and causes extra maintenance and the problem of rotating keys. Also, on the vast majority of web applications - especially small ones - the application and database are on the same server anyway.