Forem: Varun Sukheja

Web Security 101: Understanding and Mitigating Risks of Broken Authentication

Varun Sukheja — Tue, 06 Feb 2024 17:36:58 +0000

These days as we are heading more and more toward the digital world, we see more Web Applications and Cloud applications and hence is the need of the hour to understand Web Security. Data security and privacy are of the utmost importance in today's world where data is the powering engine for almost everything in and around us. One such security threat that has topped the Web Application Security Threats list is Broken Authentication.

What is Broken Authentication?

Firstly let us understand what is authentication, Authentication is a process of verifying a user or device before allowing access to a system or resource.

Broken authentication attack as the name suggests, is an attack where an attacker tries to break into the system by gaining access to a User account. There are various methods which could lead to this like:
Weak password policies, Insecure Storage of Credentials, Insecure Session Management, Session Fixation, Insufficient Account Lockout, Session Timeout Issues, Insecure Password Recovery Mechanisms.

What, you don’t agree it is a big threat!

Well, I don’t just talk with words; I communicate with facts. Let me share a few of them here:

Zomato Reports Data Theft Of 17 Million Users

LastPass admits 'attackers have users' passwords', all details inside

1-Billion Yahoo Users' Database Reportedly Sold For $300,000 On Dark Web

Gaana.com Hacked, 10 Million Users' Details Exposed

I guess these many proofs are enough to understand that Broken Authentication is a big thing.

Understanding each of these attacking methods in detail

Weak Password Policies:

Weak Password Policies
Let’s understand first what is a password policy. A password is made up of a number of characters which includes alphabets, numbers, and special characters. Similarly, passwords can vary in length. Many people prefer shorter passwords, typically around 4–5 characters, for easier memorization. All these rules collectively form your password policies.

Now let’s explore what weak password policies are and how they could lead to an attack:

Short and Simple Passwords: Allowing passwords that are too short or easy to guess, like “1234” or “password.”
Allowing Common Words: Allowing passwords that are common words or phrases, making them easier for attackers to guess, like “iloveyou”, “admin”, and “password123”.
No Special Characters: Not requiring the use of special characters like !, @, or # in passwords, which makes them less complex.
Not Checking Against Known Weak Passwords: Failing to check if the chosen password is commonly used or known to be weak.
Lack of Multi-Factor Authentication (MFA): Not encouraging or enforcing the use of multi-factor authentication, which adds an extra layer of security beyond just a password.
Using Personal Information: Allowing the use of personal information such as name, date of birth, website name, etc., like “john123”, or “ram1905”, makes it very easy to predict.

Many attackers use the Brute force attack, where they systematically try out all possible combinations of passwords until they find the correct one.

Insecure Storage of Credentials

“Insecure Storage of Credentials” refers to a security vulnerability where sensitive information like usernames and passwords is stored in an unsafe manner, making it susceptible to unauthorized access. Storing user passwords insecurely, such as storing them in plaintext or weekly hashed formats like SHA1 and MD5, may lead to vulnerabilities.

Insecure Session Management

A session is a period of time during which a user interacts with a website, application, or digital product after successfully logging in. Did you notice in banking sites or mobile apps, if you are not active for around 15–20 minutes and when you make any action it says “Your session has expired for security reasons. Please log in again to continue accessing your account.”

Now, just imagine, that if a hacker gains access to your session, they can perform actions on that website/app on your behalf. Very scary right?😨

Poorly managed session tokens can lead to vulnerabilities. For example, session tokens that are easily predictable or not securely generated may be subject to session hijacking.

Session Fixation

Session fixation occurs when an attacker sets a fake session before the legitimate users can log in. Now when the user tries to log in, they will use the same session cookie that the attacker already knows, and thus the attacker-owned cookie is now authenticated and can be exploited.

Insufficient Account Lockout

Insufficient Account Lockout or Insufficient Session Logout is a vulnerability that can be commonly found in web applications and APIs and occurs when a web application fails to properly terminate a user session, thereby allowing a hacker to reuse it and gain access to a valid user session.

Session Timeout Issues

