DEV Community: Chinmaya Tripathi

🚀Supercharging Docusaurus with MSW: Mock APIs for Live, Interactive Docs

Chinmaya Tripathi — Sun, 21 Sep 2025 22:16:04 +0000

When you’re building documentation for an API or product that depends on backend data, you face a familiar challenge: how do you make your examples feel real without relying on a fragile staging environment or exposing production endpoints?

This post is not just a set of code snippets — it’s a deep-dive tutorial and understanding guide for using 🛠 Mock Service Worker (MSW) with 📚 Docusaurus. By the end, you’ll know not only how to set it up.

💡** Why Documentation Needs Realistic API Responses**

Have you ever followed an API tutorial, clicked “Run”, and immediately hit an error? ❌ Maybe the staging server was down. Maybe you didn’t have the right auth token. Maybe the data just looked… boring.

Your readers feel this too.

By mocking your APIs, you:

✨ Guarantee Consistency: The data in your examples always matches the docs.

🧪 Provide a Safe Sandbox: Readers can experiment with code samples without breaking anything.

⚡ Lower the Barrier to Entry: No auth keys, VPNs, or setup steps needed — just run npm start.

✈️ Enable Offline Work: Contributors can work from a plane, train, or anywhere without internet.

MSW intercepts requests at the network layer (Service Worker), which means your frontend doesn’t know the difference between real and fake APIs — perfect for interactive docs.

🏗 Step 1: Installing MSW — The Foundation

First, install MSW as a development dependency:

npm install msw --save-dev

This adds the core tooling you’ll need to spin up a Service Worker in development.

🗂 Step 2: Designing Your Mock Architecture

Before writing code, think about the architecture:

Handlers: Define each endpoint you want to mock.
Browser Worker: Bootstraps MSW in the browser.
Node Server (Optional): Lets you reuse the same mocks in tests.

Create a folder structure like this:

my-docusaurus-app/
├── src/
│   ├── mocks/
│   │   ├── handlers.js  ← endpoint definitions
│   │   └── browser.js   ← bootstraps MSW
│   └── theme/
│       └── Root.js      ← starts MSW in dev mode

This structure makes it clear to future contributors where the mocking logic lives.

✍️Step 3: Writing Your First Handler

Think of a handler as an API contract in miniature — it specifies which HTTP verb, which endpoint, and what response should come back.

// src/mocks/handlers.js
import { rest } from 'msw';

export const handlers = [
  rest.get('/api/info', (req, res, ctx) => {
    return res(
      ctx.status(200),
      ctx.json({
        message: 'Hello from MSW! This is a stable, predictable response.'
      })
    );
  }),
  rest.post('/api/login', async (req, res, ctx) => {
    const { username } = await req.json();
    return res(
      ctx.status(200),
      ctx.json({ token: `fake-jwt-token-for-${username}` })
    );
  })
];

This makes it easy to reproduce login flows or fetch requests without a live backend.

🌐Step 4: Bootstrapping MSW in the Browser

Create src/mocks/browser.js:

import { setupWorker } from 'msw';
import { handlers } from './handlers';

export const worker = setupWorker(...handlers);

This file ties together all handlers and creates a single Service Worker entry point.

🏃 Step 5: Starting the Worker in Docusaurus

We want MSW to run automatically when the docs load in dev mode. Docusaurus provides a way to wrap the entire app via Root.js.

// src/theme/Root.js
import React, { useEffect } from 'react';

export default function Root({ children }) {
  useEffect(() => {
    if (process.env.NODE_ENV === 'development') {
      import('../mocks/browser').then(({ worker }) => {
        worker.start({ onUnhandledRequest: 'bypass' });
      });
    }
  }, []);

  return <>{children}</>;
}

Why onUnhandledRequest: 'bypass'? It ensures requests that aren’t mocked still hit the real API, which is useful if you’re mocking only part of your backend.

🎨Step 6: Making the Docs Interactive

Here’s an example React component that fetches data from our mocked endpoint:

import React, { useEffect, useState } from 'react';

