DEV Community: Golam Mostafa

I state "You will love it - React Query".

Golam Mostafa — Wed, 08 Oct 2025 04:29:29 +0000

🚀 ভালো লাগার আরও একটি utility: React Query

React Query use করলে API fetch, cache, update সব সহজ। RTK Query ঠিক আছে, কিন্তু complex scenario-এ clumsy হতে পারে।

👉 API Fetching সহজ

const { data, isLoading, error } = useQuery(['todos'], fetchTodos)

শুধু useQuery বা useMutation call করতে হবে।
Background-এ fetch, retry, error handling auto।

RTK Query: Multiple queries বা complex retry verbose।

👉 Caching & Stale Data

const { data } = useQuery(['projects', page], fetchProjects, {
  staleTime: 5000,
  keepPreviousData: true
})

Flicker কমায়, pagination smooth।

RTK Query: Requires more manual work than React Query.

👉 Updating & Mutations

const mutation = useMutation(updateTodo, {
  onSuccess: () => queryClient.invalidateQueries(['todos'])
})

onSuccess, onError, onSettled দিয়ে cache automatically invalidate।

RTK Query: Tag system use করতে হয়, একটু verbose।

👉 Offline / Window Focus Handling

refetchOnWindowFocus → user active করলে fresh data।
Retry automatically network fail হলে।

RTK Query: Manual setup দরকার।

👉 File Uploads & Non-serializable Data

React Query supports File, FormData direct use।

RTK Query: ❌ serializable restriction → tricky। Cache Redux store-এ → File, FormData, Date support নেই।

👉 Multiple Queries & Dependent Queries

const { data: user } = useQuery(['user', userId], getUser)
const { data: projects } = useQuery(
  ['projects', user?.id],
  getProjects,
  { enabled: !!user?.id }
)

একসাথে multiple query handle করা সহজ।

RTK Query: conditional skip করতে হয় → কম intuitive।

👉 API Error Handling & Conditional Invalidate

useMutation(updateData, {
  onSuccess: () => queryClient.invalidateQueries(['todos']),
  onSettled: () => queryClient.invalidateQueries(['todos']) // success/error উভয়েই
})

Default: error হলে invalidate হয় না। চাইলে onSettled use করে success বা error উভয়েই invalidate করা যায়।

RTK Query: conditional invalidate করতে extra code লাগে → beginner-unfriendly।

👉 Optimistic Updates

useMutation(updateTodo, {
  onMutate: async (newTodo) => {
    await queryClient.cancelQueries(['todos'])
    const previousTodos = queryClient.getQueryData(['todos'])
    queryClient.setQueryData(['todos'], old => [...old, newTodo])
    return { previousTodos }
  },
  onError: (err, newTodo, context) => {
    queryClient.setQueryData(['todos'], context.previousTodos)
  }
})

UI instantly update, error হলে rollback।

RTK Query: onQueryStarted + updateQueryData → more complex।

👉 Infinite Queries (Infinite Scroll)

const { data, fetchNextPage, hasNextPage } = useInfiniteQuery(
  ['projects'],
  fetchProjects,
  { getNextPageParam: (lastPage) => lastPage.nextCursor }
)

Next page automatic track।

RTK Query: Manual setup বা complex pattern।

⭐ Awesome Devtools

React Query devtools দিয়ে সব status (fetching, stale, active, etc.) দেখতে পারবেন। Debugging অনেক সহজ।

💡 Conclusion:
I have used both RTK and React Query. But find that React Query is much simpler than RTK 😊.

DOCUMENTATION

Web LLM attacks

Golam Mostafa — Sat, 15 Feb 2025 13:57:51 +0000

Let's explore how to secure your LLM applications using JavaScript, with simple examples and clear explanations.

1. Understanding the Attack Surface

When you build an app with LLMs, you typically have this setup:

Users send inputs to your app
Your app talks to the LLM service (like OpenAI or Claude)
The LLM connects to other parts like databases and files

Common Attack Vectors:

Direct API Manipulation

