DEV Community: Alan Norman

How to Lock Down Your Web App: Security Tips for Authentication – Alan Norman, Part 2

Alan Norman — Wed, 18 Sep 2024 13:18:20 +0000

Alright, let’s quickly recap what we covered in Part 1: User-Agent Validation, CORS, Rate Limiting, and CSP. Now, we’re diving a bit deeper into user authentication.

1. Kicking Off with CAPTCHA

Let’s start with something simple yet effective — CAPTCHA. Companies use different solutions like Google reCAPTCHA v2, v3, Cloudflare, or even roll their own.

We’ll focus on Google reCAPTCHA v3. So, what’s it all about? Unlike its older versions, reCAPTCHA v3 doesn’t throw annoying puzzles at users. Instead, it works in the background, scoring each visitor based on their behavior to figure out if they’re legit or a bot.

Implementing reCAPTCHA v3

Frontend: Pick your poison — whatever library fits your stack. Since I’m a React fan, I roll with @react-google-recaptcha. First, grab your Site Key and Secret Key by setting up reCAPTCHA here.

I won’t bog you down with frontend details, as there are tons of ways to implement it.

Backend: Here’s where things get straightforward:

app.post('/api/form', async (req, res) => { 
  const { token } = req.body; 
  try { 
    const response = await axios.post(`https://www.google.com/recaptcha/api/siteverify?secret=${RECAPTCHA_SECRET_KEY}&response=${token}`); 
    const { success, score } = response.data;

    if (success && score > 0.5) { 
      // Token is valid, and score is good 
      res.json({ message: 'Success' }); 
    } else { 
      // Token is invalid or score is too low 
      res.status(400).json({ message: 'Failed reCAPTCHA' }); 
    } 
  } catch (error) { 
    console.error(error);
    res.status(500).json({ message: 'Server error' });
  } 
});

Pro Tip: Be mindful of the response message. Don’t spill the beans on why the request failed — keep those error details vague to avoid giving attackers any clues.

2. Brute Force

Your system should recognize and prevent numerous failed login attempts from a single user. If someone is making repeated unsuccessful attempts, they’re likely trying to brute-force their way in.

Here’s how you can handle it:

Install and Configure Redis: Use Redis (a fast in-memory store) to track failed login attempts.
Implement Login Attempt Tracking:

Example of Controller:

const Login = async (req, res) => {
  const { email, password } = req.body;
  try {
    const token = await LoginModule.login(email, password); // Try to log in

    // Your logic here
  } catch (e) {
    // Handle login error
    RedisService.setUserAttempts(`attempts_${email}`, /* increment and set TTL */);
  }
}

Imagine you’ve got a LoginModule with a login method that does its thing and gives you a token if the login’s a success.

Meanwhile, RedisService has a setUserAttempts method that checks how many times a user’s tried logging in and adds one to the count.

Example of Middleware:

const USER_ATTEMPTS = 3; // Store this in env variables or system configuration
const UserLoginAttempts = (req, res, next) => {
  const { body: { email } } = req;
  const userAttempts = RedisService.getUserAttempts(`attempts_${email}`);
  if (userAttempts >= USER_ATTEMPTS) {
    return res.status(403).send('Too many attempts. Try again in 2 minutes.');
  }
  next();
}

Pro Tip: Make sure your Redis setup is fast and reliable. This is essential for managing login attempts effectively. Storing your login attempt configurations in Redis helps avoid additional database requests, which can slow down response times.

Alright, that’s a wrap for this step. Adding CAPTCHA and blocking brute force attacks will seriously beef up your app’s security.

Catch you in the next chapter where we’ll dive into Tokens and Cookies!

Security Tips, API Edition: How to Lock Down Your Web App — Part 1 by Alan Norman.

Alan Norman — Sat, 07 Sep 2024 13:29:13 +0000

Hey folks, Alan Norman here! I’m all about that security life at JFrog, and today I’m dropping some tips on web app security. We’ll focus on the basics to get you started and keep your app tight.

I’m using Node.js (Express) for the examples, so let's dive in!

1) User-Agent Validation

First up, spot shady requests by adding User-Agent validation.

const allowedUserAgents = ['Mozilla/5.0'];
app.use((req, res, next) => {
  const userAgent = req.get('User-Agent');
  const isAllowed = allowedUserAgents.some(allowedAgent => userAgent.includes(allowedAgent));
  if (!isAllowed) {
    return res.status(403).send('Forbidden: Your device was blocked permanently for making requests.');
  }
  next();
});

Pro Tip: Don’t give away too much in your error messages—keep hackers guessing. A simple "Forbidden" keeps them in the dark.

2) CORS