export default function ExampleComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/info')
      .then((res) => res.json())
      .then(setData);
  }, []);

  return (
    <div style={{ background: '#f8f8f8', padding: '1rem', borderRadius: '8px' }}>
      <h4>Mocked API Response</h4>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

This creates a live component right in your documentation, so readers can see actual responses as they would appear in a real app.

🏗Handling Deployment on GitLab Pages (Dynamic URLs)

One challenge I faced after integrating MSW was deploying the docs on GitLab Pages. Each pipeline run generated a dynamic URL like:

https://myproject.gitlab.io/-/jobs/235345/artifacts/public/index.html

By default, MSW looks for mockServiceWorker.js at the root (/mockServiceWorker.js). On GitLab Pages with dynamic URLs, this broke because the Service Worker lived at:

https://myproject.gitlab.io/-/jobs/235345/artifacts/mockServiceWorker.js

which is dynamic for each pipeline.

The Fix

When calling worker.start(), you can pass a serviceWorker.url option to tell MSW exactly where to find the file:

worker.start({
  serviceWorker: {
    url: `${window.location.pathname.replace(/\/index\.html$/, '')}/mockServiceWorker.js`
  }
});

This dynamically computes the correct URL based on the current page’s path, ensuring MSW is always found regardless of the pipeline run.

This small tweak made the GitLab Pages deployment reliable and future-proof, so every pipeline produced a fully functional, interactive documentation site.

Step 7: Common Pitfalls and How to Avoid Them

CORS Errors: Make sure your mocked URL exactly matches what fetch is requesting (including domain).
Worker Not Starting: Forgetting to import browser.js in Root.js means MSW never runs.
Production Builds Breaking: Guard MSW startup with NODE_ENV so it only runs locally.
Dynamic Paths on CI/CD: Use serviceWorker.url to point MSW to the correct location in CI/CD deployments.

Beyond Development: Using MSW in Tests

One of MSW’s superpowers is that you can reuse these mocks in integration tests:

import { setupServer } from 'msw/node';
import { handlers } from './handlers';

const server = setupServer(...handlers);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Now your tests, your local dev environment, and your documentation all speak the same language.

Conclusion

Mocking APIs in your Docusaurus site isn’t just a gimmick, it’s a professional touch that sets great documentation apart. By using MSW, you get production-like responses without production-like headaches. Your users learn faster, and your team spends less time troubleshooting docs.

ViteJS vs. Webpack: The Ultimate Showdown

Chinmaya Tripathi — Thu, 05 Sep 2024 04:11:52 +0000

There’s been a lot of buzz about who’s the reigning champion—ViteJS or Webpack. It’s the ultimate face-off, raising questions about which tool is the better choice and how development might change depending on your pick. With so many questions and often unclear answers, this blog aims to clear the air. We’ll dive into how Vite, the new hero on the block, stacks up against the classic, tried-and-true Webpack, and explore why it might just be the game-changer you’ve been looking for.

The Old Mighty Webpack:

Webpack has long been the go-to bundler for JavaScript applications, renowned for its versatility and power. It’s like the Swiss Army knife of bundlers, offering advanced features like code splitting to optimize loading times by breaking apps into bite-sized chunks. With its robust plugin system, Webpack supports a vast array of customizations, handling everything from asset management to intricate build processes. Its detailed configuration options allow for precise control, making it the dependable choice for large-scale and enterprise-level projects.

Webpack Docs

And Here Comes Our New Guy - Vite

Enter Vite, the fresh contender that’s shaking up the development scene with its speed and simplicity. Vite is like the new kid who shows up at the party and instantly becomes everyone’s favorite. It boasts lightning-fast development server start-ups and near-instant hot module replacement (HMR), thanks to its use of native ES modules and esbuild for pre-bundling. Its modern approach simplifies configuration, offering a seamless experience with less overhead. For production builds, Vite calls in Rollup for optimized, efficient output. With its focus on developer experience, Vite is quickly becoming the go-to for modern, fast-paced projects.

Vite Docs

IMO choosing between ViteJS and Webpack is a bit like deciding whether to use a jetpack or a trusty old backpack for your next adventure. The jetpack (ViteJS) will get you there faster and make you look like a superhero. The backpack (Webpack) might not be as flashy, but it’s reliable and can carry all the gear you need for the journey.

_So let’s have it _

ViteJS vs. Webpack: The Ultimate Face-Off

Development Speed:

ViteJS: Imagine having a superpower that lets you skip the waiting time—ViteJS is that superpower. It’s designed to be lightning-fast during development. By using native ES modules, it serves your files instantly, making server start-ups and hot module replacement (HMR) feel like magic. Blink, and your changes are live!
Webpack: Think of Webpack as a diligent but slightly slow-moving assistant. It bundles all your code and assets into neat packages even while you're developing, which can slow things down. Its HMR can be a bit sluggish, as it has to rebuild and re-bundle parts of your app to reflect changes.

Bundling Approach

ViteJS: Vite is a minimalist at heart. During development, it skips the bundling hassle and serves unbundled ES modules directly. When it’s time for the big show—production—Vite calls in Rollup for optimized, slick bundles.
Webpack: Webpack is the ultimate packager, bundling your code and assets for both development and production. It’s flexible and powerful, handling all sorts of bundling needs with its extensive plugin system.

Configuration Complexity

ViteJS: Vite is the easy-going friend who keeps things simple. Its configuration is straightforward and opinionated, meaning you can get started quickly with minimal setup. It’s like having a streamlined, user-friendly interface for your development environment.
Webpack: Webpack, on the other hand, is the seasoned expert with a vast array of settings. Its configuration options are as extensive as they are complex, offering flexibility at the cost of a steeper learning curve. If you enjoy tweaking every detail, Webpack has you covered.

Hot Module Replacement (HMR)

ViteJS: Vite’s HMR is like a turbo-charged pit crew—swiftly swapping out the parts that have changed without missing a beat. It only replaces the affected modules, keeping the development experience smooth and efficient.
Webpack: Webpack’s HMR is hardworking but can be a bit slower, as it needs to rebuild and re-bundle parts of the application. It’s reliable, but it might make you wait a little longer for your changes to appear.

Ecosystem and Plugins

ViteJS: Vite is the new kid on the block with a growing collection of plugins. It might not have as many options as Webpack yet, but it supports Rollup plugins to extend its functionality. It’s quickly catching up!
Webpack: Webpack is a seasoned veteran with a vast, mature ecosystem. Its extensive library of plugins and loaders means you can customize and extend it to meet nearly any need. It’s a well-established tool with broad community support.

Build Output

ViteJS: Vite’s production builds are like finely tuned race cars—optimized and performance-focused, thanks to Rollup’s powerful bundling. It includes features like tree-shaking to keep the final output lean and mean.
Webpack: Webpack also delivers top-notch production builds with optimized code splitting and tree-shaking. However, achieving these optimizations can involve a bit more configuration work, making it a powerful but complex tool.

Too much information? Alright, let’s wrap it up before we end up with more comparisons than a buffet menu!

When choosing between ViteJS and Webpack, it’s clear that each tool has its own superpowers. ViteJS shines with its speed and simplicity, making it a top pick for modern projects that demand a smooth and speedy development experience. It’s perfect for new or smaller applications, especially when using frameworks like React or Vue, and lets you focus more on coding and less on configuration.

But don’t be fooled—ViteJS isn’t just a shiny new toy. It’s mature enough for production use, and here’s why: It’s got stable releases and a solid track record in real-world projects, ensuring it handles both development and production builds efficiently. Vite’s performance optimizations, thanks to Rollup, deliver optimized, performant output with features like tree-shaking and code splitting. Its growing adoption by numerous projects and companies proves its reliability, while an active community and responsive development team keep it on the cutting edge. Plus, with comprehensive and continuously updated documentation, Vite makes adoption and troubleshooting a breeze.

On the flip side, Webpack’s extensive ecosystem and flexibility make it the go-to for large-scale and complex projects, or if you’re dealing with legacy code. It’s been around longer and offers a mature, customizable build process that’s ideal for enterprise-level applications.

So, if you’re gearing up for a modern, agile project, ViteJS is your speedster with a solid pedigree. For complex, established needs, Webpack’s the experienced pro. Choose wisely, and may your build process be as smooth as your code!

TIME ANALYSIS OF KEYSTROKES AND TIMING ATTACKS ON SSH

Chinmaya Tripathi — Mon, 14 Nov 2022 19:57:42 +0000

DON XIAODONG DON | DAVID WAGNER | XUQUING TIAN
TIME ANALYSIS OF KEYSTROKES AND TIMING ATTACKS ON SSH
(Summary by CHINMAYA TRIPATHI)

*RESEARCH AT A GLANCE: *
SSH provides a secure channel between two hosts. Despite its protective mechanisms, it is open to a lot of security mechanisms. For suppose, the transmitted data packets are padded only by 8-byte boundary, which can reveal the size of data and second the data being sent to the receiver with the user tapping each button on the keyboard. These small minor mistakes could lead to some serious security vulnerability. This paper covers some of the important aspects of transmission of data over SSH. The authors further develop mechanisms, which try to monitor and learn user data by monitoring SSH sessions.

*INTRODUCTION (Problem statement): *
Following the vulnerability of rlogin, ftp and telnet, which transfer the data over the network openly be it wireless or ethernet, creating an opportunity to an attacker to access all the data without much hustle. SSH was introduced, which came widely into practise because of its secure data transfer and reliability over any network.

Although SSH provides good encryption and secure data transfer, this paper highlights some of the techniques which can result in finding some substantial data being transferred over SSH, even though it is called out to be a secure transfer.

RESEARCH STUDY: The paper begins with studying the user's keyboard dynamics, which does reveal the information typed in the set of intervals. Looking more into detail, it revealed 1 bit of information about the content per keystroke of the keyboard. When this sequence was used in a hidden Markov Model named Herbivore (an attacker system), which records the information of a user entering the password over the network, resulted in the conclusion that passwords were chosen into a randomly uniform length of 7-8 chars. This reduced the cost of password cracking by 50 and then they focused on to include some countermeasures to eliminate this vulnerability.

It was also brought into account that this vulnerability does not limit to SSH, instead it can result in any encrypted data transfer protocol.

EAVESDROPPING SSH:
The experiment involves listening to the conversation between the client and the server which involves the data sent the client and server simultaneously, reading the packet size, monitoring the intervals the message was being sent and the pattern in bits with which the data would be sent from and to client-server. The way eavesdropping works is the attacker can learn 1-bit of data sent over the server and apply the model trained to determine the data possibility.

There are some significant attacks implemented to measure the scarcity of the attack and measure upto what extent it can affect and exploit the system. The attacks are based on the Hidden Markov Model and the ‘n’ Viterbi algorithm which help to determine the patterns and the data which can be transmitted over the network.

Traffic-signature attack: This attack involves an attacker trying to know the password paradigm with the SU linux command to the server. When the server asks for the password from the user by reading the command (SU). The attacker tries to identify the pattern of bytes returned when this certain command is being typed i.e. SU. The amount of back and forth transfer of data between the server and the client and the time to authentication, and when the user enters the password, there is no transfer of packets to the client results in recognition of password bits transferred to the server. Hence it can be traced.

Multi-user attack: In this attack, the attacker tries to examine the ‘ls’ command by the user which prints all the contents of the system present directory and helps him examine the status of authenticity of that particular user. Now, when the user tries to login, or for any other command which requires the user for root level access, the server requires a password, and this could be monitored by the attacker.

Nested SSH attack: This attack involves attacker monitoring for a connection which is made through the remote system the user is already connected to. While logging into the third system, the user transfers the password twice, that is from his own system to second and from there to third. The attacker gets a chance to verify the pattern of password by reading both the data transfer between A -> B and then B -> C, which results in even quicker pattern recognition, especially when using the designed model to detect the pattern for specific input type.

The data collected by the attacker is the interval between the two keystrokes. Hence, we focus only on key-press events. The time difference between two key presses is called the latency between the keystrokes and we can use this term inter-keystroke timing to refer to the latency between two keystrokes.

Further the patterns are read with certain constraints like, auth repetition, bit repetition, latency measurement and other, which lead to a certain prediction about the data the user is transferring/exchanging to the server frequently. This could consist of some valuable data when connecting dots. The calculation depends upon simple timing characteristics, which consist of a user typing two letters with alternative hands, matching combinations like alpha-numeric, only alpha or only numeric. This information when put into the derived models like Gaussian Modeling, can result in some valuable data the attacker can take advantage of.

In conclusion, when tried on different methods like password inference on a single user and multiple user, they give some substantial information. Organizing the long sequential patterns in the input helps the model to analyze the data.

COUNTER MEASURES: Although the attacker can figure out the pattern of keystrokes, if the echo for empty packets is turned off on server end and for each keystroke, the server returns the dummy packets which will be ignored by the client will reduce the effectiveness of the traffic signature attack, as it prevents enter-keystroke timing information.

We can also modify the SSH to receive the packet by a random amount of ‘n’ milliseconds between every keystroke. This could eliminate constant monitoring for passwords. Another way is to set a response and client request at a rate of 50 milliseconds. Since the rate is constant, in general the transmission of data will be the same for every exchange of data which will result in original data as well as dummy traffic data sent by the server at a constant rate. Although this packet doesn't help in preventing the size of packets sent for-through client-server, it diminishes the password or sensitive data between the client and server because of the same packet size.

CONCLUSION:
The paper concludes with the fact that the weaknesses reveal a surprising amount of information on passwords and other text typed over SSH sessions. The timing information opens up some of the new set of risks, which the authors recommend that developers take care when designing these types of protocols.
The transmitted packets which are sent over the network are padded only to an 8-byte boundary, which reveals the approximate size of the original data. And, in interactive mode, every individual’s keystroke typed is sent to the remote machine in a separate IP packet, which is immediately after the key is pressed, which leaks the inter keystroke timings of what the user is typing, i.e the precise inter-keystroke timings of users’ typing from the arrival times of packets.

REFERENCES:
https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf
https://sites.cs.ucsb.edu/~bultan/courses/595-F16/Week2.PDF

ROBUST DEFENSES FOR CROSS-SITE REQUEST FORGERY

Chinmaya Tripathi — Mon, 14 Nov 2022 19:52:09 +0000

ADAM BARTH | COLLIN JACKSON | JOHN C. MITCHELL
ROBUST DEFENSES FOR CROSS-SITE REQUEST FORGERY
(Summary by CHINMAYA TRIPATHI)

RESEARCH AT A GLANCE:

This paper points to a new method in CSRF attack: Login CSRF, which would redirect users to an honest webpage but as an attacker. It has put in a decent amount of attention to the use of the ORIGIN flag in HTTPS header, which works effectively to defend against such CSRF attacks as it eliminates the security issues by browser as well as provides a good reference from where the request is coming.

INTRODUCTION (Problem statement): Cross-Site Request Forgery (CSRF) is an attack which forces an end user to do unwanted actions on a web application in which they’re currently authenticated.

CSRF in-depth: The paper divides the CSRF threat model in two parts -
1) In-Scope Threats which include - Forum posters where an attacker can post malicious data on the website with the help of a post (an image, hyperlink etc.), Web attacker where an attacker owning a domain instructs the user’s browser to issue a cross-site request using GET/POST methods. And, Network attacker where the DNS server is compromised and attacker controls over the user's network.
2) Out-Scope Threats which include - XSS where an attacker inject a malicious script into site’s vulnerable/critical section, Malware where the attacker run’s a malicious software on user machine, DNS Rebounding where an attacker obtains network connectivity by binding an IP address to a server of attacker, Certificate Errors, where false certificates are provided to bypass browser security and Phishing where an attacker steals user’s credential using a fake login page or similar.

