Javascript Development & Security

There have been cases of Javascript security breaches all over ever
since its release. Even Facebook hasn’t been all of from its
vulnerabilities. Mark Zuckerberg’s own Facebook account was hacked and
he was informed in prior of the security risk Facebook had. To do away
with those security vulnerabilities, experts suggest some measures that
should be implemented so as to contain the risk. Javascript experts feel
that these vulnerabilities are a result of Javascript developers
failing to incorporate these measures to contain those risks.

One important thing to note is that “anything where we can get input
to our application and back to the backend is a potential hack factor or
vulnerability factor”. These would include Query Parameters, URL path,
PUT/POST parameter, Cookies, Referrer headers, file uploads, Emails,
Form fields, Web sockets, browser’s local/session storage etc.

Cross-Site Scripting (XSS)
This is one of the most common vulnerability in an app. XSS occurs when
any malicious or unwanted or unauthorised Javascript code snippet is run
in the victim’s browser or in side the application. This can lead to
the data being stolen, or the user being redirected, or compromising of
the clipboard data, or browser’s history. This can not be filtered
through a web app firewall as well.

XSS occurs when the application uses data parameters and pass it to the browser without properly validating the data.

Prevention

Validate and sanitise all the user based inputs.
Encode the output for specific contents, especially in cases where the output contains HTML tags.
Set proper headers like Strict transport security, X-frame-options,
X-XSS-protection, X-Content-Type-Options, Content-Security-Policy.

Cross-Site Request Forgery (CSRF)

This is pronounced as “see-surf”. It allows victim’s browser to make a
forged HTTP request. It forces the end user to execute unwarranted
actions on a web application in which they are currently authenticated.
So while the user thinks that he is just browsing his own dashboard, the
malicious code snippet loads in the background. For instance, there can
be a hidden frame of Facebook on a page and while the user is browsing
the page and is logged in to his Facebook account in the browser, the
code in the background can make him post content on his behalf.

Prevention

Include a random, unpredictable token in requests.
Add tokens to requests that can mutate the state of the application.
Incorporating captcha. Origin of the request must be verified.

Session Management

Hackers normally use leaks/flaws in the authentication mechanism to impersonate other users.

Prevention

Don’t expose session tokens in the URL.
Session tokens should have a timeout.
Recreate session tokens after every successful login.
Use HTTPS feor sending tokens.
Use appropriate permissions.
Use some well known authenticating mechanism.

Strict Mode for Javascript

Use strict mode whenever possible.
This eliminates silent errors and shows them all the times.
It helps the Javascript engine perform optimisations on the code.

Sensitive Data Exposure

Use SSL/TLS(HTTPS).
Encrypt all sensitive data at rest and in transit.
Do not store unnecessary data.
Disable cache on forms that store sensitive data.

Password Management

Use strong algorithms for hashing passwords.
Enforce stronger passwords.
Use 2 factor authentication.
Use Google authenticator.

Handling Cookies

For cookies set the following flags:
Secure: only to be used over HTTPS.
Do not allow the cookie to be accessed via Javascript.

Enforce proper cookie scoping.
Only to be accessed by certain domains.
Only accessible on certain paths.
Expires after a stipulated time.

This article contains some parts that were taken from a talk titled
“How To Write Secure JavaScript Applications” by Jared Smith at an event
“Nodevember 2016”