Next, we’ve got CORS. It’s good for stopping unwanted cross-origin requests, but don’t expect miracles.

const corsOptions = {
  origin: ['https://your.app'],
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
};
app.use(cors(corsOptions));

Pro Tip: Never use '*' in production! It’s way too risky, and anyone with Postman can break through.

3) Rate Limiting

Let’s slap some limits on requests to block out those pesky bots.

const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
  windowMs: 10 * 60 * 1000,
  max: 100,
  message: 'Too many requests from this IP, please try again later.',
});
app.use(limiter);

Pro Tip: Customize the rate limit based on your app’s traffic. Watch that error message though—don’t give the hackers a clue!

4) CSP

Why CSP? It’s your line of defense against XSS attacks. Decide what gets loaded and block the rest.

const helmet = require('helmet');
app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'"],
      imgSrc: ["'self'"],
    },
  })
);

Need third-party stuff? No problem:

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "https://cdnjs.cloudflare.com"],
      styleSrc: ["'self'", "https://fonts.googleapis.com"],
      imgSrc: ["'self'", "https://images.example.com"],
    },
  })
);

Wanna use inline scripts? Secure them with a nonce:

const crypto = require('crypto');
app.use((req, res, next) => {
  res.locals.nonce = crypto.randomBytes(16).toString('hex');
  next();
});

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.nonce}'`],
    },
  })
);

On the frontend, use that nonce:

<script nonce="${nonce}" src="/path/to/your/bundle.js"></script>

Last bit—lock down those API keys. Make sure they’re restricted by IP. Don’t let them roam free, or you’ll be swimming in security issues.

That’s it for Part 1! You’ve just leveled up your API security game. Next, we’ll talk Brute Force attacks and Captcha. Stay tuned!

Decimal numbers with trailing zeros and handling raw body data in Node.js

Alan Norman — Tue, 03 Sep 2024 18:31:33 +0000

By Alan Norman

So, a few years back, I ran into this annoying issue with decimal numbers that had trailing zeros in Node.js. It was one of those sneaky problems that ate up almost an entire day, and I'm sharing my story in the hopes that it saves you some headache if you ever stumble upon the same tiny but frustrating problem.

The Problem: Decimal Numbers with .00 Losing Their Trailing Zeros

During one of my projects, where I was rolling as the Solution Lead, our team was working on a service that hooked up with a bunch of financial platforms. These platforms kept hitting us with JSON payloads via POST requests, and our Node.js app, running on the Express framework, was on duty to handle them. We used app.use(express.json()) to parse the incoming JSON data.

Everything was smooth sailing until one of our partners started sending JSON with an “amount” key that had those pesky trailing zeros, like “amount”: “10.00”. The problem? JavaScript doesn’t give a hoot about the difference between 10.00 and 10 when converting strings to numbers. This caused a big mess because we needed to generate a digital signature from the raw request body. If the signature was made from “amount”: “10” instead of “amount”: “10.00”, boom—mismatch city.

The Challenge: Keeping the Original JSON Format Intact

Now, app.use(express.json()) was doing its job too well, automatically parsing the JSON and stripping away those precious zeros, leaving us with no way to grab the raw JSON string. We couldn’t just rip out app.use(express.json()) because that would mean rewriting a ton of code and breaking all the SOLID principles we were holding dear.

Our quick and dirty fix? We started tweaking the amounts by adding small values, turning 10.00 into 10.01. It gave us some breathing room to figure things out, but come on, this was never gonna fly long-term—especially in a financial setup where accuracy is everything.

The Fix: Using the verify Option in express.json()

After digging around a bit, I found out the fix was way simpler than I expected. Turns out, Express has this neat verify option in the express.json() method that lets you grab the raw request body before it gets all parsed into JSON.

Here’s how you can make it work:

app.use(express.json({
  verify: (req, _, buf) => req.rawBody = Buffer.from(buf).toString()
}));

The verify function kicks in before the body is turned into JSON. This way, you can stash the raw body as a string, making sure that “amount”: “10.00” stays just the way it was. Then, you can grab both the parsed JSON and the raw string in your controllers:

const { body, rawBody } = req;
// body - JSON-parsed output
// rawBody - Original raw string received before parsing

Heads Up: Be Careful When Messing with the req Object

Now, I gotta say, messing with the req object isn’t exactly best practice, but hey, sometimes you gotta do what you gotta do to fit your architecture. The main thing to remember is that you can keep both the raw and parsed versions of the JSON body in one spot.

Looking back, the fix was right there, but under pressure, even seasoned devs can miss the easy stuff. Hopefully, this helps anyone else facing the same kind of hassle. Remember, knowing how your tools really work under the hood can often turn complex problems into simple fixes.

Happy coding, folks!