Until now, the discussions on CSRF focus more on server-side state mutation rather than focusing on browser-side state. And here comes in the Login CSRF vulnerability which takes advantage of this scope of exploit and disrupts the scope of user’s session integrity. The paper presents all the critical points associated with this vulnerability by giving a detailed explanation of how it could be dangerous with examples of some widely used online platforms like PayPal and iGoogle.

Are there any defense mechanisms?
There are three widely used defense mechanisms against CSRF attacks: Validating a secret token which includes validating a secret token which is secretly received by users’ sessions. HTTP Referer header, which includes accepting the requests only from trusted sources. And, XMLHttpRequest, which includes setting a custom header via XMLHttpRequest and validating that the header is present before processing state-modifying requests.

Although all three mechanisms have their own pros and cons, the HTTP Referer validation is a good CSRF defense, but is hampered by the suppression of the Referer header. To evaluate this defense, an experiment was conducted which concluded that although the Referer header is suppressed often over HTTP, it is rarely suppressed over HTTPS, letting current sites prevent CSRF by using HTTPS and strict Referer validation. And later, it was proposed, that to create a robust CSRF defense, browsers should include an “Origin” header with POST requests which let sites defend against CSRF by deploying a few simple web application firewall rules which provides security benefits of the Referer header while addressing the privacy concerns which lead to the widespread suppression of the Referer header.

