NaveenDA's Blog
Things you need to know about front-end security

Things you need to know about front-end security

Naveen's photo
Naveen
·

7 min read

Is Front End Security is a real thing? Hmm… the truth is yes, it is. Real Gif

Security is of paramount importance, no matter front end security or backend security. When I googled “Front End Security”, I could found the proper article, so I decided to write an article about “The Ultimate Guide To Front End Security”.

In this article, I will show some of the important concepts & best practice for improving your application front-end security.

XSS

Cross side script is one of the deadliest things when comes to security.

Why it so evil?

In every year OSWAP top 10 vulnerabilities list, definitely it in the list. It a client-side code injection, Imagine if you add a comment a blog post with some javascript, now you access every user's cookie who read your blog. Sometimes it called as Landmine.

Okay reading a cookie is a potential threat, but what are the things are XSS can do.

  • Ad-Jacking - If you manage to get stored XSS on a website, just inject your ads in it to make money ;)
  • Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.

  • Session Hijacking - HTTP cookies can be accessed by JavaScript if the HTTP ONLY flag is not present in the cookies.

  • Content Spoofing - JavaScript has full access to client-side code of a web app and hence you can use it show/modify desired content.

  • Credential Harvesting - The most fun part. You can use a fancy popup to harvest credentials. WiFi firmware has been updated, re-enter your credentials to authenticate.

  • Forced Downloads - So the victim isn’t downloading your malicious flash player from absolutely-safe.com? Don’t worry, you will have more luck trying to force a download from the trusted website your victim is visiting.

  • Crypto Mining - Yes, you can use the victim’s CPU to mine some bitcoin for you!

  • Bypassing CSRF protection - You can make POST requests with JavaScript, you can collect and submit a CSRF token with JavaScript, what else do you need?

  • Keylogging - You know what this is.

  • Recording Audio - It requires authorization from the user but you access victim’s microphone. Thanks to HTML5 and JavaScript.

  • Taking pictures - It requires authorization from the user but you access victim’s webcam. Thanks to HTML5 and JavaScript.

  • Geo-location - It requires authorization from the user but you access victim’s Geo-location. Thanks to HTML5 and JavaScript. Works better with devices with GPS.

  • Stealing HTML5 web storage data - HTML5 introduced a new feature, web storage. Now a website can store data in the browser for later use and of course, JavaScript can access that storage via window.localStorage() and window.webStorage() Browser & System

  • Fingerprinting - JavaScript makes it a piece of cake to find your browser name, version, installed plugins and their versions, your operating system, architecture, system time, language and screen resolution.

  • Network Scanning - Victim’s browser can be abused to scan ports and hosts with JavaScript.

  • Crashing Browsers - Yes! You can crash browser with flooding them with….stuff.

  • Stealing Information - Grab information from the webpage and send it to your server. Simple!

  • Redirecting - You can use javascript to redirect users to a webpage of your choice.

  • Tabnapping - Just a fancy version of redirection. For example, if no keyboard or mouse events have been received for more than a minute, it could mean that the user is AFK and you can sneakily replace the current webpage with a fake one.

  • Capturing Screenshots - Thanks to HTML5 again, now you can take a screenshot of a webpage. Blind XSS detection tools have been doing this before it was cool.

  • Perform Actions - You are controlling the browser,

Taken from security.stackexchange.com/a/206526

How to prevent it?

  1. You have to more carefully when comes to display user input.
  2. Use Front Framework like react, angular, etc. It designs that to rid the XSS

CSP

Content security policy is the security layer is used to detect and prevent various attack including XSS. Strong CSP can able to prevent much potential thread. You can easily enable by adding Content-Security-Policy header. Read more about CSP on MDN Docs

Referrer value

If the link is taken to a third party domain, that domain has access to your last URL. You might think, it is not potential thread, but that URL might contain sensitive data like session-id, API-key, etc.

To prevent this attack, set the Referrer-Policy header with no-referrer value.

"Referrer-Policy": "no-referrer"

Feature policy

Always restrict to access something, which is not needed in your web application. We can tell the browser to disable some of the browser's functionalities/features by adding Feature-Policy header.

"Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"

Integrating third-party scripts

You may notice while using the bootstrap CDN with an integrity attribute.

What the heck is that? Subresource Integrity(SRI) which is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation.

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.0/css/bootstrap.min.css" integrity="sha384-9aIt2nRpC12Uk9gS9baDl411NQApFmC26EwAOH8WgZl5MYYxFfc+NcPb1dKGj7Sk" crossorigin="anonymous">

Imagine you are including a third-party script in your application. What if they serve different content that attacks your application instead of actual content? The eventuality that is possible.

The good news is we can prevent using Subresource Integrity.

What if your third-party provider doesn't provide the SRI? Still, you can generate Integrity by using srihash.org

Dependencies

If you look into the node_modules, you see a lot of folders. And you might think is this needed? Yes, those are needed that's why they are in your project folder.

But the question is, how many dependencies have security vulnerabilities? We can easily find add run command npm audit

Every day a lot of vulnerability is exposed that might affect one your dependencies, We can monitor our dependence's vulnerabilities tool using various tools.

The tools like Dependabot and Snyk constantly monitor the vulnerabilities of Dependencies and create a pull request when the vulnerability fixed.

Iframe

An iframe is used full thing to display your application content to another application or vice versa. But the iframe from the cross-domain can

  1. Autoplay videos
  2. Display Forms
  3. Triggers Alert
  4. Run plugins – including malicious ones

We can prevent by adding X-Frame-Options header

Autofill

Autofill is the super useful feature for the user, but it might lead to Sensitive data exposure. Always be careful before adding the autofill="true" attribute.



Thanks for reading.

👇 Leave a comment 👇 If you have any question or suggestion.

Leave a ♥️ & 🦄. For more interesting content also check out my Twitter.

Securitybest practicesfrontendBeginner Developers