In recent times, modern web applications are growing at a rapid pace. Responsibility for a strong and safer application should be shared between the backend as well as the frontend. Most of the security practices were being utilized in the backend side of the code but now it's becoming equally crucial to use the best security practices that will protect the frontend side of the code because of the increased cyber attacks, after all, frontend is the main window to the whole application. So, it is better to make your application safe on the entrance as well.
In this article, we’ll go through some of the common attacks that take place and the best practices that can be used to safeguard your applications from them.
Cross-Site Scripting (XSS) Attack
Cross-Site Scripting (XSS) is a form of attack whereby an attacker injects malicious scripts into a trusted website. The attacker then proceeds to send you malicious codes that look like the side script of your browser.
When other users access the web application, since the browser does not know that it is malicious as it was served by the backend, this malicious script is executed.
a) An attacker with a malicious script accesses the application.
b) He fills up a form and inputs a malicious script in the form field.
c) The malicious script reaches back-end systems via a form field data and is saved in the database.
d) When some legitimate user accesses the application, he is served with the malicious script by the application’s backend. The browser doesn’t know it is a malicious script and executes it.
The malicious scripts sent are configured to access your sensitive data, session tokens, cookies, browser history, and more.
Prevention
Filter input on arrival- When the input is received, filter data based on what is expected or valid input.
Encode data on output- When user-controllable data is provided in HTTP responses, encode the output to prevent it from being executed by HTML parser. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
Use appropriate response headers- To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, we can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend. Eg. A JSON data should never be encoded as text/html, to prevent it from accidental execution.
DDOS Attack
A Distributed Denial-of-Service (DDoS) attack is the process of overwhelming a website with too much traffic to a point where it crashes. Due to the high volume of DDoS attacks, the attacker manipulates hundreds or thousands of systems to generate the high traffic targeted at your web application to wear it out.
Prevention
Using Captcha at public-facing endpoints (login, registration, contact) — a captcha is a computer program or system intended to distinguish humans from bots.
Most of the DOS attacks are carried out using bots. Captcha identifies bots and prevents them from making requests.
Google’s reCaptcha is a highly advanced service to protect bots from abusing your applications.
Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) involves an attacker luring you into taking harmful action on a website that has been authenticated with your login credentials. This kind of attack is mostly executed with download forms.
It can be tiring to always enter your login credentials into websites that you visit frequently. You might choose to make it easier by saving your login information on the website. Although this is a common practice, it can be a problem.
An attacker could send you a download link from a website that you have saved your credentials on. If you download the file, you unknowingly perform a malicious transaction.
Prevention
For every session of a user, the server should generate a randomized token (CSRF Token) and send it to the client. The client can save the token, from where javascript can read it.
When a web application is making an HTTP request, the application should include that randomized token (CSRF Token) in the header of each request.
The value of this token should be randomly generated such that it cannot be guessed by an attacker. We should use a well-known hashing algorithm such as SHA256/512 for generating tokens.
Using third-party libraries
Implementing third-party libraries to enhance the performance of your system is necessary. The more third-party software, the more functions you can execute on your web application as each one serves a unique purpose. But sometimes, these libraries might have loopholes that could expose your system to cyberattacks.
For instance, if you offer a service that requires your clients to make online payments. Instead of creating your own billing software, you might choose to implement a third-party billing software that will get the job done. If the billing system isn’t well secured and suffers a security breach, your clients' payment information will be exposed and their money can be stolen.
Prevention
One sure way to prevent third-party library attacks is to scan all the third-party libraries that you use. Doing this manually can be complex and time-consuming, especially if you are dealing with a large web application. But you can automate the process by using vulnerability scanners to detect existing threats.
One of the most crucial practice that every developer should know about and should often use is Content Security Policy (CSP).
The main issue that comes up in XSS is the browser’s inability to distinguish between script intended to be part of your own application. A website can have multiple scripts from different sources, being used. The browser will happily download and execute any script that it comes across.
Instead of blindly trusting everything that a server delivers, CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject script, the script won’t match the whitelist, and therefore won’t be executed.
A very important point to note here is that CSP provides prevention against scripts based on origins and hence it would not prevent any inline scripts from execution. Origin based whitelisting doesn’t solve the biggest threat to XSS attacks using inline script injection.
CSP solves this problem by banning any inline scripts entirely. Hence we will have to move any inline js within the script tags to external script files. External scripts are already considered as the best practice. They are easier for browsers to cache, better for developers, better for minification.
Cyber attacks have only grown through the period of time. Attackers seize even the slightest of the opportunity they get. So, it’s better to be more secure from your end. Protecting the application from the backend only won’t solve the issue. Frontend too, should be given a priority and should not be overlooked.
Top comments (0)