RESEARCH (experiment):
The objective of this research experiment was to conduct how often and under what circumstances the referrer field is blocked or suppressed by the browser. There were two machines in the lab serving advertisements on numerous channels. Randomly selecting the server when clicking on ads, it generated GET and POST requests and hit the two servers respectively. When permitted by the browser’s security policy, the advertisement generates same-domain requests to the primary server and cross-domain requests to the secondary server. The incoming request was logged by the server along with monitoring header fields like referer and user-agent, HMAC, etc which were sufficient to distinguish the request made by which user.

Observations: When observed, the referer field was suppressed by the HTTP more often than HTTPS. Examining both the type of requests that is same domain and cross-site domain, it drew to a conclusion that referer field was suppressed by the HTTP more often than HTTPS because network proxies are able to remove the header from HTTP traffic but unable to do so from HTTPS traffic. It was also observed that document.referer is suppressed by the browser as referer is suppressed by the network. This could be due to its not being supported in many of the tested browsers.

It was noticed that the referer field was suppressed by the browser due to privacy concerts because when a browser sends referer in header, it shows all the information about the website the request is coming from. There is more evidence of field suppressing for a cross-site request as compared to same site request. This shows the same request when done from two different ways have different impacts.

Conclusion: The researchers drew two conclusions based on their experiment. The CSRF attacks can be defended when using a referer in the header along with HTTPS requests. HTTP requests cannot omit to block requests that do not have a referer header in their request, so use HTTPS instead.

