DEV Community: Aleh Zasypkin

A primer on open-source intelligence for bug bounty hunting in Grafana

Aleh Zasypkin — Tue, 11 Jun 2024 10:18:20 +0000

ℹ️ ANNOUNCEMENT
Before getting to the main topic of this blog post, I’d like to take a moment to share some exciting news (at least for me): Secutils.dev, the product for software engineers and security researchers that I’ve been working on lately, is now generally available!

Preparing the tool for GA is what has been keeping me busy for the last couple of months. I’d encourage you to quickly skim through the video guides to learn what Secutils.dev is capable of today:

Quickly deploy and program webhooks

Track changes in any part of a web application

Easily generate development certificates and keys

Slice and dice content security policies (CSP)

It’s still early days for Secutils.dev, and if you want to know what's coming, check out the roadmap.

Hello!

Today, I’d like to touch on open-source intelligence, or OSINT. According to Wikipedia, open-source intelligence is the collection and analysis of data gathered from open sources (covert sources and publicly available information) to produce actionable intelligence. As you can infer from the definition, OSINT is a vast topic, and the best way to understand such broad topics is through concrete, narrow-scoped practical examples. In this blog post, I’d like to share one of the approaches on how OSINT techniques can be applied to bug bounty hunting for products with publicly hosted code on GitHub, using the awesome open-source project Grafana as an example. Read on!

⚠️ DISCLAIMER
I’m not a security researcher nor a bug bounty hunter myself, but as an application security engineer, I think about these essential participants of the security ecosystem and how they might approach the applications I defend day and night. Therefore, I have some insights to share. Everything in this post is for educational purposes only and is solely targeted at well-intentioned researchers and bug bounty hunters who follow responsible and ethical security issue disclosure rules.

Keep your focus narrow

As a security researcher, there are many ways you can approach an application you want to explore for potential security flaws, from trying to use it in esoteric conditions with tricky input data to thoroughly learning every bit and piece of its source code, hoping to find anything that can knock it out. A seasoned researcher knows that these approaches, unfortunately, can be very time-consuming with a bleak chance of success, so the first step is usually to reduce the scope of research to improve the ratio between time spent and the chance of a successful finding.

If it’s a new project for you, I’d recommend concentrating on understanding the security model used in the application: authentication, authorization, and integration with third-party applications and services. In an ideal scenario, you might find a very rewarding flaw in the security model itself, and in the worst case, you’ll have a better chance to spot when security primitives are used incorrectly in other areas of the application.

On one hand, in a large and complex application like Grafana, the security model is complex to grasp. On the other hand, it’s just as complex for the application developers. To manage this complexity, the application is frequently split into separate well-defined domains with clear owners. If you know these domains and/or owners, you know where to look. GitHub, or the GitHub CODEOWNERS file specifically, is your ally here.

GitHub `CODEOWNERS` file

Let’s take a look at the excerpt from the CODEOWNERS file for the grafana/grafana repository:

…
/.changelog-archive @grafana/grafana-release-guild
/CHANGELOG.md @grafana/grafana-release-guild
/CODE_OF_CONDUCT.md @grafana/grafana-community-support
…
/.github/workflows/update-make-docs.yml @grafana/docs-tooling
/.github/workflows/snyk.yml @grafana/security-team  ----> (1) <----
…
# Cloud middleware
/grafana-mixin/ @grafana/grafana-backend-services-squad

# Grafana authentication and authorization  ----> (2) <----
/pkg/login/ @grafana/identity-access-team
/pkg/services/accesscontrol/ @grafana/identity-access-team
/pkg/services/anonymous/ @grafana/identity-access-team
…

The CODEOWNERS file format is pretty self-describing - every line contains a path in the source code repository and the corresponding owner, either a specific person or an entire team. (1) and (2) are what should have caught your eye - it’s easy to spot at least two security-oriented teams in the file - @grafana/security-team and @grafana/identity-access-team. Great, now we can discern and learn more about the security-related domains these teams own.

Let’s assume you have a slightly better understanding of Grafana’s security model domains now, but what’s next? You might also say that generally security-related code is the one that’s hardest to break, and I’d agree. But there is one exception - newly written code! Pressing deadlines to deliver a new feature that force engineers to speed up the review process, code written by engineers who are new to the security domain, incomplete security fixes, and so on and so forth - these are some of the many reasons why newly written code is so compelling for our purpose. That’s the weakest point you might want to target, and there are two potential vectors here: completely new security domains, e.g., a new SSO integration, or changes in the existing domains, e.g., a bug fix.

Automating change tracking

Of course, you can periodically manually scan the CODEOWNERS file for newly introduced domains or write a dedicated tool for that, but it’s a very laborious task that makes the approach somewhat unsustainable in the long term, especially if you have multiple applications to work with and multiple angles to look at. That’s where tools like Secutils.dev can be helpful! Let me show you how you can use the “Content Tracker” utility to watch the content of the CODEOWNERS file on a specific schedule. I won’t be covering what this utility is for and how to use it. You can spend a couple of minutes and watch a video guide. I’ll just provide tracker settings you can use for your tracker:

Name	[OSINT][Grafana] CODEOWNERS
URL	https://secutils-dev.github.io
Revisions	10
Frequency	Daily
Content extractor	const teams = [ '@grafana/security-team', '@grafana/identity-access-team' ]; return import('https://secutils-dev.github.io/secutils-sandbox/content-extractor-scripts/github-codeowner-file.js') .then((module) => module.run(context, 'grafana', 'grafana', teams));

The important part here is the Content extractor script that is injected into a target page. All this script does is load another external module from the secutils-dev/secutils-sandbox repository and run its run function. The run function expects the GitHub repository owner (grafana), repository name (grafana), and the teams to look for in a CODEOWNERS file. I could put all the logic inside the content extractor script itself, but I prefer to keep the main logic in a separate file to make it easier to debug and iterate on it. Let’s take a look at what I have in the github-codeowner-file.js script (the full source code can be found here):

import type { WebPageContext } from './types';

export async function run(
  context: WebPageContext,
  owner: string,
  repo: string,
  teams: string[],
): Promise<string> {
  const codeOwnersUrl = `https://raw.githubusercontent.com/${owner}/${repo}/main/.github/CODEOWNERS`;
  const lines = (await fetch(codeOwnersUrl).then((response) => response.text())).split('\n') ?? [];

  const rows: Array<Array<string | null | undefined>> = [['Owners', 'Path']];
  for (const line of lines) {
    const [path, owners] = line.split(' ').sort();
    if (owners && teams.some((team) => owners.includes(team))) {
      rows.push([owners, path]);
    }
  }

  const module = await import('markdown-table');
  return module.markdownTable(rows, { align: ['l', 'c'] });
}

The script simply loads the CODEOWNERS file from the specified repository, parses it, and only retains entries that are owned by the specified teams. The result is returned as a nice markdown table. Here’s how the result looks like in Secutils.dev:

So what we have now is a regular job that runs daily, parses the content of the CODEOWNERS file for the specified repository, extracts the areas that are owned by the specified GitHub teams, and notifies you via email if it detects any changes. Now, as soon as a new security domain is introduced, you can go and take a closer look at it right away, no need to waste time on doing it manually on a regular interval. Nice!

Okay, but new domains aren’t introduced that often. What about changes in the existing domains? We can do that too. Let’s tweak our content extractor scripts. The easiest way to know if there were any changes in a specific security domain is to take a look at the recent commits for the specified path. To do that, we can use GitHub’s Get commits API. For public repositories, this API can be used anonymously, but it has a very low request rate limit - just 60 requests per hour, so it’s better to create a GitHub personal access token (PAT) to query this API. Let’s tweak our main content extractor script to provide an access token:


const apiToken = 'github_pat_11xxxxxxxx'; // GitHub personal access token
const teams = [
  '@grafana/security-team',
  '@grafana/identity-access-team'
];
return import('https://secutils-dev.github.io/secutils-sandbox/content-extractor-scripts/github-codeowner-file.js')
    .then((module) => module.run(context, 'grafana', 'grafana', teams, apiToken));

And here are the changes we need to make in the dynamically loaded script:

import type { Endpoints } from '@octokit/types';
import type { WebPageContext } from './types';

export async function run(
  context: WebPageContext,
  owner: string,
  repo: string,
  teams: string[],
  apiToken?: string,
): Promise<string> {
  const codeOwnersUrl = `https://raw.githubusercontent.com/${owner}/${repo}/main/.github/CODEOWNERS`;
  const lines = (await fetch(codeOwnersUrl).then((response) => response.text())).split('\n') ?? [];

  // Use API token if provided to have higher request rate limit.
  // https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28.
  const headers: Record<string, string> = apiToken
    ? { Authorization: `Bearer ${apiToken}`, 'X-GitHub-Api-Version': '2022-11-28' }
    : { 'X-GitHub-Api-Version': '2022-11-28' };

  // Retrieve the latest commit for the specified path.
  const getCommitLink = async (path: string) => {
    try {
      const commits = (await fetch(
        `https://api.github.com/repos/${owner}/${repo}/commits?path=${encodeURIComponent(path)}&per_page=1`,
        { headers },
      ).then((response) => response.json())) as Endpoints['GET /repos/{owner}/{repo}/commits']['response']['data'];
      if (commits.length === 0) {
        return 'N/A (no commits found)';
      }
      const topCommit = commits[0];
      const commitLabel =
        topCommit.commit.author?.name && topCommit.commit.author?.date
          ? `${topCommit.commit.author.name} on ${topCommit.commit.author.date}`
          : topCommit.sha.slice(6);
      return `[${commitLabel}](${topCommit.html_url})`;
    } catch (err) {
      return `N/A (${(err as Error).message ?? 'unknown error'})`;
    }
  };

  const rows: Array<Array<string | null | undefined>> = [['Owners', 'Path', 'Last commit']];
  for (const line of lines) {
    const [path, owners] = line.split(' ').sort();
    if (owners && teams.some((team) => owners.includes(team))) {
      rows.push([owners, path, await getCommitLink(path)]);
    }
  }

  const module = await import('markdown-table');
  return module.markdownTable(rows, { align: ['l', 'c'] });
}