// ❌ Vulnerable Implementation
function processUserRequest(userInput) {
    const llmResponse = await llm.generate(userInput);
    const filename = llmResponse.filename;
    return fs.readFileSync(filename); // Dangerous!
}

// ✅ Secure Implementation
function processUserRequest(userInput) {
    const llmResponse = await llm.generate(userInput);
    const filename = llmResponse.filename;

    // Check if path is safe
    if (!isSafePath(filename)) {
        throw new Error("Invalid file path");
    }

    // Use path sanitization
    const safePath = sanitizePath(filename);
    return fs.readFileSync(safePath);
}

Hidden Prompt Injection

// Example of checking for hidden content
function checkForHiddenContent(userInput) {
    // Remove HTML tags
    const strippedInput = userInput.replace(/<[^>]*>/g, '');

    // Check for suspicious keywords
    const suspiciousPatterns = [
        'ignore previous',
        'system prompt',
        'you are now'
    ];

    return !suspiciousPatterns.some(pattern => 
        strippedInput.toLowerCase().includes(pattern)
    );
}

2. Security Best Practices

2.1 Secure API Wrapper

class SecureAPIWrapper {
    constructor(llmClient) {
        this.llm = llmClient;
        this.allowedApis = new Set(['getPublicData', 'processText']);
        this.rateLimiter = new RateLimiter();
        this.logger = new AuditLogger();
    }

    async executeApiCall(apiName, params) {
        // Check if API is allowed
        if (!this.allowedApis.has(apiName)) {
            throw new Error("Unauthorized API access");
        }

        // Clean parameters
        const cleanParams = this.sanitizeParams(params);

        // Check rate limit
        if (!await this.rateLimiter.canMakeRequest()) {
            throw new Error("Rate limit exceeded");
        }

        // Log the call
        this.logger.logApiCall(apiName, cleanParams);

        // Make the actual API call
        return await this.llm.callApi(apiName, cleanParams);
    }
}

2.2 Protecting Sensitive Data

class DataProtector {
    constructor() {
        this.patterns = {
            email: /\b[\w\.-]+@[\w\.-]+\.\w{2,}\b/,
            ssn: /\d{3}-\d{2}-\d{4}/,
            creditCard: /\d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4}/
        };
    }

    sanitizeText(text) {
        let cleanText = text;

        // Replace each pattern with [REDACTED]
        Object.entries(this.patterns).forEach(([type, pattern]) => {
            cleanText = cleanText.replace(pattern, `[REDACTED ${type}]`);
        });

        return cleanText;
    }
}

// Usage example
const protector = new DataProtector();
const userInput = "My email is user@example.com and CC: 1234-5678-9012-3456";
console.log(protector.sanitizeText(userInput));
// Output: "My email is [REDACTED email] and CC: [REDACTED creditCard]"

3. Security Monitoring

class SecurityMonitor {
    constructor() {
        this.events = [];
    }

    logEvent(eventType, severity, details) {
        const event = {
            timestamp: new Date(),
            type: eventType,
            severity,
            details,
        };

        this.events.push(event);

        // If high severity, send alert
        if (severity === 'high') {
            this.sendAlert(event);
        }
    }

    async sendAlert(event) {
        // Send to your monitoring service
        await fetch('your-monitoring-endpoint', {
            method: 'POST',
            body: JSON.stringify(event)
        });
    }
}

4. Security Checklist

✅ Always implement these safety measures:

Input Validation
- Validate all user inputs
- Set maximum length limits
- Check for malicious patterns
API Security
- Use secure API keys
- Implement rate limiting
- Log all API calls
Data Protection
- Remove sensitive information
- Encrypt data in transit
- Regularly check security logs

Example Implementation

class SecureLLMApp {
    constructor() {
        this.apiWrapper = new SecureAPIWrapper(llmClient);
        this.dataProtector = new DataProtector();
        this.monitor = new SecurityMonitor();
    }