The privacy of each user surfing the web is important, hence all the modern web browsers should implement strict referer validation in incoming requests. Usage of custom HTTP headers can also be an effective way to prevent CSRF attacks because the browser prevents sites from sending custom HTTP headers to another site, but allows sites to send custom HTTP headers to themselves using XMLHttpRequest.

PROPOSAL: Following these experiments, evolved a new proposal where a different attribute was proposed to be added into the header that is “ORIGIN”. While making a POST request, the ORIGIN header respects the privacy concerns of browsers, hence not widely suppressed. It includes limited information required by browsers to verify whether the request is genuine or not, eliminating extra fields like path or query portions of the URL. This request is only sent for POST requests not other (GET) requests which result in saving a lot of information getting leaked while making any request. This approach comes with certain conditions which include elimination of all requests whose ORIGIN flag is null or have an undesired value, hence an attacker can’t make a supporting browser a non-supporting browser.

In addition to this, a browser should implement DNS rebinding and shouldn't opt into cross-site scripting requests from untrusted origins.

CONCLUSION: Concluding the research, it was brought into the attention that CSRF is a widely exploited vulnerability and all the browsers should implement a defense mechanism against this attack. The implementation was categorized in three major categories -
Login CSRF: Requesting to implement strict referer validation while performing any request over HTTPs requests. The site should reject a request if it doesn't have any referer header to defend against any malicious request.
HTTPS: Crucial sites like banking should limit cross-site requests only till their landing pages, and strictly follow the referer header validation to prevent CSRF attacks.
Third-Party content: Site’s including hyperlinks or video players should implement token validation correctly with the help of secure frameworks and bind the token with a user's session, if the framework lacks, they should not accept the request and block them.