The session timeout determines the time a user can remain idle before the session is terminated and the user must log in again.
Hence, Session Timeout Issues refer to security vulnerabilities that arise when a web application does not have an adequate session timeout which means the timeout duration of a user session in a web application is either too long or too short, leading to potential security risks. It can leave the user’s session open for an extended period, allowing unauthorized access to their account and sensitive information.

Insecure Password Recovery Mechanisms Password Recovery is a mechanism that allows user to reset their password in case they find it difficult to access their account using their original password or they are unable to recall their original password. You can see most of the login forms have a ‘forgot password’ option at the bottom. Clicking on it takes you through the Password Recovery flow.

Insecure Password Recovery Mechanisms refer to vulnerabilities in the recovery method that allow an attacker to reset the password of another user without their consent. Insecure password recovery mechanisms may involve sending reset links over unencrypted email, allowing attackers to intercept them. Additionally, weak identity verification, easily guessable security questions, or failure to notify users of recovery attempts can compromise account security. For instance, if a recovery process lacks proper safeguards, an attacker might exploit it to gain unauthorized access to a user’s account.

For more such articles checkout my blogs at varunsukheja.com

Stop using {} in Typescript

Varun Sukheja — Mon, 27 Nov 2023 10:36:03 +0000

In the world of TypeScript, it’s pretty common to use ‘Object’ or ‘{}’ as a type when we’re expecting an object but aren’t quite sure about the object’s ins and outs. It’s like getting a mystery package — you know it’s there, but you’re not entirely sure what’s inside. But here’s the twist: while this practice might seem handy at first glance, relying too much on these generic object types can lead to some unexpected issues down the road. Let’s dive in and explore why it might be time to hit the brakes on using these ambiguous types in your TypeScript code.

Understanding the problem of using Object or {}

Whenever we have a variable in Typescript storing any object but aren’t sure about the object structure, we often use type Object for {} as shown below

type Param = Object;

type Param = {};

and using it at various places like function parameters:

function myFunc(obj:Param){
  console.log(params);
}

But this becomes a problem, as we know in Javascript an Object is the base of everything, hence allowing values like string, date, boolean, etc to be passed without throwing a Typescript error, as shown below consoles.

myFunc({name: 'John', age: 30});
myFunc('abc');
myFunc(123);
myFunc(true);
myFunc([1,2,3]);
myFunc(new Date());
myFunc(() => {});
myFunc({});

Now that we’ve glimpsed the hiccups caused by using Object or {}, it’s time to roll up our sleeves and explore a few different paths to solve these snags. By finding alternatives, we can pave the way for smoother, more predictable code.

Solution-1: using Record

We can use Record in Typescript to solve this problem. Record takes 2 types one for the key and another for the value as:

type Param = Record<string, unkown>

Here we can see <string, unknown> is passed to Record which means the keys will be of type string and values are marked unknown.

Let us see using the record in the above example myFunc

type Param = { [key: string]: unknown };
function myFunc(params: Param) {
  console.log(params);
}


myFunc({ name: 'John', age: 30 });
myFunc('abc');
myFunc(123);
myFunc(true);
myFunc([1, 2, 3]);
myFunc(new Date());
myFunc(() => {});
myFunc({});

Here we can see Typescript starts complaining out type for values like string, number, boolean, etc.

Solution-2: using index

Another approach is using the index where we can define the individual types for the key and value.
Let’s say we want to use type string for keys and unknown for values then we can define our param as:

type Param = {
  [index:string]: unknown
}

Note: index here is a placeholder and we can use any other terms like key, property, id, etc like:
type Param = { [key: string]: unknown };

now let us see what happens if use it in our example code with myFunc

type Param = { [index: string]: unknown };

function myFunc(params: Param) {
  console.log(params);
}


myFunc({ name: 'John', age: 30 });
myFunc('abc');
myFunc(123);
myFunc(true);
myFunc([1, 2, 3]);
myFunc(new Date());
myFunc(() => {});
myFunc({});

In the above example, we defined the type Pram using the index and this is how Typescript starts complaining when you pass params like string, number, boolean, etc.

