Let’s run down the most common web security issues related to the front-end.
SQL injections occur when attackers use application code to access a database. This could be done by putting a string of code in an input field on an attacked website. Well, it can even be a line of code inserted into the URL, if there’s such vulnerability.
Rather than data, the database will recognize this input as a query, allowing the attackers to access the backend and modify the data in the database or even delete it altogether.
SQL injections can be avoided by implementing parameterized database queries.
This should already be familiar thanks to the Tweetdeck’s case described earlier. XSS vulnerabilities happen when dynamic data is sent without being filtered against malicious content. In Tweetdeck’s case, the dynamic data was the tweet, while the script inside it was the malicious content.
These vulnerabilities are most often a result of sloppiness (like forgetting to limit input fields functionalities).
- CROSS-SITE REQUEST FORGERY (CSRF)
This is a pretty advanced technique of attack, as it requires good timing and knowledge. There are many ways a CSRF can be performed, but to keep it simple, it is about tricking a regular user of a service into performing an undesired actionwithout their knowledge.
In CSRF, the attacker can not even directly see if they succeeded, as they rely on the actions taken by the attacked user within the user’s browser. It is best to learn about Cross-Site Request Forgery on an example.
Imagine a simple online banking site. The victim is currently logged in to their account (so the session is authenticated). In the same time, the victim receives a link from the attacker. The link contains a script that tells the bank to send money to the attacker (it is a major simplification, but let’s say it contains the account number and the amount to be transferred). When clicked, the banking site performs the action and voila, the attack is successful, and the victim can only see a message about a successful money transfer.
CSRF can be used for various kinds of attacks. How to avoid them? There are a few solutions. One of them might be tokens generated for each session, so the service can check if they match with each request. This can, however, be still hacked using XSS. So a better solution may be to generate tokens for each page separately, but this still has some flaws (for example eliminates the possibility to go back a page). What may work best for you, are the so-called Double Submit Cookies. In this case, the service authenticates each request based on the values set in cookies sent to users.
iFrames are used for embedding an HTML document in another HTML document, which in practice can mean placing ads on a website. iFrames can also be used to embed a button from a popular social page (like a Tweet button) on another site. Either way, iFrames can bring security vulnerabilities.
To make sure the iFrame content on your website is secure, it is advised to add the sandbox attribute in the code, which enforces plenty of restriction on the iFrame content, so that scripts can not be executed.
If you want to make sure your content is not used for malicious iFrames (clickjacking), learn more about X-Frame Options.
- CROSS-ORIGIN RESOURCE SHARING (CORS)
CORS allows for sharing resources across your subdomains, but it can be a vulnerability if used improperly, allowing anyone to request to your server and even receive a response with sensitive information. It can be used to attack both a user and a server.
According to Google, the most common problems with Cross-Origin Resource Sharing include:
- Universal Allow
- Site-level Cross-Origin Access
- Access-control decision based on Origin header
- Prolonged caching of Preflight responses
- Processing rogue COR
For ways of protecting against CORS vulnerabilities, it is best to refer to Google’s comprehensive guide.
Libraries like jQuery Cookie allow for setting cookies without accessing a server. What is more, cookies are not encrypted by default and can be vulnerable to XSS and CORS exploits.
- INSECURE DIRECT OBJECT REFERENCES
This is a part of web security 101. Sometimes getting access to data or files is as simple as figuring out the scheme of the URL and constructing a new one that leads directly to the data.
That is why you should never directly give away database keys. Instead, use indirect, simplified references. For example, if you have five selectables on your page, do not put their real IDs in the URL, but replace them with numbers from 1 to 5.
This can also be fixbyith authenticating each attempt to access data.
- AUTHENTICATION AND SESSION MANAGEMENT VULNERABILITIES
These are quite self-explanatory. Attackers can hijack sessions or identities because of poor credential authentication and/or session ID protection.
That’s why you should always require your users to set strong passwords, limit the number of failed logins, use encryption for password storing, use double authentication for password changing, and encrypt the connection with SSL/TLS.
- VARIOUS SECURITY MISCONFIGURATIONS
Sometimes the vulnerabilities can be sourced in as simple thing as configuration. What can be a misconfiguration? Default login and password still being enabled, unnecessary plugins and accounts, overly informative error messages, outdated software and any other settings that may make attacks easier.
Avoid misconfigurations by auditing, testing, and turning to minimalism – that is getting rid of anything that’s not necessary for your service.
Performing a Web Security Check
Web security ought to be treated with special care by any service out there. That’s why you should always double check every area of your infrastructure for potential mishaps. This means:
Securing the database.
Use encryption for any sensitive data. Make sure users have minimal needed privileges and get rid of unnecessary accounts. Use parameterized queries to avoid SQL injections.
Scan all the components of your software against vulnerabilities with every version you put on production. Build software in secure development systems. Let the QA team do their work.
Encrypt all passwords. Make sure that logging in and restoring password procedures are secure. Enforce strong passwords. Use multi-factor authentication if possible.
Protecting against DoS/DDoS attacks.
Implement rate limiter on API paths (also those related to authentication). Implement limits on the size of data submitted by users and the number of requests.
Protecting against known frontend vulnerabilities.
Securing your APIs.
Require full authentication when using your APIs. Detect abnormal requests with canary checks
Configuring your cloud servers properly.
Always stay true to the minimalism rule – don’t allow for anything that’s not necessary. Regularly change passwords.
Protecting the infrastructure.
Use centralized logging in for all services. Implement Intrusion Detection Systems (IDS). Keep unused servers turned off.
Test, test, test.
Try hacking yourself, make external experts run audits on your configurations, train your staff to beware of web security and testing.
Finally and most importantly – repeat.