REFERENCES:
https://owasp.org/www-community/attacks/csrf
https://seclab.stanford.edu/websec/csrf/csrf.pdf

REFLECTIONS ON TRUSTING TRUST

Chinmaya Tripathi — Thu, 10 Nov 2022 21:08:44 +0000

KEN THOMPSON’S
REFLECTIONS ON TRUSTING TRUST
(Summary by CHINMAYA TRIPATHI)

INTRODUCTION (Problem statement):
Ken Thompson’s reflections on trusting trust is one the most crucial papers in the history of computer science, which unearths one of the most important problems one could ever encounter in software vulnerability. It emphasizes over a fact that how important it is to trust a code written by any other programmer. Ken starts his statement with the following lines -

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

About the author: Kenneth Lane Thompson is an American pioneer of computer science. Thompson worked at Bell Labs for most of his career where he designed and implemented the original Unix operating system.

RESEARCH STORY (Approach and methodology):
Getting started with his research paper, Ken unearths the trust factor when it comes to using someone else’s code. The beginning of his research starts with Ken talking about one of his programming exercises he got started with, where he later discovered how easy it is to introduce Trojan horses in software and later emphasizes on how important it is to emerge the need for new laws and new social rules for these kinds of weaknesses, in the computer system.

The way he articulates his research covering each point at a time and later combining all of them to conclude his finding is exemplary, he describes an attack on computer systems at the level of the C compiler. He breaks down the attack into three critical stages:

Step 1: This step tells about the programming exercise where he was supposed to create the shortest self-producing program i.e to write a source program that, when compiled and executed, will produce an exact copy of the source as its output. Which means that the output of the execution, of the compiled code, is equal to the source code.

Step 2: Here he points out, since the compiler to compile this code is also written in C language, this could lead to some problems like character escaping, which means it could print some characters which aren't supposed to get printed in the output. He gives an example of
“ Hello World \n”, where \n represents a new line. This is pointed out as an ideal C compiler which interprets the character escape sequence.

The point he tries to emphasize here is that if a C program contains a trojan horse, all the compilers built on the top of the program will result in defective one and could be used in an evil way to satisfy a hidden (evil) purpose.

Step 3: In this step, we tweak the code to deliberately miscompile the program when a particular pattern is matched calling it a trojan horse. The bug planted in the compiler would match to the login mechanism of a UNIX system, which would recognize every password valid for every other account in the system. This could result in a security breach since we are able to login into any system which uses the login command compiled by our compiler.

Although, the abstract idea of stage 3 is understandable, yet using an example of logging in into the system by showing the exploit (evil code) or its working would have put some great detail on what Ken wants to conclude.

FINDINGS:
Now, if we combine all the three steps, we could create a powerful attack because since our C compiler would produce the same malicious features to the source code before compilation, because of the fact that it recompiles itself, this could be undetectable. This could turn into a trojan horse.

It’s really surprising to find that such subtle frictions (which are the building blocks) of any software could be vulnerable. It’s something which is neglected by all the developers as well as research scientists in the name of truthfulness (that the code has been written by someone professional and genuine who works at a multinational corporation) but this is the fact that Ken wants to magnify and how overstated this is.