For more such articles checkout my blogs at varunsukheja.com

Exploring TypeScript’s Potential: Mastering Value-Based Typing

Varun Sukheja — Wed, 15 Nov 2023 06:48:50 +0000

Hey there, fellow coder! Let’s dive into the fascinating world of TypeScript and its knack for value-based typing. You might have come across the usual stuff, like using the ternary operator or the extends keyword for conditional typing in TypeScript. But hey, there’s a whole new level to this game, and it’s all about conditional types based on actual values.

Getting Down to Basics

So, remember that snippet you might have stumbled upon:

type ValueType<T> = T extends number ? "Number" : "Not a Number";

Yeah, that’s the tip of the iceberg. Our mission here is to dig deeper into the world of conditional typings, especially when they’re based on the actual values themselves.

Unleashing the Power of Values

Let’s paint a scenario involving an order object. It’s got some optional stuff like estimatedDelivery, trackingNumber, deliveryDate, and cancellationReason. But here’s the catch: they’re all optional, and that can be a headache when you need them but they’re not there.

type OrderStatus = {
  status: string;
  estimatedDelivery?: Date;
  trackingNumber?: string;
  deliveryDate?: Date;
  cancellationReason?: string;
};

Enter value-based conditional types! We’re refining the OrderStatus type to make it super specific to different scenarios:

type OrderStatus = { status: string } & (
    {
      status: 'pending';
      estimatedDelivery: Date;
    }
  | {
      status: 'shipped';
      trackingNumber: string;
    }
  | {
      status: 'delivered';
      deliveryDate: Date;
    }
  | {
      status: 'cancelled';
      cancellationReason: string;
    }
);

Making Life Easier with Smart Functions

Now, let’s up our game by writing functions that perfectly match up with different OrderStatus situations:

function getOrderStatus(order: OrderStatus): string {
    if (order.status === 'pending') {
      return `Your order is pending. Estimated delivery: ${order.estimatedDelivery}`;
    } else if (order.status === 'shipped') {
      return `Your order has been shipped. Tracking number: ${order.trackingNumber}`;
    } else if (order.status === 'delivered') {
      return `Your order has been delivered on ${order.deliveryDate}`;
    } else if (order.status === 'cancelled') {
      return `Your order has been cancelled. Reason: ${order.cancellationReason}`;
    } else {
      return 'Invalid order status';
    }
}

Let’s Get Fancy with Mapping Types

We’re going even smoother now! By creating a mapping type, we’re tying up each OrderStatus with its own unique message generator function:

type OrderStatusMessages = {
  'pending': (order: { status: 'pending'; estimatedDelivery: Date }) => string;
  'shipped': (order: { status: 'shipped'; trackingNumber: string }) => string;
  'delivered': (order: { status: 'delivered'; deliveryDate: Date }) => string;
  'cancelled': (order: { status: 'cancelled'; cancellationReason: string }) => string; // Added handler for cancelled status
};

function getOrderStatusConditional(order: OrderStatus): string {
  const messageGenerator = orderStatusMessages[order.status];
  if (messageGenerator) {
    return messageGenerator(order);
  } else {
    return 'Invalid order status';
  }
}

Wrapping It Up

So, there you have it! TypeScript’s value-based conditional typing is like a superpower for coders. It helps you write code that’s not just efficient but also super adaptable to whatever comes its way.

By understanding, implementing, and mastering these cool tricks, you’re taking your coding game to a whole new level!

Remember, embrace those value-based conditional types in TypeScript and open doors to a whole new world of coding awesomeness.

For more such articles checkout my blogs at varunsukheja.com

Dev.to should have tagging for readers?

Varun Sukheja — Fri, 02 Oct 2020 10:33:33 +0000

Should dev.to also have a tagging feature for readers?
So basically readers can group their reading list/archive list like the way we do bookmarks with folders in chrome. This makes it easy to manage the reading list.

Formik VS Reat Hook Form which is better to use in React App for forms??

Varun Sukheja — Thu, 23 Jul 2020 05:08:12 +0000