    async processUserRequest(userInput) {
        try {
            // 1. Validate input
            if (!checkForHiddenContent(userInput)) {
                throw new Error("Suspicious content detected");
            }

            // 2. Sanitize sensitive data
            const cleanInput = this.dataProtector.sanitizeText(userInput);

            // 3. Make API call
            const response = await this.apiWrapper.executeApiCall(
                'processText', 
                { text: cleanInput }
            );

            // 4. Log success
            this.monitor.logEvent('request_processed', 'info', {
                inputLength: userInput.length
            });

            return response;

        } catch (error) {
            // Log any errors
            this.monitor.logEvent('request_failed', 'high', {
                error: error.message
            });
            throw error;
        }
    }
}

Remember

Always validate user inputs
Keep your security measures updated
Monitor for unusual behavior
Regularly test your security setup

Acknowledgment: This document references information from PortSwigger Web Security.

Prevent Authentication Security Issues

Golam Mostafa — Fri, 14 Feb 2025 17:55:23 +0000

Use Strong Passwords
- Enforce strong password policies. Use a password strength checker like zxcvbn to guide users in creating secure passwords.
- Example: If a user tries "password123," the system should suggest using "MyStr0ng#Pass2025" instead.
Prevent Username Enumeration
- Return the same error message and HTTP status code for invalid usernames and passwords to avoid revealing whether a username exists.
- Example: Show "Invalid credentials" for both wrong usernames and passwords, without confirming which part was incorrect.
Implement Account Locking
- Temporarily lock accounts after a certain number of failed login attempts.
- Example: Lock an account for 10 minutes after 5 wrong attempts to prevent targeted brute-forcing.
Limit Login Attempts (Rate Limiting)
- Limit login attempts per IP address and block suspicious behavior.
- Example: Allow 5 attempts per minute per IP. Block further attempts for 15 minutes if the limit is exceeded.
Add CAPTCHA for Extra Protection
- Require users to complete a CAPTCHA after several failed login attempts.
- Example: After 3 failed logins, show a CAPTCHA like "Click all the images with traffic lights."
Implement Multi-Factor Authentication (MFA)
- Use app-based or hardware-based MFA instead of SMS.
- Example: After entering a password, require a 6-digit code from Google Authenticator or a similar app.
Secure Password Reset
- Use a time-limited, unique token for password reset links.
- Example: Send an email with a link that expires in 15 minutes. Ensure the link can only be used once.
Avoid SMS-Based MFA
- SMS 2FA can be bypassed via SIM-swapping attacks. Use app-based authentication instead.
- Example: Encourage users to set up an authenticator app for 2FA instead of relying on SMS codes.
Protect Additional Authentication Functions
- Secure features like account registration, password recovery, and password changes.
- Example: Require users to verify their email before changing their password.
Prevent Brute-Force Attacks on Multiple Accounts
- Limit the number of login attempts across all usernames using shortlists of passwords.
- Example: If an attacker tries common passwords like "123456" or "qwerty" across accounts, block them after 5 attempts.
Triple-Check Verification Logic
- Regularly audit login and authentication logic to prevent bypass vulnerabilities.
- Example: Ensure the system verifies both the username and password properly and doesn't skip steps due to flawed code.
Don’t Rely on Users for Security
- Enforce secure practices like strong passwords and MFA automatically.
- Example: Block weak passwords like "Password123" and require a unique, strong password.
Implement Robust Brute-Force Protections
- Require CAPTCHA or other verification methods after multiple failed attempts.
- Example: After 5 failed attempts from the same IP, show a CAPTCHA and notify the account owner.

Please feel free to add more :).

Acknowledgment: This document references information from PortSwigger Web Security

SQL Injection (SQLi)

Golam Mostafa — Thu, 26 Dec 2024 18:04:21 +0000

SQL Injection (SQLi) is a trick used by hackers to mess with websites. They add fake input into forms or URLs to access or steal data from a website's database.

How to Spot SQL Injection