MORAL (Conclusion):
At first, his methodology may seem a little confusing, it’s a little difficult to grasp his motive with respect to the title and the articulation of the paper, but in the end, when connect the dots and get the whole idea in the conclusion, where he finally, he concludes his research on moral grounds emphasizing that you cannot trust the code written by any other programmer unless you write the code yourself. He also phrases this line - Perhaps it is more important to trust the people who wrote the software, which somewhere or the other proves his earlier discovery of a vulnerability. He also criticized the role of media and movies encouraging the young ones to practice hacking, thinking it as a ‘cool’ and ‘genius’ thing. He adds, “The press must learn that misguided use of a computer is no more amazing than drunk driving of an automobile”. He also tells how big tech giants enforce strict hacking policy because the bigger the company, the easier it is to get the access.

REFERENCES:
https://en.wikipedia.org/wiki/Ken_Thompson

Blockchain - Overview

Chinmaya Tripathi — Mon, 24 Jan 2022 17:46:53 +0000

After a ton of research, reading blogs and referring documentation, I've tried to summarize the concept of blockchain by giving an overview about what exactly it is, covering all the important foundational information one needs to get started with it.

So what is blockchain?

Well in simple words, it’s basically a distributed immutable digital ledger of transactions that is duplicated across the entire network of computer systems (nodes).

In terms of blockchain, a single transaction or record is called a block[]. Which holds all the information with respect to that transaction. Forming a chain of such blocks(transactions) is called a blockchain.

So Why should we study blockchain?

Because it’s the future, it eliminates the concept of centralized data and helps in the verification and traceability of multistep transactions. Building decentralized applications is the way, which are safer and more secure.

In short build a sense of trust in making a transaction. (I'll explain the concept of immutability further, but for now understand it this way that once a transaction has been made, nobody can alter it).

How does blockchain work?

It's an immutable ledger - All the nodes are connected in a distributed peer to peer system. So suppose, if an attacker tries to mutate the data of an existing block (change some information in a blockchain), it will be immediately corrected by other nodes connected to the network.

When a block is added or changed in a blockchain, a message is broadcast to all other nodes connected in the network. Each node match the consistency of the information with their blockchain, if something is wrong, the victim node is immediately notified and the state is corrected.

The concept of correcting an incorrect blockchain consist of majority of the nodes having same state from the one which is different, because it's present in a distributed immutable environment.

Diving deeper - Let's see how a single block looks in blockchain...

A block consists of -

A Block number
Data
Previous hash
Hash

Note: First block is called the genesis block.

The Algorithm used is SHA 256 which Encrypts the data into a 64 hexadecimal char of 4 bits each, which is equal to 256 bits.

And how the blocks are connected?
So, its something like Block1 -> Block2 -> Block3 -> Each block contains prev hash value of block and its own hash.

Note: Data cannot be decrypted once encrypted.

What is a distributed P2P network?

Thousands (even more) of node connected to each other in a network, where each node contains a copy of the blockchain. Whenever a node adds a transaction, it transmits a message to all the other nodes connected and everyone adds that transaction to their chain(if course they verify whether the transaction is valid or not, but we'll talk about it later), maintaining the consistency of the network.

The advantage of having a distributed p2p network is that it eliminates data tampering. Suppose A’s data gets changed, it gets notified by all the other nodes connected to it about data tampering and since the majority of connected nodes have different data as compared to what A has now, it correct its mutated data and balances the integrity again. This scenario is also called the byzantine fault tolerance problem.

Consensus protocol - > which prevents attacks on blockchain and also validate each transaction addition.

POW(Proof of work) -> This is something which comes into play when a blockchain miner mines a particular transaction to add it into their blockchain. Miners have to solve a math problem and then a block is mined.

So suppose, a transaction is added to a blockchain in a node. When a miner solves a math problem and adds that transaction to the chain, they are rewarded, solving a problem and adding it into the blockchain is not at all an easy job, so they show their proof of work before adding the transaction to the blockchain and every other node runs an algorithm to verify that the added transaction is valid or not. Once verified, all the other nodes in the network add that block to their chains.

Curious question - What if two nodes add two transaction simultaneously? Which one will be added first?

So, if two nodes transact a two blocks simultaneously at the same time, then the entire network waits until one of the adjacent nodes or the main node(from where the initial transaction blocks were added) add one more block to them increasing their length. In such case the all the other nodes have to accept the that particular nodes added block and add it to their blockchain, discarding their initial node (which is also called the orphan node).

That’s why we follow a six-step confirmation approach to have a successful transaction.

Finally, I would like to conclude by emphasizing to research more about this technology which could revolutionize the concept of application security and transaction transparency. Not only this, blockchain has much more to offer, it can be an effective addition to some vital sectors like government, supply chain, healthcare, cyber security and many more...

Getting started with Penetration Testing!

Chinmaya Tripathi — Fri, 12 Jun 2020 18:14:25 +0000

I've always been fascinated by the science behind hacking, the art of exploitation, cracking something, thinking about how it all works. Finding a vulnerability and then exploiting it isn't as easy as it looks like in the videos. Trying to write my first ever blog, I thought of starting it with writing about the field I love the most.

1. Introduction

Penetration testing often called as 'pen testing' has been the most important and rapid growing sectors of cyber security field. With growing data there is growing demand for security to protect it as well and this is where the role of an Ethical hacker comes into play. Pen testing is done by an hacker to crack and find out the vulnerability inside any system, the idea is to get the security professionals act like attackers and crack the system down to find its vulnerability and further help the organization to strengthen it in order to protect it from any real offensive attack.

2. Hacking with Ethics -

We know there are good as well as bad people in any field, you as an ethical hacker would do everything by taking the permission from the organization, under the law, though our intention should be to crack the organization's security yet only to strengthen it more, not to use it for any false purposes and this is what differentiates us from the bad one's.

Alright! Enough about the banal theory, lets get started..

3. Prerequisites -

If I'd have to really talk about the requirements in detail, I'd probably have to write another blog for it, but I would like to be as simple and precise telling you the most basic requirements needed for getting started with penetration testing.

1) Networking basics - You don't have to know everything but basics are very important like - IP, MAC Addresses, the OSI Model, specially the TCP, UDP and three-way handshake protocol. Common ports and their protocols and subnetting. File transfer protocols like ftp and ssh Having this much knowledge for starters is enough to dive into this field.

2) Linux - You would probably be setting up your testing lab using either kali linux or parrot, these distros have inbuilt tools which are really helpful in carrying out the attacks. Ofcourse you can go ahead and make your own tool and scripts but for starters this is where almost every other newbie starts its journey, you would get your work done and focus more about the methodology behind pen testing rather than worrying about coding the tools and programs to run attacks. Get familiar with basic linux commands like navigating file systems, network commands, starting and stopping services, users and privileges.

