When talking about web security, we subconsciously tend to focus on the back-end. I bet that one of the first things that comes to people’s minds when they hear the notion of web security are hackers trying to break into a server. While back-end security usually receives more attention, front-end security is definitely not to be neglected.

This is not to say you should not focus on fortifying your server. Quite the contrary. You should be familiar with server security measures like firewalls (responsible for blocking/allowing access to different ports), SSL/TLS encryption (authenticating and encrypting communication), or SSH keys (a cryptographic alternative to password-based logins).

There are more steps you can take to improve your server security.

One of them is service auditing. It is nothing else than analyzing your systems and configurations and looking for vulnerabilities. It is a good idea to delegate the audit to an expert that was not involved in the setup process.

What you can do by yourself, though, is file auditing. It is checking the current system files every certain period of time and comparing them against each other to see if there were some undesired changes. To avoid doing it manually, get yourself an IDS – Intrusion Detection System. Such a piece of software will use file auditing as a method of server activity monitoring.

It is also good to isolate execution environments if your infrastructure allows that. This means running individual elements of your application in separate space, whether it is a container or another server.

In some instances, you may want to leverage a VPN (Virtual Private Network) which allows remote computers to connect to the network as if they were local. This allows you to set up your services on a local network and communicate with other servers via a secure connection. This eliminates the possibility of being attacked from outside of the network.

That pretty much covers the basic server security. But even if you take care of the things listed above, you still can become a victim of an attack. An attack performed from the outside, without even breaking in. Why? Because of poor front-end security.

What Front-end Security Actually Is?

First, let’s take a look at this tweet.

<script class=”xss”>$(‘.xss’).parents().eq(1).find(‘a’).eq(1).click();$(‘[data-action=retweet]’).click();alert(‘XSS in Tweetdeck’)</script>♥

— *andy (@derGeruhn) June 11, 2014

Quite a lot of retweets for a seemingly meaningless piece of code. The secret of these retweets lies in Tweetdeck’s (Twitter’s dashboard for managing multiple accounts) XSS vulnerability that let this piece of code become an executable script. In result, it turned out to be a self-retweeting tweet. Let this video explain it to you.

The XSS – or Cross-Site Scripting – vulnerability is one of the common issues in front-end security. It shows how one missed detail can lead to costly exploits.

Tweetdeck had to bring down their service for a while to fix the issue. Even though this attack was not malicious (but very well could have been), every minute of downtime for a service means a loss in revenue. Had “Andy” put a malicious link in his self-retweeting tweet, Tweetdeck would have been in a major crisis.

Tweetdeck’s case shows how important it is to pay attention to frontend security, especially if you are running a commercial website or application. By the way, do you know what the top web development trends this year are?

Common Front-end Vulnerabilities

Let’s run down the most common web security issues related to the front-end.

• SQL INJECTIONS

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.

• CLIENT XSS

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).

XSS vulnerabilities can be avoided by using frameworks and services with built-in protection. It is also advised to avoid the eval () parameter in Javascript, that opens the doors to many attack possibilities.

• 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.

• iFRAME VULNERABILITIES

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
• Misplaced-trust
• Processing rogue COR

For ways of protecting against CORS vulnerabilities, it is best to refer to Google’s comprehensive guide.

• COOKIE VULNERABILITIES

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.

To stay secure with cookies, you should remember to limit the amount of sensitive information in the cookie to a minimum. Additionally, you should encrypt the cookies with SSL and make them HTTP-only, so they are not accessible for Javascript.

• 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.

Careful development.

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.

Strict authentication.

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.

Encrypt your entire site with TLS. Make cookies HTTP-Only. Use X-Frame-Options. Use cookies or tokens to protect against CSRF. Validate and encode user input.

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.