The change here is that we are now adding a third column to our markdown table, which we fill with the latest commit information returned from the getCommitLink function invoked with the path extracted from the CODEOWNERS file. Easy! Here’s how the result looks:

Now, when a new commit is detected in any security domain, you’ll get an email notification. Then, you can go to Secutils.dev to see what has changed exactly with the Diff feature and click on the commit link to learn more about the specific changes. Great, isn’t it?

But wait, there's more

Tracking changes in the CODEOWNERS file and security-related domains is just the tip of the open-source intelligence iceberg. If you want to fully embrace its principles, you can go a few steps further since the commit authors can give you a better idea about the composition of the security teams in a particular organization, which isn’t publicly available information. What can you do with this new data? Well, quite a lot.

For example, the majority of security issues are found outside the security domains, so it’s hard to recognize security fixes automatically. But there is a high chance that some members of the security teams can be tagged for review or advice on the pull requests with those fixes. So you might want to take a closer look at the pull requests for the domains unrelated to security if security folks are involved in one way or another, assuming you know who these security folks are 😬.

The fun part of open-source intelligence is that it doesn’t limit you to information sources as long as they are public. Social networks, such as LinkedIn, are invaluable sources of information for security researchers, and sadly for bad actors as well.

If you know who the security team members are, you can go a little bit crazy and set up a dedicated tracker for their LinkedIn profiles. When you detect this infamous “I’m happy to announce” message on their profile, go and check that their access was properly revoked, name-bound sub-domain names and S3 buckets are still owned by the organization, and Slack, Zoom, and GitHub profile handles are properly secured. Security team members usually have elevated privileges within organizations, and when they depart, special care should be taken. If you notice it’s not the case, please disclose it responsibly and ethically!

I know it might look a lot like stalking, but it’s not. It’s about understanding the security posture of the organization you’re interested in, and it’s a very important part of the security research process. If you’re not comfortable with this, you can always stick to the technical part of the research, which is also very rewarding.

In this blog post, I’ve covered just the most basic and obvious ways to apply open-source intelligence for security research, but there are many more. State-backed actors are known to use these techniques combined with other techniques such as social engineering, and it’s important to understand how they work to be able to defend against them. Let me know if it’s something you’d like to learn more about!

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Cybersecurity basics: security mindset

Aleh Zasypkin — Tue, 20 Feb 2024 12:00:00 +0000

Hello!

Recently, I was invited to give a presentation on cybersecurity to a group of young developers at Onja, a social enterprise in Madagascar. Since they are at the beginning of their cybersecurity journey, I didn't want to bore them with the hackneyed OWASP Top 10 or overwhelm them with the plethora of security tools developers have to rely on these days to keep software safe and secure. Instead, I wanted to discuss something basic yet foundational for anyone dealing with cybersecurity - the security mindset.

In my experience, when it comes to security, the right mindset is what transforms an average engineer into a good one. It's not something you can buy or acquire quickly, but it's something everyone can learn over time and benefit from throughout their career. The earlier you realize this, the better. Similar to building personal wealth, the earlier you start learning and investing, the better your life will be.

Generally speaking, if you're dealing with anything related to security, the right mindset gets you roughly 80% of the job done; the remaining 20% comes from proper tooling, a good team, and other factors. I like to say that developing a security mindset is simple, but not easy.

This blog post is the presentation turned into a blog post. Read on!

Explore unhappy path

As software engineers, you've likely heard about the term "happy path" - the ideal scenario in the application flow. If the user follows the path we expect, and everything else in the application works as planned, everyone is happy. Hence, the term happy path. For a software engineer, it's entirely reasonable to think about the happy path first: it helps in understanding what needs to be built. However, when your goal is to assess whether the application is secure enough and understand how malicious actors or hackers could potentially break it, you should take a much closer look at how the application behaves when things go wrong – the so-called unhappy path.

This approach is somewhat similar to what QA engineers do, but as a software engineer, you go much deeper. Start by examining what happens when a legitimate user does something unexpected, like pressing buttons in the wrong order, repeatedly and quickly refreshing the page, bombarding your server with requests, or uploading a file of an unexpected type or much larger size than expected. Move on to more advanced scenarios, such as what if the external service or database your application communicates with is unavailable or hacked, sending malicious data? Or if the file you're reading from disk is corrupted, or the user content you render in the application contains malicious code?

Building a habit of thinking about the unhappy path first might not be easy, but ignoring these scenarios often leads to weaknesses in your application that others could exploit to harm your users and your reputation.

Assume compromise

More frequently than not, you hear things like:

"Oh, our network is behind a firewall and fully protected within a corporate network, we don’t need to worry about establishing trust between internal services and applications". But then, a testing application is deployed and exposed to the internet by mistake, becoming an open door for intruders to easily access everything within a corporate perimeter.
Or, "we use Okta to manage our users and their permissions, it takes care of everything, we don’t need to monitor for suspicious activity of employees' accounts." Then suddenly, Okta's customer support system is hacked, and malicious actors can now act on behalf of your own employees.
Or, "we don’t need to waste time on automated credentials revocation when an employee leaves the company; the admin will do it manually later this week". But then, suddenly, an angry fired employee wipes out your customer data backups and wreaks havoc in the internal infrastructure.
Or even, "let’s introduce this new file upload feature without any additional configuration switch that could allow us to easily reduce file size limit or disable the feature completely without rebuilding and re-deploying the application entirely". And then, the application is being DDoS’ed with gigantic files, putting your entire infrastructure down or skyrocketing your Cloud storage bills.

If something bad can happen in theory, someday it will happen in practice, and you'd better be prepared for that right from the start. Assuming that all your security measures are compromised will help you build much more resilient and future-proof applications that will save your time, money, and reputation.

Avoid insecurity through obscurity

You might have heard the term "Security through obscurity" - in simple terms, it's the reliance on secrecy as the primary method of providing security to a system or component. There's even an illusion that closed-source software is more secure than open-source because attackers cannot understand the application logic and spot flaws in the code. Some even claim that obfuscating code is a strong security measure to protect intellectual property.

Statements like that aren’t just untrue, but actually very dangerous - if a company believes that secrecy is a sufficient security measure, they won't invest time and money in educating their employees about security and won’t bother thinking about mitigation and response tactics if they come under attack. Lying to yourself is the worst type of lie.

Attackers are a smart and creative bunch of people. If they have enough motivation, they will figure out everything about your application and infrastructure they need to conduct an attack. There are thousands of tools easily accessible to them that can analyze every bit and piece of your application. Not to mention the emergence of AI that can sometimes collect the puzzle in minutes.

So, if you're serious about security, it's better to assume that your secrets aren't secrets to a sufficiently motivated party. It’s important to keep your secrets safe, though it shouldn’t be the only or certainly not the main security measure.

Be pragmatic about security

There is no doubt that keeping an application secure is important for both developers and users. However, keep in mind that the main goal of the software is to deliver value to the user. Nobody would use or pay for an application just because it's super secure. Look at security as something fundamental, always going without saying, like the absence of bugs, reasonable performance, and usability. There are practical limits to how secure an application can be while still delivering value to the user. When working with other engineers and helping them make their software secure, be collaborative and pragmatic. You have a common goal: to deliver top-notch software to your users that is both secure, useful, and user-friendly.

If you have to make trade-offs in security to improve usability or deliver more value, talk through the risks with the team, document everything, prepare a plan in case anything goes wrong, and move on.

Always be learning

The security landscape is constantly changing, in fact, it's one of the most dynamic areas of information technology today. Almost every day, we hear about new vulnerabilities, novel approaches to break applications, or trick users. I won't stop repeating that your knowledge is your most important tool, but it becomes dull very quickly if you don't sharpen it regularly enough. Make learning a part of your routine, read books, follow security researchers on their social networks - they do like to share their knowledge, dive deep into security disclosures and statements, grind through exploit proof-of-concepts until you fully understand how it works.

Always be curious, always be learning, it will pay off. We are all different, find the way to learn that is suitable for you, something that brings you joy and is fun to do, then it will be much easier.

Example: logs and exceptions

During their lifetime logs can flow through different environments with different level of security and access, and it’s hard to be 100% sure where your logs will be at any point in the future. It’s not uncommon to ingest your logs into different external cloud-based solutions (e.g. Elasticsearch or Datadog) for monitoring and further analysis. Older logs might be stored for a long term in a complete (e.g. S3).

When you’re dealing with logs, these are the important questions you should ask yourself:

Can logs contain secrets or customer information?
- Sensitive information isn’t only passwords or secret tokens, but also so-called PII (Personal Identifiable Information) - anything that can be used to identify a specific person - e.g., full name, username, address, phone number, and any other official document number. Even if you rotate leaked passwords in your application, they might still be valid in other places. Unfortunately, people like to reuse passwords.
If I log exceptions, do I fully trust all the fields that will be logged?
- Usually, developers pay attention to the data and responses they send to the user, but throwing exceptions is another important program flow that leads to returning some data to the user that might be sensitive too, but it’s often ignored. Exceptions can include file paths, environment variables, request and response headers that might include credentials and cookies.
Who can access logs during their entire lifetime?
- You should think about where your logs go after they are logged, how they are stored, and who might potentially have access to them. The safest assumption is that logs might eventually be exposed to the public in one way or another, so it’s better to be careful with logging anything that can be potentially sensitive.
Can logs contain user content that can be weaponized?
- There is an entire class of vulnerabilities that can be exploited through logs, so-called log injections. It can be anything, from making your terminal unusable to remote code execution where the attacker can execute binaries in your environment. It can be quite scary. I'd encourage you to read more about Log4Shell and log injections.