3) Programming and Scripting - Most important, though not necessary to be god in it, but yes you should have an intermediate level knowledge about any programming language like python, golang or ruby because mostly all the tools are written using these languages. I've seen many people say its not necessary to know any language but not according to me, as someday or the other you will write your own exploits and make tools, so why not to start learning in advance, you can contribute to the community by helping improve on some existing exploits and tools as well. Also, having some knowledge about bash scripting is very useful in post exploitation.

4) Hacking Paradigms - Even if theoretical but having a good knowledge about basic hacking paradigms is important, for example enumeration, privilege escalation, reverse tcp shell, local, remote exploits, maintaining the session, covering the tracks. These are some very common things done while exploitation and should be understood.

4. Tools -

There are a ton, I repeat a ton of tools available to begin with, and its really hard to choose between them. But I would list out some of the most basic tools which you'll use executing any attack.

1)Nmap : An amazing network scanning tool coming with a lot of different modes to scan a given target. You can use this tool to find out all the open ports on the victims machine and plan out your attack from there. An aggressive nmap scan can even list out the available vulnerabilities and exploit hints available if any.

2)gobuster/dirbuster : Mostly used when targeting a web server, both the tools help you get all the directories of an website, from where you can find and target any vulnerable thread and break into the server

3)hydra: One of the most powerful tool for brute-force attack. You can use this tool brute force against any login form and easily crack the admin password if they have not set their password hard enough.

4)metasploit : Most powerful and widely used with over 7000+ available exploits, Metasploit makes your job way easier. It helps you by providing an exploit for almost every other vulnerability. It is widely used to gain access in a system.

All these tools come inbuilt in Kali Linux

5. Online platforms to practice -

For starters, you can signup on some platforms like Hack The Box and Try Hack Me, they have some free as well as paid hackable rooms. They even provide a step by step guide and tutorial to start using the tools used for pen testing.

6. Maintaining the flow -

Research, Research and Research! I can't emphasize more over this point. The more you read and research the more you come across amazing hacking techniques and walkthroughs, get to know about new vulnerabilities discovered and their patching technique. The never ending process of unraveling a new exploit and sewing the old one, you have to keep learning new techniques and try improvising them.

To take your skills to the next level you can go for some certifications such as OSCP and CEH by EC-Counsel.

7. Conclusion -

Above all this is the most important thing which has to be in you and that is the motivation and eagerness to learn and explore more about this field. This is one the most ever changing fields of computer Universe and one needs to keep himself updated about all the new tools and exploits available.