Single Quotes (''): Enter a single quote (') in a form or URL. If you see an error, the website might be vulnerable.
Always True Condition: Try entering OR 1=1 (always true) or OR 1=2 (always false) and see if the site behaves differently.
Delays: Use commands like SLEEP(5) to see if the page takes longer to load.
External Calls: Test if your input makes the site connect to another server.

Example: Finding Hidden Items

For example:

https://example.com/products?category=Gifts

The site might use this command to get the products:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1;

This hides unreleased items (released = 1 shows only ready products).

What Hackers Do:

They can change the URL to:

https://example.com/products?category=Gifts'--

This changes the database query to:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1;

The -- ignores the rest of the query, showing all products, even hidden ones.

Example: Show Everything

Hackers can show all items, even unknown categories, by using:

https://example.com/products?category=Gifts'+OR+1=1--

This creates a query like:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1;

Since 1=1 is always true, the database returns everything.

Example: Hacking a Login

Think of a login form that checks username and password. Normally, it might do this:

SELECT * FROM users WHERE username = 'user' AND password = 'pass';

A hacker can enter this as the username:

user' OR '1'='1

The query becomes:

SELECT * FROM users WHERE username = 'user' OR '1'='1' AND password = 'pass';

Since 1=1 is always true, the hacker logs in without a password.

Be Careful

Testing SQLi is risky. Commands like OR 1=1 might delete or change important data if misused. Always handle websites and data responsibly.

To stay safe, websites must properly check user inputs and use secure coding practices.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

OWASP Top 10

Golam Mostafa — Mon, 16 Dec 2024 13:11:34 +0000

The OWASP Top 10 is a list of the most common and dangerous security risks for web applications. If you're building a website or an app, you need to know these risks to keep your system safe.

1. Broken Access Control (A01)

This happens when users can access things they shouldn’t, like admin pages or other users' data.

Example:

Imagine a normal user visiting:

https://example.com/admin

If they see admin pages, that’s broken access control.

How to Fix:

Use Authorization to check who can access what.
Add Role-Based Access Control (RBAC): e.g., Admin, User, Guest.
Use Secure Cookies.
Always validate inputs on the backend.

2. Cryptographic Failures (A02)

This happens when sensitive data like passwords or credit card info isn’t protected properly.

Example:

Storing passwords as plain text:

Password: mypassword123

If a hacker gets this, it’s game over.

How to Fix:

Use strong encryption for passwords like bcrypt.
Use HTTPS/TLS to secure data during transfer.
Example:

   const bcrypt = require('bcrypt');
   const hashedPassword = await bcrypt.hash("mypassword123", 10);
   console.log(hashedPassword);

3. Injection (A03)

This happens when a hacker sends harmful code (like SQL or scripts) into your application.

Example:

If your website takes input like this:

SELECT * FROM users WHERE id = 1;

A hacker could type:

1; DROP TABLE users;

How to Fix:

Validate and sanitize all inputs.
Use parameterized queries. Example in Node.js:

   const query = "SELECT * FROM users WHERE id = ?";
   db.query(query, [userId]);

4. Insecure Design (A04)

This happens when your system is not designed securely in the first place.

Example:

An app that allows weak passwords like "1234" is insecure by design.

How to Fix:

Use OWASP resources to follow secure design patterns.
Perform regular security reviews.

5. Security Misconfiguration (A05)

This happens when your app has default settings or unnecessary features enabled.

Example:

Leaving the default username and password:

admin / admin123

How to Fix:

Keep systems up-to-date.
Remove unused features and accounts.
Use safe error messages like "Invalid credentials" instead of exposing details.

6. Vulnerable and Outdated Components (A06)

This happens when your app uses old software or libraries with known security issues.

Example:

Using an old version of a library like express that has vulnerabilities.

How to Fix:

Update your libraries and software regularly.
Use security tools like npm audit to check for vulnerabilities.

7. Identification and Authentication Failures (A07)

This happens when attackers can bypass login systems.

Example:

Allowing weak passwords like "password123" or not locking accounts after failed logins.

How to Fix:

Use strong authentication like JWT tokens.
Store passwords securely.
Protect against brute-force attacks.
Example: Lock an account after 5 failed attempts.

8. Software and Data Integrity Failures (A08)

This happens when your software or data is tampered with during updates or transfers.

Example:

A hacker changes your app update to include malware.

How to Fix:

Always verify updates with digital signatures.
Use trusted sources for libraries.
Keep everything up-to-date.

9. Security Logging and Monitoring Failures (A09)

This happens when you don’t track suspicious activities on your app.

Example:

If someone tries to log in 100 times and fails, and you don’t log or monitor it, you might miss a brute-force attack.

How to Fix:

Add proper logging and monitoring.
Use tools like Winston or ELK Stack.
Example: Log failed login attempts:

   console.log(`Failed login attempt for user: ${username}`);

10. Server-Side Request Forgery (SSRF) (A10)

This happens when an attacker tricks your server into making a request to an internal system.

Example:

A hacker sends:

http://localhost/admin

If your app fetches this URL, it exposes internal data.

How to Fix:

Validate all URLs before making requests.
Don’t allow users to directly input URLs.
Example: Use a whitelist of trusted URLs.

Acknowledgment: This document references information from OWASP, Foyjul Karim and ChatGPT.

File Upload Vulnerabilities

Golam Mostafa — Sat, 23 Nov 2024 17:25:53 +0000

What Are File Upload Vulnerabilities?

File upload vulnerabilities occur when a server lets users upload files without proper checks. Attackers can exploit this to upload harmful files, like scripts, instead of safe ones, like images. Sometimes, just uploading the file causes damage; other times, attackers trigger the file to execute with a request.

How Do These Vulnerabilities Happen?

Even when protections exist, flaws in implementation can still allow attacks. Common issues include:

Blocking some dangerous file types but missing others.
Relying on file properties that attackers can fake using tools.
Inconsistent validation across the website.

These small mistakes give attackers ways to bypass security measures.

Exploiting Flawed File Upload Validation

Attackers often exploit weak validation to upload harmful scripts, like web shells. For example, a PHP script like this reads secret files:

<?php echo file_get_contents('secret.txt'); ?>

Or, a script like this can run system commands:

<?php echo system($_GET['cmd']); ?>

Attackers can send:

GET /hack.php?cmd=whoami

This shows the server's identity and gives attackers control.

Flawed File Type Validation

Some servers validate file uploads by checking the Content-Type header for expected MIME types like image/jpeg. However, if the server trusts this header without checking the file’s actual contents, attackers can easily bypass the validation.

For example, an image upload form may send this request:

POST /images HTTP/1.1  
Host: example.com  
Content-Type: multipart/form-data  

--boundary  
Content-Disposition: form-data; name="image"; filename="example.jpg"  
Content-Type: image/jpeg  

[binary data]  
--boundary--

If the server only verifies the Content-Type value, attackers can fake this using tools like Burp Repeater and upload malicious files disguised as images.

Protecting Against File Upload Vulnerabilities

To prevent these attacks:

Verify file content matches the declared type.
Store uploaded files in non-executable directories.
Use strict whitelists for allowed file types.
Scan files for malicious content.

Learn More: Watch the Tutorial

Acknowledgment: This post is inspired by insights from PortSwigger Web Security and ChatGPT.

SSRF Attacks: The Silent Threat Hiding in Your Server

Golam Mostafa — Sat, 16 Nov 2024 19:24:26 +0000

What is SSRF (Server-Side Request Forgery)?

Server-Side Request Forgery (SSRF) is a web vulnerability where attackers trick a server into making unauthorized requests to internal or external systems.

How Does It Work?

An attacker sends a malicious URL in a request that the server processes as legitimate. The server then makes the request on the attacker’s behalf.

Example:

A shopping app checks stock by making a backend API request:

POST /product/stock  
stockApi=http://stock.server.com/check?productId=6&storeId=1

An attacker modifies the URL to point to the server's admin page:

POST /product/stock  
stockApi=http://localhost/admin

The server fetches and returns restricted admin data, bypassing access controls.

Why Does This Happen?

Access Control Gaps: Checks are skipped for local requests.
Recovery Features: Admin access is granted to local users without authentication.
Hidden Interfaces: Admin tools on separate ports trust local machine requests.

Protect Against SSRF

Validate and sanitize input URLs.
Use URL whitelists.
Restrict internal service access.

SSRF can be critical, but good design and input validation can prevent it.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Weaknesses in Two-Factor Authentication

Golam Mostafa — Tue, 12 Nov 2024 19:54:40 +0000

Two-factor authentication (2FA) is meant to add extra security by asking for a password and then a code. However, some websites don’t fully enforce the second step.

For example, imagine logging in to a site that asks for your password, then moves to a page asking for a code. If the website considers you "logged in" after just the password, you might be able to skip the code and access secure pages.

To check if this flaw exists:

Enter your password.
When asked for the code, try going directly to a secure page.

If it works, the 2FA isn’t doing its job, and hackers could exploit this to bypass security.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Authentication vs. Authorization: Key Differences and Security Risks Explained

Golam Mostafa — Sat, 09 Nov 2024 15:14:21 +0000

When accessing online accounts or secure areas, two key security concepts play a role: Authentication and Authorization. Both are essential, but they serve different purposes. Let’s explore the differences with clear examples and highlight security risks, such as brute-force attacks and username enumeration, that threaten them.

What is Authentication?

Authentication is all about verifying identity. In simple terms, it’s how a system checks if you are really who you claim to be.

Example: Imagine Carlos tries logging into a website with the username “Carlos123.” Authentication is the process that checks if Carlos is indeed the person who created that account by verifying his password.

What is Authorization?

Authorization comes after authentication. Once the system knows who you are, authorization decides what you are allowed to do.

Example: After Carlos logs in, his account permissions determine what he can access. For instance, he might be authorized to view personal data but not to delete another user’s account.

Brute-Force Attacks

A brute-force attack is when an attacker tries different usernames and passwords repeatedly to gain access. Often, this is done with automated tools that test a vast number of login combinations very quickly.

How Brute-Forcing Works

Guessing Passwords: Attackers use common or predictable passwords, such as “Password123” or “Admin2023!” They might even try patterns based on the target, like adding “123” or “!” to simple words (e.g., “mypassword1!”).
Automated Tools: Tools like Hydra or Burp Suite make it easier to brute-force logins at high speed, increasing the chances of guessing correctly.

Example: Carlos uses “Carlos2023” as a password. An attacker using a brute-force tool could guess this password if it tries combinations based on his name.

Brute-Forcing Usernames

Usernames often follow patterns, making them easier to guess.

Example: Many companies use email addresses as usernames, like “firstname.lastname@company.com.” High-level accounts often use simple names like “admin” or “administrator,” which attackers know to try first.

Checking for Publicly Visible Usernames

Attackers can look for usernames on public pages. Sometimes websites unintentionally reveal usernames through profile links or in HTTP responses, providing attackers with information for brute-force attempts.

Brute-Forcing Passwords

While strong passwords are harder to guess, attackers know common tricks users apply to meet password requirements. For example, users might change “mypassword” to “Mypassword1!” to meet complexity rules. Attackers exploit these patterns by targeting predictable variations.

Example: If the original password “mypassword” is too weak, the user might create “Mypassword1!”. Attackers know these patterns, making brute-force attacks more efficient.

Username Enumeration

Username enumeration allows attackers to discover valid usernames by observing system responses.

How It Works

When entering a correct username with a wrong password, some sites give a different error message than for an incorrect username. This helps attackers confirm if a username exists, reducing the work needed to brute-force the password.

Example: If Carlos enters “Carlos123” with an incorrect password, the site might say, “Incorrect password,” rather than “Username not found.” This confirms to an attacker that “Carlos123” is a valid username.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Horizontal privilege escalation

Golam Mostafa — Mon, 28 Oct 2024 05:54:24 +0000

What is Horizontal Privilege Escalation?

Horizontal privilege escalation is when a user can see another user’s data that they shouldn’t have access to. For example, if you can view your account but change the URL to see someone else’s account, that’s a security problem called Insecure Direct Object Reference (IDOR).

Example of IDOR

Say your account page has this URL:

https://example.com/myaccount?id=123

If someone changes id=123 to a different number, they could accidentally see another user’s account. This happens because the website isn’t protecting users’ data properly.

How Some Sites Try to Prevent It

Websites sometimes use special codes, like long GUIDs instead of numbers, to make guessing harder. But even these codes can show up in other parts of the website, like messages or comments, where they can be misused.

Horizontal privilege escalation exposes private data and shows why websites need strong security controls to protect each user’s information.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Unprotected Functionality

Golam Mostafa — Tue, 22 Oct 2024 17:44:24 +0000

Title: Vertical Privilege Escalation

Vertical privilege escalation happens when regular users access admin-only areas due to weak access control and vice versa.

Example:

A user types example.com/admin. If there’s no restriction, they can access the admin panel without permission.

Key Points:

Direct URL Access: Typing sensitive URLs like /admin can bypass security.
robots.txt Exposure: Can accidentally reveal admin URLs.
Brute Force: Attackers guess URLs to find admin pages.

Dangers:

Unauthorized changes, data access, or system takeover.

Prevention:

Use strict role-based access controls.
Always secure sensitive areas, don’t rely on hidden URLs.

Title: The Flaw of Security by Obscurity

Hiding sensitive functionality behind a hard-to-guess URL isn’t true protection. This is known as "security by obscurity."

Example:

An admin URL like insecure-website.com/administrator-panel-yb556 might seem secure because it's not guessable. But if the URL is in the JavaScript, any user can inspect the code and find it.

Key Points:

Hidden URLs aren’t real security.
Visible in Code: Scripts or code can leak sensitive URLs to regular users.

Solution:

Always enforce strict access control; never rely on hiding URLs.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Securing File Paths: Preventing Directory Traversal Attacks

Golam Mostafa — Mon, 21 Oct 2024 14:15:13 +0000

Improper handling of file paths can lead to security vulnerabilities known as directory traversal attacks. These vulnerabilities allow an attacker to access arbitrary files on the server.

What is a Directory Traversal Attack?

A directory traversal attack occurs when an attacker manipulates file paths to access files outside the intended directory. For instance, if an application uses a user-provided file path without validation, an attacker could use a path like ../../etc/passwd to access sensitive files on the server.

Example of a Directory Traversal Attack:

Vulnerable Code:

const filePath = `public/uploads/${req.params.fileName}`;

Imagine you have a file download function that allows users to download files by providing an id. The application might construct the file path directly from the user input.

Malicious Input:

/public/uploads/../../secret.txt

Here an attacker could provide a malicious input like ../../secret.txt, leading to an unintended file access.

Consequences:

If the application does not validate this input, it could expose sensitive files, such as configuration files or user data, to the attacker.

Example of preventing such kind of attacks

import path from 'path';
import fs from 'fs/promises';
import { RequestHandler, NextFunction } from 'express';

// Point: 1
const BASE_DIRECTORY = path.resolve(__dirname, 'public/uploads');

export const downloadAttachment: RequestHandler = async (req, res, next: NextFunction) => {
    // Point: 2
    const { fileName } = req.params; 

    // Point: 3
    const filePath = path.join(BASE_DIRECTORY, fileName);
    const resolvedPath = path.resolve(filePath);

    // Point: 4
    if (!resolvedPath.startsWith(BASE_DIRECTORY)) {
        return res.status(400).json({ message: "Invalid file path" });
    }

    try {
        // Point: 5
        await fs.access(resolvedPath);

        // Point: 6
        res.download(resolvedPath, path.basename(fileName), (err) => {
            if (err) {
                return next(err);
            }
        });
    } catch {
        // Point: 7
        return res.status(404).json({ message: "File not found" });
    }
};

Key Points Explained:

Base Directory Definition: Establishes a fixed directory for file uploads to restrict access.
Extracting File Name: Retrieves the requested file name from the URL parameters.
File Path Construction: Combines the base directory with the requested file name to create a full path.
Path Validation: Ensures that the resolved file path is within the designated base directory to prevent unauthorized access.
File Existence Check: Asynchronously checks if the file exists at the constructed path.
File Download Handling: Initiates the file download and handles any errors that may occur during the process.
Error Handling for Missing Files: Sends a 404 response if the requested file does not exist.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.