That wraps up today's post, thanks for taking the time to read it! If you found this post helpful or interesting, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Supercharge your app with user extensions using Deno JavaScript runtime

Aleh Zasypkin — Wed, 24 Jan 2024 11:00:00 +0000

Hello!

Today, I'd like to discuss one of the many approaches to implement user extensions in your application, using "script" extensions for the webhooks introduced in Secutils.dev in January, 2024 (1.0.0-alpha.5) as an example. In a nutshell, "script" extensions enable users to dynamically process incoming webhook requests and decide on the response on the fly, making simple webhooks akin to tiny applications.

As a user, have you ever wished for your favorite application to behave a little differently? Sometimes, even a slight change in behavior could make a big difference in the application or tool you rely on. Alternatively, as a developer, have you found yourself in a situation where numerous user feature requests seem almost identical but not quite enough to implement a single feature that satisfies all users without creating a ton of different toggles to customize behavior?

These are rhetorical questions, as I'm sure that such scenarios have crossed your path at least once. Otherwise, browser extensions, Shopify apps, Notion integrations, Grafana, and WordPress plugins wouldn't be as popular.

As a solo-developer for Secutils.dev, I operate with very limited resources and cannot accommodate every user's feature request, even if I wish to. On the other hand, prioritizing and developing features based on assumptions and limited upfront user feedback has its own challenges and risks. That's why, right from the start, I've been considering adding some sort of "extension points" into Secutils.dev that would allow users to customize the certain behavior of the utilities according to their needs.

The core idea is that if a specific modification holds genuine value for the user, they wouldn't mind investing some time in extending the application themselves, provided they have the right tools and documentation. Actually, this serves as one of the most effective forms of validation that the feature is indeed necessary. Over time, validated user extensions make their way into the main application functionality or even community "extensions" marketplaces.

Picking the extensions "framework"

The idea looks good in theory. Though it might not work for all applications or users, having a mostly developer audience makes things simpler. Developers are accustomed to modifications, plugins, and extensions. More importantly, they have coding skills, making them more comfortable with writing code to extend the applications they use. Moreover, with the emergence of highly capable code-generating language models (LLMs), being a developer might not be a strict requirement for crafting simple extensions in the future.

If I've convinced you that extending Sectuils.dev with the user code is a good idea, the next thing to consider is the language for this code. There are many great languages, but let's be honest — there's currently one universal "web" language, and that's JavaScript. It's easy to grasp and forgiving of user errors, making it the ideal language for user extensions!

If your application is written in JavaScript, integrating it with JavaScript extensions is a no-brainer. However, Secutils.dev is entirely written in Rust. How would I even begin? Fortunately, I recently came across an excellent blog post series explaining how to implement your JavaScript runtime in a Rust application with Deno:

Besides offering a JavaScript runtime, Deno also allows me to have complete control over which APIs and capabilities will be available to user JavaScript extensions. Brilliant!

Using Deno Core as extensions runtime

ℹ️ NOTE: I've left out some non-essential details in code examples for brevity, you can find the full source code on the Secutils.dev GitHub repository. I won't be explaining what Deno is and isn't in this blog post. If you're curious, you can find all the necessary information in the official Deno documentation.

The absolute minimum you need to embed a Deno JavaScript runtime in a Rust application is the deno_core crate. The basic code to execute your extension, represented as a string with asynchronous JavaScript code, might look like this:

use deno_core::{
  JsRuntime, 
  serde_v8, 
  v8,
  PollEventLoopOptions,
  RuntimeOptions
};
use serde::Deserialize;

/// Executes a user script and returns the result.
pub async fn execute_script<R: for<'de> Deserialize<'de>>(
   js_code: impl Into<String>
) -> Result<R, anyhow::Error> {
    // Create a new instance of the JS runtime.
    let runtime = JsRuntime::new(RuntimeOptions::default());

    // Convert a JS code string to a `ModuleCodeString` and
    // retrieve the result. This snippet assumes that JS code
    // from `js_code` is asynchronous and returns `Promise`.
    // For example something along these lines: 
    // r#"(async () => {{ return 2 + 2; }})();"#
    let script_result_promise = runtime
        .execute_script("<anon>", js_code.into().into())?;

    // Now, wait for the promise to resolve.
    let resolve = runtime.resolve(script_result_promise);
    let script_result = runtime
        .with_event_loop_promise(
            resolve, 
            PollEventLoopOptions::default()
        )
        .await?;

    // Deserialize script result from v8 type and return.
    let scope = &mut runtime.handle_scope();
    let local = v8::Local::new(scope, script_result);
    serde_v8::from_v8(scope, local)
}

If you're familiar with Rust, the code should be self-explanatory: we take a string with JavaScript code, convert it to a type expected by Deno/V8, instruct the runtime to execute the script, wait for the result promise to resolve, and then extract and return the value.

It's also possible to supply parameters to the script being executed. There are various ways to do this, but I opted for the script global scope as a method of sharing input parameters with the script:

use deno_core::{serde_v8, v8};
use serde::Serialize;

// Make sure parameters can be serialized to a
// v8 compatible type.
#[derive(Serialize, Debug, PartialEq, Eq, Clone)]
struct ScriptParams {
    arg_num: usize,
    arg_str: String,
    arg_array: Vec<String>,
    arg_buf: Vec<u8>,
}

// Create params.
let script_params = ScriptParams {
    arg_num: 1,
    arg_str: "Hello, world!".to_string(),
    arg_array: vec!["one".to_string(), "two".to_string()],
    arg_buf: vec![1, 2, 3],
};

// Retrieve script "scope".
let scope = &mut runtime.handle_scope();
let context = scope.get_current_context();
let scope = &mut v8::ContextScope::new(scope, context);

// Prepare a key to store our params in the global scope.
let params_key = v8::String::new(scope, "param").unwrap();
// Serialize params value to a v8 compatible type.
let params_value = serde_v8::to_v8(scope, script_params)?;
// Set the value in the global scope (`globalThis.param`).
context
    .global(scope)
    .set(scope, params_key.into(), params_value);

Dealing with malfunctioning and malicious extensions

A JavaScript extension operating within a full-fledged JavaScript runtime is a powerful tool, and like any powerful tool, it can be quite harmful if not used correctly. When you're building an extension runtime that will run arbitrary user extensions, it's wise to operate under the assumption that it may be misused someday, whether intentionally malicious or not.

