Security Considerations while designing Web Applications
In Interview Camp’s Live Session, we discussed Security Considerations while designing web applications. This can be asked as a follow up question after you have proposed a System Design in an interview.
Here are a few things to consider and mention in an interview:
Data In Transit: You should use HTTPS, which encrypts the data between the server and user. This ensures that no one can snoop on your connection and capture your requests (Man in the Middle Attacks).
Load Balancer: A load balancer serves as the public face of your backend. With a load balancer, no one has access to your internal application servers.
Verify Requests on Server: Validate all requests on the server, regardless of if your UI validates it. Anyone can send malformed requests such as form input, url requests, etc.
- Add Two Factor Authentication
- Limit number of Failed Login Attempts. Lock the account for some time after failed logins.
- Add CAPTCHA to ensure the user is not a bot.
- Set a Session Timeout for important applications such as online banking. If the session times out, the user has to login again.
- Re-verify Login Credentials before performing critical operations like transferring money, making payment, etc.
Prevent Denial of Service Attacks (DoS): One way of doing this is by using Rate Limiting on your backend. For example, limit the number of requests from each IP address to 10 requests per second. This can be done using a distributed cache, where you store the number of requests seen for each IP address in the last second.
This technique works if the attacks are from a small set of IP addresses. If the number of IP addresses is large (Distributed Denial-of-service or DDoS), you have to deploy more advanced techniques such has profiling your traffic and identifying legitimate visitors.
Prevent SQL Injection: This xkcd strip illustrates SQL injection well: 1
To prevent such attacks, always treat your inputs and SQL syntax as separate – don’t just do blanket concatenations. For example, don’t do the following:
"SELECT * FROM Users WHERE Username=" + user_name + ";"
Here, user_name could be anything, maybe even a SQL command.
Encrypt data stored in 3rd Party Databases: You can encrypt data that is stored on AWS or Azure to prevent access if those services get compromised.
Hash Passwords: Don’t store passwords in plain text. Hash them using an advanced hashing algorithm.
Hash it many times (for e.g, 10,000 times). This makes it harder to crack passwords using brute force. The hacker will have to perform more work to find if a password is valid.
Also, add a Salt to the hash. A salt is a unique string (like a UUID) that you add to the password before hashing it. This ensures that your hash is unique. Without a salt, different websites that use the same hashing algorithm will have same hashes. Hackers can utilize that.
Encrypt Personal Messages: Messages and other sensitive information should be encrypted before storing.