Fortunately, Deno Core already offers certain security assurances by default: user scripts cannot interact with the network and file system (unless you explicitly expose this functionality, and it's possible!). Even though it significantly reduces the potential for abuse or attacks, scripts can still consume all your CPU and memory resources, leading to a denial-of-service (DoS) for your application!

For instance, imagine a malicious user provides the following JavaScript extension that never completes and occupies your valuable server's resources:

(() => {
    // Infinite loop.
    while (true) {}
})();

Typically, you should define a time limit for executing user extensions to handle long-running scripts (for Secutils.dev, it's set at 30 seconds), after which the "extension process" will be terminated. The code might look like this:

use std::{
    sync::{atomic::{AtomicBool, Ordering}, Arc},
    time::{Duration, Instant},
};

// Define a timeout after which the script will be terminated.
let termination_timeout = Duration::from_secs(30);

// Define the "cancellation token" that main thread
// can use to signal to the termination thread that
// script completed and termination isn't needed.
let timeout_token = Arc::new(AtomicBool::new(false));

// Retrieve v8::Isolate handle.
let isolate_handle = runtime.v8_isolate().thread_safe_handle();
let timeout_token_clone = timeout_token.clone();
std::thread::spawn(move || {
    let now = Instant::now();
    loop {
        // If main thread signaled that script completed
        // execution, exit.
        if timeout_token_clone.load(Ordering::Relaxed) {
            return;
        }

        // Otherwise, terminate execution if time is out, or sleep for max 2 sec.
        let Some(time_left) = termination_timeout.checked_sub(now.elapsed()) else {
            isolate_handle.terminate_execution();
            return;
        };

        std::thread::sleep(
            std::cmp::min(time_left, Duration::from_secs(2))
        );
    }
});

// Execute script...

// If the script completed execution early, tell
// "terminator" thread to exit.
timeout_token.swap(true, Ordering::Relaxed);

The code revolves around a special "terminator" thread that terminates the script execution when the time is up, and doesn't need additional explanation. The only detail worth mentioning is that I want the "terminator" thread to exit as early as possible if the script completes within the time budget. Hence, I check the status every 2 seconds instead of sleeping for 30 seconds.

Protecting against memory-hungry scripts in Deno is more challenging. I won't go into details about how it works and instead direct you to the issue in the Deno repository with all the details. In short, you need to create a JavaScript runtime with a specific heap limit and add a callback that's invoked when the memory limits are approached. This gives you a chance to terminate the execution before Deno/V8 crashes the entire process.

For example, a script like this would quickly consume all available memory:

(async () => {{
   let s = "";
   while(true) { s += "Hello, World"; }
   return "Done";
}})();

And here’s how you can try to mitigate this:

use deno_core::{JsRuntime, RuntimeOptions};

// Create a new instance of the JS runtime with
// a 10 megabytes heap limit. 
let mut runtime = JsRuntime::new(RuntimeOptions {
    create_params: Some(
        v8::Isolate::create_params().heap_limits(0, 10 * 1024 * 1024),
    ),
    ..Default::default()
});

// Retrieve v8::Isolate handle and setup a "near_heap_limit" callback.
let isolate_handle = runtime.v8_isolate().thread_safe_handle();
runtime.add_near_heap_limit_callback(move |current_value, _| {
    // Terminate execution.
    isolate_handle.terminate_execution();

    // Give the runtime enough heap to terminate
    // without crashing the process.
    5 * current_value
});

These are good protective measures to have, but unfortunately, they don't provide complete protection. The script can quickly fill up memory, preventing termination from completing, or it might perform some heavy actions to hog your CPU. So, remember to set the CPU and memory limits for the container or Kubernetes pod where you're running your JavaScript runtime!

Monitoring user extensions

If you're running user extensions or code, it's important to monitor them not only to alert you when something suddenly goes awry but also to gain valuable insights into how users extend and use your application.

As I mentioned in my "Privacy-friendly usage analytics and monitoring" post, I rely on the Elastic Stack to monitor Secutils.dev deployments. I use Filebeat and Metricbeat to collect and ingest application logs and metrics into Elasticsearch, which I can later use in my Kibana dashboards. I've created several visualizations and dashboards to monitor various aspects of my Secutils.dev Kubernetes deployment. Here are a few relevant to the "webhooks" script extensions:

Script execution time

Firstly, I monitor how long user scripts take to execute. If a script takes more than 5 milliseconds to complete, it enters a "red zone" that makes me curious about what it does! The highest bar you see in the screenshot below is attributed to a script that renders PNG on the fly!

Script terminations and crashes

As I explained earlier in this post, I set limits on how much time (30 seconds) and memory (10 megabytes) a script can consume during execution. If a script exceeds these limits, it gets terminated, and the relevant logs are recorded for later review. This lets me understand the situation and decide what actions to take. If the user's intent is legitimate, I can collaborate with them individually to adjust these limits on a case-by-case basis. However, if the intent is malicious, well, I take some other measures 😬

Overall memory consumption

As I integrate the Deno JavaScript runtime into a Secutils.dev API server application, I want to monitor the overall memory consumption of the API server. As shown in the following screenshot, the API server's memory consumption remains consistently low most of the time, especially when compared to the memory required by the Web Scraper.

All in all, I'm pleased with how it turned out and how straightforward it was to work with Deno Core. The "script" extensions have proven to be a nice way to turn static responders into tiny applications that users can tailor to their needs without my involvement. I'm planning to make use of the Deno JavaScript runtime in other parts of Secutils.dev where I want to provide users with more flexibility. Stay tuned!

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

How to track anything on the internet or use Playwright for fun and profit

Aleh Zasypkin — Tue, 16 Jan 2024 11:00:00 +0000

Hello!

After a refreshing winter-time blogging-break, I'd like to resume introducing new features of Secutils.dev through practical use cases. Ever wondered how to easily track something on the internet that does not offer subscribing to updates natively? If so, let me introduce you a recently released web content tracking utility that made its debut in December 2023 (v1.0.0-alpha.4). I'll explain how I use it for various tasks, well beyond its primary security focus. Additionally, I'll cover how it's made in case you're interested in developing a similar tool yourself. Read on!

If you've read my previous blog posts or ever experimented with Secutils.dev, you might be familiar with the web resources tracking utility. This utility allows you to monitor changes in web page resources, specifically JavaScript and CSS. While it has a somewhat narrow security-focused purpose — detecting broken or tampered web application deployments — it may not be the type of tool you use daily. Nevertheless, it serves as a good example of what you can build with modern browser automation tools like Playwright and Puppeteer. If you're interested in digging deeper into this specific utility, refer to the following blog post series:

Back in July 2023, while working on the web page resources tracker utility and integrating it with other Secutils.dev components, I realized that the combination of a browser, scheduler, and notifications offers far more interesting applications beyond web page resources tracking. Imagine this scenario: there's specific content on the internet that interests you, and you want to stay informed about any updates to that content, whether it's a new blog post from your favorite author, changes to a particular web page, or a hot discussion on Hacker News.

Typically, you would subscribe to email or push notifications through a subscription form, and in many cases, that suffices. But what if the website or application in question doesn't provide a way to subscribe to the updates you need? What if you're only interested in specific changes, or perhaps you want to adjust the frequency of notifications?

This is where the trio of browser, scheduler, and notifications can be extremely valuable. You can instruct the scheduler to periodically check the content you're interested in, use a browser automation tool to extract the relevant part of the content, and then rely on notifications to alert you to any changes. Essentially, this is what the web page content tracker utility does. In general, if you can manually obtain the information you need through a browser, it can be automated as well.

Originally, I developed the web page content trackers utility to address a very specific security-focused requirement in my day job — I needed to monitor security headers and a few other properties of the production Cloud Kibana deployment. However, since its release, I've found myself leveraging this the content trackers for a lot of use cases that extend well beyond security:

In one of my other projects, AZbyte | ETF, I require up-to-date information about exchange-traded funds (ETFs) from various fund providers (iShares, Vanguard, etc.). Content trackers come in handy to monitor their websites for new funds, as these providers don't offer a way to subscribe to such updates.
For my day job, I track web page metadata of my development “serverless” Elastic projects. This helps me know when they are automatically upgraded to a new version since there's currently no straightforward way to receive notifications about this.
I use content trackers to keep an eye on "Pricing", "Terms", and "Privacy Policy" pages of some of the tools and services I use. This should help me to catch any unexpected changes early on, especially with services like Notion, Oracle Cloud, and Cloudflare.
There are several trackers dedicated to "What's New" pages that only notify me when updates include specific keywords, and so on.

As you can see, the use cases are virtually limitless. In fact, I've accumulated so many web page content trackers that I now need a way to organize them effectively. I'm considering picking up either the “Add support for user data tags” or “Allow grouping user content into separate projects” enhancement during the ongoing “feature sprint” to address this.

Now, let's take a closer look at one of my simplest personal web page content trackers!

Example: Trending GitHub repositories

I enjoy discovering new open source projects for inspiration, and the GitHub trending page serves as an excellent resource for that. However, as far as I'm aware, there's no straightforward way to receive notifications when a new project rises to the top of the trending repositories, unless I use GitHub APIs directly. To workaround this, I set up a web page content tracker with the following settings:

All fields should be self-explanatory: I instruct the tracker to check for updates at https://github.com/trending daily, retaining only the last three revisions. I provide the tracker with a piece of JavaScript code (Content extractor) to execute on the target web page, extracting the relevant content. If this content differs from the previously extracted content, the tracker sends an email notification. Additionally, if the content extraction attempt fails, the tracker will retry a few more times at 2-hour intervals. If none of the attempts succeed, the tracker notifies about the failure.

The most important part here is the Content extractor, a simple JavaScript script executed within the context of the target web page to extract the actual content:

// Get top link at the "trending" page.
const topLink = document.querySelector('h2 a.Link');

// Cleanup the repository name.
const topLinkName = topLink.textContent.split('/')
  .map((part) => part.trim().replaceAll('\n', ''))
  .filter((part) => part)
  .join(' / ');

// Craft a Markdown-styled content with a link.
return `Top repository is **[${topLinkName}](${topLink.href})**`;

While the script, relying on opaque web page-specific CSS selectors, might appear fragile, these selectors don't change frequently in practice. Moreover, the tracker will notify me if this code begins to fail, allowing me to make necessary adjustments.

One doesn't need to be proficient in JavaScript to write such simple scripts — ChatGPT and similar tools can generate something like this easily nowadays. I'm seriously thinking about launching a dedicated paid service centered around this functionality. Users could simply hover over the content they want to track, and the AI would handle the rest! Wouldn't that be awesome? 😃

The script can return Markdown-styled content, making it easier for users to consume. Here's how it looks in Secutils.dev UI:

With Markdown and a bit of creativity, one can create a nice personalized version of the tracked content!

How it works

I won't dive into the UI, HTTP APIs, or storage layer used for this functionality, as it's all standard tech. I'd better focus on the content extraction part, the core of this functionality.

To begin, all functionality related to browser automation and web scraping lives in a dedicated service — Web Scraper. The primary rationale is that dealing with browsers and arbitrary user scripts is tricky from a security standpoint, and it's always a good idea to isolate such functionality as much as possible. You can read more about the security aspects of web scraping in the "Running web scraping service securely" post.

As the post title suggests, at the heart of Web Scraper lies Playwright with an additional HTTP API layer on top. Playwright is an exceptional tool that manages all interactions with the headless browser and abstracts away a considerable amount of complexity. Let me show you how I use Playwright to extract content from web pages:

ℹ️ NOTE: I've omitted some non-essential details for brevity, you can find the full source code at the Web Scraper GitHub repository.

const browserToRun = await chromium.launch({
  headless: true,
  chromiumSandbox: true,
  args: ['--disable-web-security'],
});

In the snippet above, we run Chromium in headless mode and enable the security sandbox, which is disabled by default, but I highly recommend enabling it. I also set the --disable-web-security flag to bypass any CORS restrictions. This is important if you want to allow injected scripts to make XHR requests to other domains/origins. It can be handy if the user's custom script is just a light "shell" that asynchronously loads the JavaScript code to execute from another place (refer to examples in documentation for more details).

Remember that running the browser might consume a significant amount of resources, so you might want to consider shutting it down after some idle timeout or maybe even scale your service to zero completely. Secutils.dev Web Scraper runs the browser on demand and shuts it down after 10 minutes if it's not used by default.

The next step is to decide what input parameters the content scraper should support. The most obvious candidates are:

[Required] URL to track the content.
[Required] Previously extracted content. In some cases, you might want to compare the previous and new content and only save a new version if a special condition is met.
[Required] Content extractor JavaScript script. This script is injected into the target page and executed once the page is loaded. Since the script is executed in the most up-to-date version of the browser, it can use the latest JavaScript features and Web APIs! The script can return anything as long as it's possible to serialize it as a JSON string and store it in a database.
[Optional] A list of custom HTTP headers to send to the target web page. This may be required if the page you're tracking requires authentication (e.g., via Cookie or Authorization HTTP headers) or some sort of consent (e.g., Cookie consent) before rendering the content.
[Optional] A delay or CSS selector to wait for before the tracker tries to extract content. This is a must for some very dynamic and heavy modern applications that can lazily load the content.

With all these parameters, the code to scrape content might look like this (simplified and with additional comments):

// Create a new browsing context and pass custom HTTP headers.
const context = await browser.newContext({ extraHTTPHeaders: headers });

// Create a new page within this context.
const page = await context.newPage();

// Inject a custom script, if provided.
if (scripts?.extractContent) {
  await page.addInitScript({
    content: `self.__secutils = { async extractContent(context) { ${scripts.extractContent} } };`,
  });
}

// Navigate to a custom page and retain full `Response`
// to return detailed error messages.
let response: Response | null;
try {
  response = await page.goto(url, { timeout });
} catch (err) {
  return { type: 'client-error', error: "…" };
}

// Wait for a custom CSS selector, if provided.
if (waitSelector) {
  try {
    await page.waitForSelector(waitSelector, { timeout });
  } catch (err) {
    return { type: 'client-error', error: "…" };
  }
}

// Finally, extract web page content.
let extractedContent: string;
try {
  // Use `jsonStableStringify` to make sure the same result
  // always serializes to the same JSON string.
  extractedContent = jsonStableStringify(
    scripts?.extractContent
      // If content exraction script is provided, execute it.
      // See definiton of `extractContent` function below. 
      ? await extractContent(page, { previousContent})
      // Otherwise, treat the full web page HTML as content.
      : jsBeautify.html_beautify(await page.content()),
  );
} catch (err) {
  return { type: 'client-error', error:"…" };
}

async function extractContent(page: Page, context: WebPageContext<string>) {
  // Evaluate custom script in the page context.
  return await page.evaluate(async ([context]) => {
    const extractContent = window.__secutils?.extractContent;
    if (!extractContent || typeof extractContent !== 'function') {
      throw new Error("…");
    }

    return await extractContent({
      ...context,
      // Deserialize previous content, if available.
      previousContent: context.previousContent !== undefined 
        ? JSON.parse(context.previousContent)
        : context.previousContent,
    });
  }, [context] as const);
}

As you can see, Playwright is a very powerful tool, and working with it is straightforward. I omitted a few pieces that rely on the Chrome DevTools Protocol (e.g., collecting all external requests with responses and clearing browser cache) that aren't strictly relevant for this post, but you can check out the Web Scraper GitHub repository to see the full source code if you're curious.

What's next

Web page content trackers are already quite functional, but I have a number of ideas on how to make them even more useful:

Add ability to capture web page screenshots and performing visual diffs (secutils#33)
Allow tracking the content of web pages protected by WAF and CAPTCHA (secutils#34)
Add support for auto-generated content extraction scripts

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Explore web applications through their content security policy (CSP)

Aleh Zasypkin — Tue, 28 Nov 2023 12:00:00 +0000

Hello!

I've finally wrapped up the feature development and fixes planned for the "Q4 2023 – Oct-Dec" milestone of Secutils.dev, a month earlier than expected! It feels good to be getting better at estimating my own work 🙂 I still need to update documentation and create a few demo videos for the new functionality, but that should be the easy part. Hopefully, I can release a new version in a week or so.

Like anything we invest our time and energy in, I want to raise awareness about the work I've done, gauge interest, and hopefully receive constructive feedback. I'm not a fan of blunt self-promotion, so I'm going to try something different - demonstrating new features in action. Sometimes I'll show their business value, and other times it'll just be for fun and entertainment. In this post, I'll demonstrate how to use the new “Import content security policy” feature to learn a bit more about the websites you use every day. Let's dive in!

Alright, let's explore a few popular websites and uncover any new insights from the CSP they employ. To import the policy, head to Web Security → CSP → Policies and click on the Import policy button. Within the import modal, enter an arbitrary name, the webpage URL, and select the source from which to import the policy: HTTP header (enforcing), HTTP header (report only), or HTML meta tag.

Google

By default, Secutils.dev allows importing CSP from the Content-Security-Policy HTTP header, matching the HTTP header (enforcing) policy source in the import dialog. However, attempting to import CSP from this source results in an error. Surprisingly, google.com doesn't transmit this header. Instead, it delivers CSP via the Content-Security-Policy-Report-Only HTTP header! It actually makes sense when you think about it: as the most visited website on the planet, they wouldn't want to accidentally disrupt anything with CSP changes, especially considering the need to support all web browsers. Instead, opting for a robust monitoring solution around CSP violation reporting seems more plausible. They might even set up alerts for suspicious activities that could indicate attempts to harm users through their website. This is, of course, speculative, but it seems to align logically.

Now, let's examine what google.com delivers in the Content-Security-Policy-Report-Only HTTP header:

The CSP used by Google appears quite reasonable to me, given their stature. Although having two unsafe directives isn't ideal, I trust Google's Security team extensively evaluated potential attack vectors and deemed the risk close to negligible. The inclusion of report-sample can be incredibly useful when monitoring CSP violations since having a sample makes it much easier to understand how the policy was violated exactly.

Interestingly, CSP violations are directed to https://csp.withgoogle.com/csp/gws/other-hp. I hadn't encountered this website before! I encourage you to visit csp.withgoogle.com to explore this valuable resource dedicated to CSP and its necessity.

Bing

Alright, let's take a look at Google's competitor - bing.com. And here's the first surprise - Bing doesn't utilize CSP at all! Who would've thought?

I can understand why certain websites resort to using unsafe CSP directive values, or why some opt for monitoring rather than strict enforcement. However, I can't seem to find any justification for Bing's complete absence of CSP! If anyone has a hint as to why, I'd love to hear it.

DuckDuckGo

Okay, let's explore something more exotic - duckduckgo.com. And would you look at that!

Firstly, unlike Google, DuckDuckGo enforces CSP via the policy delivered within the Content-Security-Policy HTTP header. Secondly, DuckDuckGo's CSP employs a strict none default source, which is always a good practice.

Another notable aspect is that DuckDuckGo's CSP includes sources in the *.onion top-level domain. This might be because they maintain the same policy regardless of how the website is accessed. That seems logical.

However, it's disappointing that DuckDuckGo doesn't appear interested in analyzing CSP violations as they haven't set up any reporting. It's a letdown, but on the flip side, it would only make sense if they had the desire and resources to actively utilize this data.

Bonus: ChatGPT

Of course, how can a blog post these days avoid mentioning AI? Let's peek at the CSP employed by ChatGPT. Can we? Apparently not! ChatGPT utilizes Cloudflare application protection, which blocks the Secutils.dev HTTP client from executing a simple HEAD request to retrieve the policy. What a shame!

It's something I might address in the future. For now, let me turn this setback into an opportunity to demonstrate another method of importing content security policy to Secutils.dev - via serialized policy text. This process is a tad more complex as it involves manually capturing the policy using the browser's developer tools and then pasting it into the Serialized policy tab within the import dialog. Here's the CSP manually imported from ChatGPT:

Simply by examining a website's CSP, you can learn a lot about its construction and reliance on third-party solutions. It's a complex beast with many moving parts. Nothing particularly alarming here though. It's a pretty standard set for a modern application.

I also noticed that OpenAI collects CSP violation reports using the Datadog Content Security Policy integration. However, having unsafe-eval and unsafe-inline in the scripts directive, especially for an application like ChatGPT, does raise concerns. Hopefully, there's a compelling reason behind this.

Ultimately, whether you're curious about how an application operates or conducting initial reconnaissance, overlooking CSP would be a mistake. Sometimes, it's like a treasure trove, revealing the inner workings and structure of an application.

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Two simple rules for better and more secure code

Aleh Zasypkin — Tue, 07 Nov 2023 12:00:00 +0000

Hello!

In one of my previous posts, "The best application security tool is education", I discussed why educating yourself or your engineers about security can yield the highest return on investment, especially if you have a limited budget. However, I understand that learning or teaching security is not as straightforward as it sounds. Every organization has its unique characteristics, and every engineer has their own distinct qualities. Moreover, internalizing secure coding practices is a time-consuming process. If you're just starting on this journey, I'm here to share two very simple rules that are easy to remember and have the potential to significantly enhance the security of the code you or your colleagues write. So, let's dive in!

Don't log what you don't know

If you're working on a non-trivial application, chances are you're logging various pieces of information. Logs are essential for understanding your software and are indispensable during debugging. In fact, the more application and operational information you log, the better prepared you are to debug any issues that your application might encounter.

However, the rule I want you to keep in mind is this: every time you consider logging something, ask yourself these two critical questions:

Is the data I'm logging sensitive? For instance, does it include credentials, request or response headers, or any information that could potentially identify my users, like client IPs or user names? In short, anything that falls under the category of Personal Identifiable Information (PII).
If I'm logging a complex data structure, do I fully understand and trust all the fields that will be logged?

Asking these questions becomes especially crucial when you're dealing with data that originates from users or external services you don't have full control over. This is important because the data you log might eventually end up elsewhere, such as in Elasticsearch, backed up in the cloud, or stored locally for an unknown period. It's not uncommon for these secondary locations to be less secure than the environment where the logs were initially captured. This increases the risk, sometimes significantly, that the logs might be accessed by individuals who weren't meant to see them, even months after the logs were recorded. This is a potential problem, not to mention the possibility of leaks and hacks, which can also occur.

Leaking sensitive information through logs is one problem, but keep in mind that mishandled logs can also be weaponized, as explained in the Log injection article from OWASP.

In summary, please avoid blindly logging everything and, instead, select carefully based on what is safe and genuinely necessary.

Don't expose raw errors

I have to admit that I see it far more frequently than I would like: an engineer carefully crafts a successful response, selects only the necessary data for return, and wisely sanitizes untrusted data. However, at the same time, they completely neglect the errors their code generates and throws.

Errors returned to users or consumers of APIs can sometimes contain as much, if not more, sensitive data compared to a successful response. Stack traces, file system paths, URLs with embedded credentials, internal addresses, and environment variables with secrets are just a few examples of what might be included in these errors, inadvertently leaking from your software.

The rule I want to emphasize is simple: strive to handle errors internally, and log the relevant error details when necessary. But, when it comes to an error that should be visible to your users or API consumers, craft a custom, safe, and actionable error message instead.

⚠️ NOTE: The two rules I've discussed may seem simple and obvious, but you'd be surprised at how often they are neglected, leading to serious security incidents that can cost organizations thousands or even tens of thousands of dollars in remediation and associated expenses. Forewarned is forearmed!

That wraps up today's post, thanks for taking the time to read it! If you found this post helpful or interesting, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Q4 2023 iteration: tracking arbitrary web content, user-specific webhook subdomains, inherited CSP, and more

Aleh Zasypkin — Tue, 31 Oct 2023 12:00:00 +0000

The original post was published on my blog on October 10, 2023.

Hello!

Last week, I kicked off the new "Q4 2023 – Oct-Dec" development and research iteration for Secutils.dev, the open-source toolbox designed for developing and testing secure applications. In this post, I'll take you through the significant features and changes that will be the focus of my work in the coming weeks and months: tracking arbitrary web content, user-specific webhook subdomains, inherited CSP, and more. Let's dive in!

Tracking arbitrary web content

Tracking issue: #secutils/28

In my previous update, I mentioned that Web Page Resources trackers now allow you to specify custom JavaScript scripts to filter and map resources. As I implemented this feature, I had a slightly broader vision in mind: extending this functionality to address use cases beyond web page resource tracking. One such case that has been on my mind for some time is the ability to track changes in any arbitrary web page content or behavior.

Consider this scenario: You're interested in specific content on a web page, such as a list, table, or even navigation bar items, but the page doesn't offer a subscription or notification features. Or maybe you'd rather not create a dedicated account for it. In such cases, the typical approach involves periodically visiting the page and manually scanning for updates — a process that's neither convenient nor efficient. Fortunately, many tasks like this can be automated.

This is where the new functionality in Secutils.dev comes into play. It will allow you to track arbitrary web content as long as you can extract the relevant data using a custom JavaScript script injected to a target web page. While it may not immediately seem related to security, it has its own utility:

Security researchers can stay informed about new sections or internal links on websites they're analyzing.
Developers can receive alerts if their production web pages render or expose unexpected content.
Anyone needing to monitor updates across various unrelated sources, from public repository commits to recent disclosures on random websites, can now consolidate their tracking efforts in a single location.

User-specific webhook subdomains

Tracking issue: #secutils/22

Previously, you could only specify a unique name for the auto-responder webhook. For example, if you named your responder as my-page.html, you'd get the following webhook endpoint URL: https://secutils.dev/api/webhooks/{your_unique_user_handle}/my-page.html. That's perfectly fine for simple use cases where you can directly feed your full webhook URL to a system or service you're interacting with.

However, some services might already assume a certain URL structure and won't allow you to specify the full URL directly. In such cases, you're usually limited to providing only a host name. For example, when testing an interaction between Service A and another well-known Service B, such as Elasticsearch or Supabase, Service A might request only the host name and credentials for Service B, as it's well aware of all Service B's REST APIs. In this scenario, you'd either use dedicated mocking tools (e.g. WireMock) or set up a testing Elasticsearch or Supabase cluster yourself. The latter case can be quite involved, and you'll need to go through various steps to understand exactly what data Service A is sending to Service B.

To address cases like this, Secutils.dev will offer an alternative way to configure and invoke responder webhooks. Each user will be allocated a dedicated webhook subdomain with the ability to configure any path, including the root one (/): https://{your_unique_user_handle}.webhooks.secutils.dev/my-page.html.

ℹ️ NOTE: It's worth emphasizing that Secutils.dev is not aiming to compete with fantastic mocking tools like WireMock or MockServer, and realistically, it can't. These tools have strong communities and excel at what they do! The goal behind the webhook utility is to complement the Secutils.dev toolbox with yet another commonly used utility in various short-lived security-related scenarios that's incredibly easy and cost-effective to set up and dispose of when no longer needed. A scenario akin to choosing between a universal lightweight Swiss Army knife and highly specialized Wüsthof Chef's knives.

Inherited content security policies (CSP)

Tracking issue: #secutils/16

Currently, Secutils.dev enables you to construct content security policies (CSP) templates through a guided UI. Once you've created a policy template, you can generate a policy ready for use on your website. This approach works well when you have a clear goal and can create a new policy template from scratch.

However, there are times when you'd prefer to base your policy on or "inherit" it from an existing policy. It would be beneficial if, when you create a new policy template in Secutils.dev, you have the option to either specify an existing policy directly or simply point to an arbitrary web page from which to fetch the policy. These changes will enhance the flexibility and usability of Secutils.dev when it comes to managing content security policies.

This is a feature I'll be working on in the upcoming weeks.

Sharing & collaboration

Tracking issue: #secutils/24

As mentioned in my previous post, I’m planning to gradually expand the list of user-generated content that can be publicly shared via Secutils.dev. In this iteration, my goal is to enable the sharing of user certificate templates. This means that anyone with the unique link will not only be able to view the certificate template but also generate a new key/certificate pair. This feature will enhance collaboration and convenience within the Secutils.dev community. Stay tuned for more updates!

That wraps up today's post, thanks for taking the time to read it!

If you found this post helpful or interesting, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Announcing 1.0.0-alpha.3 release: more powerful resource tracking, notifications and content sharing

Aleh Zasypkin — Tue, 24 Oct 2023 10:00:00 +0000

The original post was published on my blog on October 4, 2023.

Hello!

Earlier this week, I wrapped up the "Q3 2023 – Jul-Sep" iteration and cut a new 1.0.0-alpha.3 release of Secutils.dev. In this post, I would like to quickly walk you through the major changes since 1.0.0-alpha.2: notifications, more powerful web page resource tracker, sharing capabilities and more. Let’s dive in!

Scheduled resources checks

If you’ve read my previous posts or tried Secutils.dev web page resources tracker functionality, you might recall that users were required to manually trigger resource checks. With this release, you have an option to schedule automatic resources checks to be performed hourly, daily, weekly, or monthly! When you configure the web page resource tracker, you define how many resource revisions Secutils.dev should store so that you can view the diff between two consecutive revisions. Once the limit is reached, the next revision will displace the oldest one.

Email notifications for changed resources

Since previously you were supposed to manually trigger immediate resource checks, it wouldn't make much sense to send you any additional notifications about detected changes. You'll be presented with the check result in the UI as soon as the check is complete without losing context. However, the automatic scheduled resource checks change the control flow, where Secutils.dev should perform the check regularly and notify you if it detects any changes. In the latest release, you can opt in to email notifications, and Secutils.dev will email you if it detects any changes in resources.

Custom resources filtering and mapping

Modern web pages can contain numerous resources, and tracking changes for all of them may not be always necessary. Additionally, certain resources, like those injected by web page analytics solutions, can change with every page load, potentially leading to excessive notifications. In such cases, you'll likely want to filter out irrelevant resources or focus on specific ones.

In more advanced scenarios, you might be interested in only a portion of a web page resource. For instance, there could be scripts bundling multiple third-party libraries, with changes in some libraries being more important than others. It would be convenient to have the ability to trim or "map" these resources into more meaningful resources.

I explored various approaches to address these use cases in the simplest way possible, but there were always complex edge cases that required a change in direction. However, considering that the primary audience for Secutils.dev is software developers, I decided that introducing some complexity could offer much greater flexibility.

As mentioned in this post, I use Playwright (with Chromium) to extract web page resources. While this choice adds complexity to implementation, security, and deployment, it grants quite a bit of flexibility. With Playwright, I can access, intercept, or modify virtually everything on the tracked web page. Notably, Playwright allows me to inject custom JavaScript scripts into a web page. Rather than inventing my own syntax/parser for custom user resource filters and mapping rules, I can provide users with the full power of modern JavaScript executed within the latest available browser. The only constraint is that users must adhere to the input and output interfaces expected by Secutils.dev.

The potential applications of this approach are vast. I'm already planning to extend it to cover more utilities and use cases, such as tracking changes in page content, not just resources. Imagine a change tracker for virtually anything on the web!

Sharing & collaboration

In today's world, it's challenging to envision a software engineer or security researcher working entirely in isolation. As software systems grow in size and complexity, collaboration becomes essential. That's one of the reasons why collaboration software is on the rise, with built-in collaboration features becoming increasingly common.

While it may be too early to implement full-fledged two-way collaboration functionality in Secutils.dev, I recognize that the absence of such features could limit the tool's adoption. Therefore, I'm planning to gradually introduce collaboration-related features in each iteration, starting with the "one-way" sharing functionality released in 1.0.0-alpha.3 release. With this release, you can share created content security policies with anyone on the internet, even if they don't have a Secutils.dev account.

In the future, I intend to expand this sharing functionality to include digital certificate templates and tracked web page resources.

Other enhancements and bug fixes

In addition to the major features mentioned above, this release also includes several smaller enhancements. These include extending the digital certificate editor to allow users to configure private key size (for RSA and DSA) and elliptic curve name (for ECDSA).

As previously mentioned, while the resource tracker functionality has become more powerful, it also comes with increased security risks. Therefore, I've made security enhancements for Docker images for all Secutils.dev components, and the Web Scraper component itself. I've covered this in more detail in my Running web scraping service securely post.

You can find the full change log here: changelog#1.0.0-alpha.3

In the next few days, I'll be prioritizing work for the upcoming "Q4 2023 – Oct-Dec" iteration. In my next post, I'll provide more details on what I'll be focusing on during this period.

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Thank you for being a part of the community!

Running web scraping service securely

Aleh Zasypkin — Thu, 19 Oct 2023 10:00:00 +0000

The original post was published on my blog on September 12, 2023.

Hello!

In my previous post, I shared the update regarding the upcoming "Q3 2023 - Jul-Sep" milestone. While I briefly covered how I implemented the notifications subsystem in Secutils.dev, there are a few other important changes I've been working on for this milestone. One of these changes is related to the fact that I’m preparing to allow Secutils.dev users to inject custom JavaScript scripts into the web pages they track resources for (yay 🎉). As a result, I've spent some time hardening the Web Scraper environment's security and wanted to share what you should keep in mind if you’re building a service that needs to scrape arbitrary web pages.

When it comes to web page resource scraping, Secutils.dev relies on a separate component - secutils-dev/secutils-web-scraper. I've built it on top of Playwright since I need to handle both resources that are statically defined in the HTML and those that are loaded dynamically. Leveraging Playwright, backed by a real browser, instead of parsing the static HTML opens up a ton of opportunities to turn a simple web resource scraper into a much more intelligent tool capable of handling all sorts of use cases: recording and replaying HARs, imitating user activity, and more.

As you might have guessed, running a full-blown browser within your infrastructure that users can point literally anywhere can be quite dangerous if not done right, so security should be a top-of-mind concern here. Let me walk you through the most obvious security concerns one should address before exposing a service like that to the users.

Input validation

The first line of defense, and the most basic one, is to limit where users can point their browsers through input argument validation. If you know that only certain resources are supposed to be scraped by users, ensure you properly validate the provided URLs and allow only the expected subset. As a bare minimum, you should validate the arguments on the server/API side, but also consider doing it on the client side if possible, as it would significantly improve the user experience of your service and serve your users better. However, never-ever rely solely on client-side validation - client-side validation is for your users' convenience and is not a security measure, as it can be easily bypassed by directly accessing your APIs.

Although the resource tracker functionality of Secutils.dev is designed to allow users to scrape virtually any web page on the internet, I still make efforts to validate the provided URL and restrict it as much as possible:

if tracker.url.scheme() != "http" && tracker.url.scheme() != "https" {
    anyhow::bail!("Tracker URL scheme must be either http or https");
}

// Checks if the specific hostname is a domain and public (not pointing to the local network).
let is_public_host_name = if let Some(domain) = tracker.url.domain() {
    ...
} else {
    false
};

if !is_public_host_name {
    anyhow::bail!("Tracker URL must have a valid public reachable domain name");
}

Resource isolation

Running an entire browser is a resource-intensive operation, even if it’s a headless one. It’s likely that the component responsible for running and dealing with the browser isn’t the only part of your service. It's probably not as critical as components dealing with authentication or database access, for example. You certainly don’t want your entire service to go down just because a resource-intensive web page consumed all the available resources on the host.

To address this, consider running the component that spawns the browser within a separate container. This approach not only better protects your business-critical functionality but also allows you to scale up or down your browser-specific service independently.

Additionally, try to explicitly limit the resources available to the container using techniques like control groups or similar features that suit your environment. For instance, if you’re running your container in Kubernetes, you can limit resources available to that container using configurations such as this:

apiVersion: v1
kind: Pod
metadata:
  name: web-scraper
spec:
  containers:
  - name: app
    image: node:20-alpine3.18
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "1Gi"
        cpu: "500m"

Privilege management

The principle of least privilege is particularly crucial when dealing with complex software like a web browser. Running a browser as the root user is inviting trouble, and it's something you should avoid. For instance, if you're using Node.js to automate a headless browser with tools like Puppeteer or Playwright, make sure to run it as a non-root user:

FROM node:20-alpine3.18
...
USER node
CMD [ "node", "src/index.js" ]

If you're running your container in Kubernetes and relying on a non-root user, you can safely drop all capabilities for that container:

securityContext:
  capabilities:
    drop: [ ALL ]

You can take additional steps by setting the appropriate seccomp profile for the Node.js container:

securityContext:
  seccompProfile:
    type: Localhost
    ## Taken from https://github.com/microsoft/playwright/tree/main/utils/docker
    localhostProfile: secutils-web-scraper-seccomp-profile.json

These measures ensure that your browser runs with the least privileges necessary, reducing potential security risks.

Browser sandbox

If you've followed the recommendation from the previous section and are running your browser process as a non-root user, there's no reason not to enable a sandbox for your browser. For example, if you're using Playwright with Chromium, you can enable the sandbox like this:

import { chromium } from 'playwright';

const browserToRun = await chromium.launch({
  chromiumSandbox: true,
});

Enabling the sandbox adds an extra layer of security to your browser operations, visit no-sandbox.io to learn about the potential risks of disabling the Chromium/Chrome sandbox.

Network policies

Even if your input validation code appears reliable today and you have a solid test coverage, bugs can occur at any time. If you have the opportunity to implement multiple layers of defense, make use of as many layers as your financial and resource constraints allow. Implementing proper network policies for the container running the browser based on user-provided URLs is one of such layers. At the very least, you should safeguard your internal infrastructure by allowing access only to globally reachable addresses while excluding local host resources and internal network resources. For example, in the case of IPv4, you can exclude private IP ranges like 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

In Kubernetes, you can achieve this using NetworkPolicy. Here's an example of how to set up a simple policy to forbid access to non-global IP addresses:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: secutils-web-scraper-network-policy
  namespace: secutils
spec:
  policyTypes: [ Ingress, Egress ]
  podSelector:
    matchLabels:
      app: secutils-web-scraper
  # Allow incoming traffic only from Secutils.dev API pods.
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: secutils
        podSelector:
          matchLabels:
            app: secutils-api
  # Allow outgoing traffic only to DNS server and public internet.
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: coredns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
            - 10.0.0.0/8
            - 172.16.0.0/20
            - 192.168.0.0/16
      ports:
        - protocol: TCP

Monitoring

So, you've implemented robust input validation, ensured container security, isolated resource-heavy workloads, and restricted network access with network policies. Is that enough for peace of mind? Well, it might be, but then again, it might not. Threat actors and their tactics evolve daily, and what appears secure today might not be tomorrow. In our imperfect world, bugs, misconfigurations, and other errors happen regularly. Stay vigilant, keep an eye out, and maintain constant monitoring of your deployments.

Fortunately, there are numerous tools available for monitoring and alerting, ranging from free to paid, simple to sophisticated, self-hosted to fully managed. There's no excuse not to utilize them. Monitor resource usage and set alerts for unexpected spikes, watch for brute-force and DDoS attempts, and pay attention to unexpected errors and service crashes. If your service or product is publicly accessible, I guarantee, monitoring data will reveal a lot of unexpected stuff about what's happening while you're catching some sleep 🙂

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Thank you for being a part of the community!

Q3 2023 update - Notifications

Aleh Zasypkin — Tue, 17 Oct 2023 10:00:00 +0000

The original post was published on my blog on September 5, 2023.

Hello!

With just one month remaining in the "Q3 2023 - Jul-Sep" milestone (this is how I structure my roadmap), I wanted to provide a quick progress update. A significant deliverable for this milestone includes adding support for email notifications and other transactional emails.

Notifications, in general, and email notifications, specifically, are integral to any product that involves any monitoring or tracking activities. Secutils.dev already includes, and will continue to expand, features that require the ability to send notifications. Two notable examples include sending notifications for changes detected by the web page resources trackers and changes detected in the tracked content security policies (CSP).

Of course, I don't have infinite resources or time to architect different notification solutions for various use cases. Therefore, the notifications subsystem must be flexible and robust enough to cover all of today's needs and those that might arise in the near future. This includes seemingly unrelated use cases, such as new account activation emails, password reset emails, and even contact form messages. If you take a moment to think about it, you'll realize that these are essentially just different types of notifications.

For now, a fairly simple Notification definition (shown below) covers all my immediate needs:

/// Defines a notification.
#[derive(Debug, Clone, Eq, PartialEq)]
pub struct Notification {
    /// Unique id of the notification.
    pub id: NotificationId,
    /// The destination of the notification (e.g. registered user, email or server log).
    pub destination: NotificationDestination,
    /// The content of the notification (e.g. simple text or HTML email).
    pub content: NotificationContent,
    /// The time at which the notification is scheduled to be sent, in UTC.
    pub scheduled_at: OffsetDateTime,
}
---
// Example #1: Resources tracker detected changes in the web page reso
Notification::new(
    NotificationDestination::User(12345),
    NotificationContent::Text(format!(
        "Web page resources tracker {} ({}) detected changes in resources.",
        tracker.name, tracker.url
    )),
    OffsetDateTime::now_utc()
)
---
// Example #2: New account activation email
Notification::new(
    NotificationDestination::Email("12@34.56".to_string()),
    NotificationContent::Email(NotificationEmailContent::html(
        "Activate you Secutils.dev account",
        // Plain text fallback for simple email clients.    
        format!("To activate your Secutils.dev account…"),
        // HTML email for advanced email clients.
        format!(r#"
<!DOCTYPE html>
<html>
  <head><title>Activate your Secutils.dev account</title>…</head>
  <body><h1>Activate your Secutils.dev account</h1>…</body>
</html>"#)
    )),
    OffsetDateTime::now_utc()
)

To compose and send emails, I rely on an incredible open-source Rust library called Lettre.

Sending notifications over the network can be quite resource-intensive, and I don't want to let it affect the user experience or block the primary functionality of Secutils.dev. To deal with this, I've implemented a system where notifications are sent in a separate thread. Besides, Secutils.dev doesn't send notifications immediately. Instead, it schedules them for batch delivery at regular intervals. Scheduling notifications is very lightweight, essentially as cheap as inserting a single row into a SQLite database.

As I previously covered in my “Building a scheduler for a Rust application” post, I rely on Tokio Cron Scheduler for various routine background tasks, and one such task runs every 30 seconds (although the default value, it's configurable). This task checks if there are any pending notifications ready for dispatch. Fortunately, the extra 30-second delay doesn't significantly impact my use cases, but it allows me to manage the load more effectively. This approach works equally well for both near-real-time notifications and those scheduled for future delivery.

The notification sending job also tracks the time taken to send each batch of notifications, recording this data in the server log. This information is then captured by my monitoring setup. This monitoring approach helps me determine when it's necessary to fine-tune or scale up my notifications setup.

Speaking of scalability, the separation between the code responsible for preparing notifications and the code handling their actual transmission gives me the flexibility to scale my notification system easily. I can achieve this by deploying one or more dedicated Secutils.dev server instances solely tasked with serving pending notifications. These dedicated instances may have entirely different hardware profiles optimized just for this purpose.

Today, Secutils.dev exclusively supports two types of notification destinations: email and the server log. The rationale for requiring email notifications is self-evident. However, it's worth shedding light on the server log as a notification destination. Utilizing the server log as a notification destination is not only very handy for debugging purposes but also serves as an integration channel between Secutils.dev and the Elastic Stack monitoring system. All server logs are ingested into the Elasticsearch instance I've deployed for monitoring. I've crafted a dedicated dashboard and several visualizations within Kibana to specifically monitor server log notifications, leveraging the [Notification] log record prefix. This allows me to track and visualize any imaginable custom application metric.

As it's set up right now, the notifications system can be expanded to include more destinations like Slack, Telegram, browser push notifications, or any other third-party webhook with minimal tweaks. And speaking of the future, once Secutils.dev makes it out of beta, I'll be handling more sophisticated transactional or marketing emails, and planning to add Loops as the notification destination. Loops is a nice service positioned as "Email for modern SaaS". They also offer a pretty generous free plan, check it out!

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Thank you for being a part of the community!

The best application security tool is education

Aleh Zasypkin — Tue, 10 Oct 2023 10:00:00 +0000

The original post was published on my blog on August 29, 2023.

Hello!

ℹ️ NOTE: Although not directly related to this topic, I encourage you to take a look at the latest US national cyber security workforce and education strategy from July 31, 2023. The thumbnail picture for this post is taken from there. It's an interesting read!

As you might have guessed, I spend a lot of time thinking about application security - almost every day, in fact. At my day job, I'm constantly pondering how to enhance Kibana's security in a scalable manner without overburdening my already hardworking team. Outside of work, I'm equally dedicated to making Secutils.dev even more valuable to fellow engineers looking for better security tools.

While I'd love to tell you there's a magic tool or a combination of tools that can make your application completely secure, I don't believe it's quite that simple - at least not yet. If you're working within tight budget constraints, resist the urge to spend it all on solutions like Veracode, Snyk, Secutils.dev, or any other security tool. Also, don't obsess over supply chain security and penetration testing just yet. Instead, focus your initial investment on something absolutely critical - educating your engineers about security. You'll reap the rewards, and so will your team. Only once you have a solid educational program or processes in place should you consider investing in additional security-oriented tools.

I do appreciate various application security tools. Many of them are great and significantly simplify my life as a security engineer. However, none of these tools can prevent developers from inadvertently exposing sensitive information in logs, accidentally sending error stack traces in API responses, caching authorization results in memory, hardcoding S3 bucket names and URLs for third-party services, or neglecting to invalidate access tokens when they are no longer necessary.

This isn't a fault of the developers though. They might not even be aware that what they're doing could be exploited by a malicious actor with sufficient motivation. Engineers are a creative group, and they can unintentionally craft a vulnerable piece of code in a way that prevents detection by any code or security scanner. While it's clear to engineers that code should be performant (just think of all these technical interview questions and tasks related to code performance, complexity, and efficiency), it's unfortunately less evident that code should also be as secure, if not more so.

Many of my colleagues and I have experimented with various approaches to enhance the security situation: conducting code security reviews, writing documentation outlining security best practices, advocating for more secure programmatic APIs, and incorporating tools like Snyk and CodeQL. These initiatives certainly help, but they don't always scale efficiently unless engineers begin to consider security with the same seriousness as they do performance and maintainability.

Historically, security was often an afterthought for the majority of software engineers. This was primarily because security breaches and data leaks were not as frequent, dramatic, or devastating as they are today. As more aspects of our lives become digital, and this shift continues to accelerate, along with the slow but steady evolution of government regulations, I believe, we should change this perception through education. This education should extend to specific teams, organizations, and entire company, and the investment will undoubtedly pay off over time.

If you really care about security, make software security trainings mandatory and recurring, just like other compulsory training sessions related to topics like equal treatment and work ethic, which are common today. All these training sessions are important and can literally impact people's lives. Also, actively ask for a feedback and continually update the training content. Admittedly, it's easier said than done, but...

When you onboard a new engineer, consider sending them something more meaningful than just another useless branded mug – perhaps a book on application security or a prepaid voucher for a security training course. This gesture will send a clear message from day one that security is an important concern for your company, not merely a nice-to-have. And I beg you, if you offer security training or host internal security-focused hackathons, avoid making them optional or scheduling them after working hours. Otherwise, they won't be taken as seriously – I know I wouldn't.

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Thank you for being a part of the community!

Useful newsletters and podcasts for indie web developers

Aleh Zasypkin — Thu, 05 Oct 2023 10:00:00 +0000

The original post was published on my blog on August 22, 2023.

Hello!

I'm sharing a quick post today to highlight a few newsletters and podcasts that I, as an indie developer, find useful. Hopefully, they'll be of use to you too. This post is deliberately brief because I firmly believe that the most effective way to learn something new is to start doing it. Hands-on experience is and always was the master key to personal growth. There's no real shortcut, you can't absorb it all from reading a blog post or tuning into a podcast.

However, that doesn't mean I've sworn off reading, watching, and listening to learn new things or get inspired. I do partake, but I keep it to a bare minimum. In general, I try hard to focus on "creating" over "consuming." Now, let's get to it:

JavaScript Weekly and Node Weekly

These newsletters are among the best sources to stay up-to-date with the latest happenings in JavaScript, web development, and Node.js. They conveniently categorize content into sections like new releases, articles & tutorials, and code & tools. Since I use JavaScript/TypeScript and Node.js extensively, both in my day job and for Secutils.dev, I have to stay informed about developments in these essential tools. Usually, I quickly scan through the newsletter and focus only on the items that grab my attention — it doesn't consume much time but keeps me well-informed.

This Week in Rust

This newsletter is like JavaScript Weekly but for Rust! It provides updates from the Rust community, highlights updates from the vital Rust projects, shares new ideas and thoughts, offers guides, updates from the Rust core teams, and, sometimes, introduces brand new Rust crates. Rust is my passion and the primary programming language I use for the Secutils.dev Server. Every time I read this newsletter, I discover something new and exciting about Rust!

Software Lead Weekly

This is a curated and condensed newsletter that focuses on people, culture, and leadership in the tech industry. The content selected for this newsletter often resonates with me and even adds a touch of humor. Human beings are complex, and investing in understanding them better always yields significant returns. I hope you too can find valuable insights in this newsletter.

Indie Hackers newsletter and podcast

These resources are invaluable for anyone interested in early-stage entrepreneurship. They provide real-life experiences from people worldwide who have ventured to build something, whether successfully or not. This contrasts with the abundance of self-proclaimed experts, thought leaders, and book authors who often lack substantial hands-on experience. Personally, I find greater value in reading about the personal experiences of individuals from various backgrounds who attempted to create small products, even if they didn't succeed, than in consuming the "synthetic" thoughts of bestselling authors (👋 Simon Sinek & Friends).

Y Combinator YouTube channel

Whether you're in the process of building a tech product or just contemplating it, I highly recommend exploring this channel, even if you have no intention of applying to YC. The team offers a wealth of valuable insights, founder anecdotes, and startup guidance that can be challenging to come by elsewhere.

Bonus: The idea farm newsletter

While it's undeniable that "hard", "soft", and entrepreneurial skills are very important for those looking for independence and self-sufficiency, there are other universal skills that shouldn't be overlooked. As I mentioned in my "Personal Finances and Indie-Project Budget" post, I'm a strong advocate for financial literacy and maintaining healthy personal finances. I'm constantly in learning mode in this area, and seeking ways to preserve and invest the money I have.

That's why I really like The Idea Farm newsletter, which provides free access to quite unique investment research and ideas. Many of these align neatly with my personal investment philosophy, making it quite an enjoyable read!

That wraps up today's post, thanks for taking the time to read it!

ℹ️ ASK: If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository.

Also, feel free to follow me on Twitter, Mastodon, or LinkedIn.

Thank you for being a part of the community!

DEV Community: Aleh Zasypkin

A primer on open-source intelligence for bug bounty hunting in Grafana

Keep your focus narrow

GitHub CODEOWNERS file

Automating change tracking

But wait, there's more

Cybersecurity basics: security mindset

Explore unhappy path

Assume compromise

Avoid insecurity through obscurity

Be pragmatic about security

Always be learning

Example: logs and exceptions

Supercharge your app with user extensions using Deno JavaScript runtime

Picking the extensions "framework"

Using Deno Core as extensions runtime

Dealing with malfunctioning and malicious extensions

Monitoring user extensions

Script execution time

Script terminations and crashes

Overall memory consumption

How to track anything on the internet or use Playwright for fun and profit

Example: Trending GitHub repositories

How it works

What's next

Explore web applications through their content security policy (CSP)

Google

Bing

DuckDuckGo

Bonus: ChatGPT

Two simple rules for better and more secure code

Don't log what you don't know

Don't expose raw errors

Q4 2023 iteration: tracking arbitrary web content, user-specific webhook subdomains, inherited CSP, and more

Tracking arbitrary web content

User-specific webhook subdomains

Inherited content security policies (CSP)

Sharing & collaboration

Announcing 1.0.0-alpha.3 release: more powerful resource tracking, notifications and content sharing

Scheduled resources checks

Email notifications for changed resources

Custom resources filtering and mapping

Sharing & collaboration

Other enhancements and bug fixes

Running web scraping service securely

Input validation

Resource isolation

Privilege management

Browser sandbox

Network policies

Monitoring

Q3 2023 update - Notifications

The best application security tool is education

Useful newsletters and podcasts for indie web developers

JavaScript Weekly and Node Weekly

This Week in Rust

Software Lead Weekly

Indie Hackers newsletter and podcast

Y Combinator YouTube channel

Bonus: The idea farm newsletter

GitHub `CODEOWNERS` file