DEV Community: wennan xu

Monilith vs Monorepo

wennan xu — Sun, 28 Sep 2025 05:15:09 +0000

Thread safe strategy in Java or .net

wennan xu — Mon, 15 Sep 2025 11:25:56 +0000

Stateless design

Just like in Java, designing classes without shared mutable state is the safest approach.

public class MyProcessor
{
    public string Process(string input)
    {
        return input.ToUpper(); // No shared state
    }
}

ThreadLocal

ThreadLocal is a .NET class that allows you to store data that is local to a specific thread. Each thread accessing a ThreadLocal instance gets its own independent copy of the data.

private static ThreadLocal<Random> random = new ThreadLocal<Random>(() => new Random());

public int GetRandomNumber()
{
    return random.Value.Next();
}

Synchronized blocks

Use lock (or Monitor) to protect shared resources.

private readonly object _lock = new object();
private List<string> _sharedList = new List<string>();

public void AddItems(List<string> items)
{
    lock (_lock)
    {
        _sharedList.AddRange(items);
    }
}

ReentrantLock — More powerful, flexible locking with timeout

ReentrantLock lock = new ReentrantLock();

try {

    acquired = lock.tryLock(500, TimeUnit.MILLISECONDS);
    if (acquired) {
        System.out.println("Lock acquired, doing work...");
        // critical section
        Thread.sleep(1000); // simulate work
    } else {
        System.out.println("Could not acquire lock within timeout.");
    }
} finally {
    lock.unlock();
}

ReentrantReadWriteLock — More powerful and more flexible, providing two locks - readLock and writelock with timeout, Effect: Multiple threads can read concurrently. Only one thread can write, and it blocks all readers.

Concurrency: Much better for read-heavy workloads.


private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();
private final Lock writeLock = rwLock.writeLock();

public String read(String key) {
    readLock.lock();
    try {
        return sharedMap.get(key);
    } finally {
        readLock.unlock();
    }
}

public void write(String key, String value) {
    writeLock.lock();
    try {
        sharedMap.put(key, value);
    } finally {
        writeLock.unlock();
    }
}

Thread-safe collections

Thread-safe collections are designed to handle concurrent access without requiring manual locking.
Common Thread-Safe Collections in .NET

Collection               Use Case
ConcurrentDictionary    Key-value store with safe concurrent access
ConcurrentQueue         FIFO queue for producer-consumer scenarios
ConcurrentStack         LIFO stack for concurrent access
ConcurrentBag           Unordered collection for fast insert/retrieve
BlockingCollection  Thread-safe wrapper for producer-consumer with blocking and bounding

Partitioning

Similar to Spring Batch partitioning, you can divide work into chunks and assign each to a separate thread or task.

Parallel.ForEach(partitions, partition =>
{
    ProcessPartition(partition);
});

Immutable data

Immutable types are inherently thread-safe. You can use records or readonly structs in C#.

public record Person(string Name, int Age);

OWASP Top 10 2025

wennan xu — Mon, 15 Sep 2025 03:12:02 +0000

A01:2025 – Broken Access Control

Access control flaws occur when users are allowed to perform actions outside their permission scope, such as accessing another user’s data or modifying records.

Implement role-based access control (RBAC) to ensure users only have access to the data and functions they need.
Regularly audit user permissions to remove unnecessary privileges.
Enforce multi-factor authentication (MFA) for critical operations to add an additional layer of security.

A02:2025 – Injection attacks, particularly SQL injection

Always sanitize and validate user inputs to prevent the execution of untrusted commands.
Use parameterized queries or prepared statements to safely process database inputs.
Implement Web Application Firewalls (WAF) to detect and block injection attempts.

A03:2025 – Insecure Design (Combined with Security Logging and Monitoring Failures)

Adopt threat modeling early in the development cycle to identify potential security risks.
Use security frameworks and libraries that enforce secure design principles.
Ensure all critical systems have comprehensive logging in place.
Use real-time monitoring tools to detect unusual activity.
Regularly audit logs to ensure compliance with security policies.

A04:2025 – Identification and Authentication Failures

Authentication failures can lead to severe security breaches, allowing attackers to impersonate legitimate users. This vulnerability includes weak passwords, missing multifactor authentication (MFA), and flawed session management.

Enforce strong password policies with minimum complexity requirements.
Implement multifactor authentication (MFA) to add an additional layer of protection.
Use secure, industry-standard session management techniques, including secure tokens and cookies.

A05:2025 – Cryptographic Failures

Use strong encryption algorithms such as AES-256 and ensure proper key management.
Avoid outdated cryptographic methods like MD5 or SHA-1, as they are prone to attacks.
Regularly update and patch encryption libraries to safeguard against newly discovered vulnerabilities.

A06:2025 – Security Misconfiguration

Security misconfigurations occur when default settings, incomplete configurations, or errors in security settings leave applications vulnerable to attack.

Regularly audit and harden configurations to meet industry security standards.
Disable unused features and services to reduce the attack surface.
Use automated configuration management tools to ensure consistency across environments.

A07:2025 – Vulnerable and Outdated Components

Use automated tools such as Dependabot or Snyk to monitor and update third-party components.
Regularly review and update dependencies to ensure they are secure.
Employ software composition analysis (SCA) tools to identify and mitigate risks in your application’s dependencies.

A08:2025 – Software and Data Integrity Failures

This vulnerability occurs when software updates, critical data, or infrastructure components are not properly secured, leading to unauthorized changes that compromise system integrity.

Sign and verify software updates to ensure their integrity.
Implement integrity checks on critical data to detect tampering.
Regularly monitor and verify the integrity of infrastructure components.

Server-Side Request Forgery (SSRF): The Emerging Threat

SSRF vulnerabilities occur when an attacker can manipulate a server to send unauthorized requests to other systems, potentially bypassing firewalls and exposing sensitive data. As microservices and cloud applications become more prevalent, SSRF is becoming a growing concern.

Real-World Impact:

In 2021, an SSRF vulnerability in Microsoft Azure exposed sensitive internal information, highlighting the growing risks of this attack vector in cloud environments.

Mitigation Strategies:

Implement input validation to prevent attackers from injecting malicious URLs.
Restrict outbound network access to limit the scope of SSRF attacks.
Use firewalls and network segmentation to protect critical systems from unauthorized requests.

How to use pgpainless-core

wennan xu — Sun, 09 Mar 2025 00:02:38 +0000

Document

https://pgpainless.readthedocs.io/en/latest/quickstart.html

Setup

// If you use Gradle
...
dependencies {
    ...
    implementation "org.pgpainless:pgpainless-core:1.7.2"
    ...
}

// If you use Maven
...
<dependencies>
    ...
    <dependency>
        <groupId>org.pgpainless</groupId>
        <artifactId>pgpainless-core</artifactId>
        <version>1.7.2</version>
    </dependency>
    ...
</dependencies>

What's ASCII Armor

ASCII armor is a layer of radix64 encoding that can be used to wrap binary OpenPGP data in order to make it save to transport via text-based channels (e.g. email bodies).

The way in which ASCII armor can be applied depends on the type of data that you want to protect. The easies way to ASCII armor an OpenPGP key or certificate is by using PGPainless’ asciiArmor() method:

PGPPublicKey certificate = ...;
String asciiArmored = PGPainless.asciiArmor(certificate);

How to Setup the ProducerOptions when Encrypt

Suppose you have a FileInputStream or ByteArrayInputStream. Then also you need to have a OutputStream, like

OutputStream outputStream =
                        Files.newOutputStream(outputFileLocation, StandardOpenOption.CREATE_NEW);

Before you call the Painless.encryptAndOrSign(), you need to build up the ProducerOptions. It will be like

/** The secret key ring used for decrypting and signing. */
private final PGPSecretKeyRing secretKeyRing = ...;

/** The public key ring used for encrypting. */
private final PGPPublicKeyRing publicKeyRing = ...;

/** Stores the password securely, required to access the secret key. */
private final SecretKeyRingProtector secretKeyRingProtector = ...;

SigningOptions signOptions = SigningOptions.get().addInlineSignature(secretKeyRingProtector, secretKeyRing);

when you try to build your secretKeyRing and secretKeyRingProtector, you probably will get it from your properties like

this.secretKeyRing = armorStringKeyringLoader.load(properties.getSecretKey(), PGPSecretKeyRing.class)

this.publicKeyRing = armorStringKeyringLoader.load(properties.getPublicKey(), PGPPublicKeyRing.class)

In order to load the key, all you need to do is to get the BufferedInputStream, then

protected <T extends PGPKeyRing> T readKeyRing(BufferedInputStream keyInputStream, Class<T> clazz) throws IOException, KeyRingLoaderException {
    if (clazz.isAssignableFrom(PGPSecretKeyRing.class)) {
        return clazz.cast(PGPainless.readKeyRing().secretKeyRing(keyInputStream));
    } else if (clazz.isAssignableFrom(PGPPublicKeyRing.class)) {
        return clazz.cast(PGPainless.readKeyRing().publicKeyRing(keyInputStream));
    } throw new KeyRingLoaderException(
        String.format("Unsupported key ring type [class=%s]", clazz.getSimpleName()));
    }
}

Create that BufferedInputStream from string can be like

public BufferedInputStream getBufferedInputStreamForKey(String armorKey) throws Exception {
        // return a new BufferedInputStream with the key as the content.
        ByteSource byteSource = ByteSource.wrap(armorKey.getBytes());
        return new BufferedInputStream(byteSource.openStream());
    }

Or create that BufferedInputStream from file can be like

public BufferedInputStream getBufferedInputStreamForKey(String armorKeyfileLocation) throws IOException {
    // Loads the ascii armor key file from the file system.
    return (BufferedInputStream) Files.asByteSource(new File(armorKeyfileLocation)).openBufferedStream();
}

Now lets build the encryptionOptions. You only need to add the recipient's public key as the

PGPPublicKey certificate = ...;
EncryptionOptions encOptions = EncryptionOptions.get().addRecipient(certificate);

Same philosophy to load the PGPPublicKey via PGPainless.readKeyRing().publicKeyRing(keyInputStream).

So now we can put both of them into the ProducerOptions options like

ProducerOptions options = ProducerOptions.signAndEncrypt(signingOptions, encryptionOptions);

If you want to ASCII armor ciphertext, you can enable ASCII armoring during encrypting/signing by requesting PGPainless to armor the result:

producerOptions.setAsciiArmor(true); // enable armoring

File Association: When you encrypt data, you might want to include the original file name so that the recipient knows what the encrypted content represents. The setFileName method allows you to set this file name.
Metadata: Including the file name as metadata can help the recipient understand the context of the encrypted data, especially if multiple files are being encrypted and sent together. So you can do like:
producerOptions.setFileName(outputFileLocation.toString()).

Encrypt with the OutputStream

EncryptionStream encryptionStream = PGPainless.encryptAndOrSign()
        .onOutputStream(outputStream)
        .withOptions(producerOptions);

Encrypt the file data

If you already have an existing file, you can encrypt it to another file location like

InputStream plaintext = ...; // The data that will be encrypted and/or signed
ByteArrayInputStream contentToEncrypt = ...; // can also be the ByteArrayInputStream 
OutputStream ciphertext = Files.newOutputStream(Path outputFileLocation, StandardOpenOption.CREATE_NEW); // Destination for the ciphertext

EncryptionStream encryptionStream = PGPainless.encryptAndOrSign()
        .onOutputStream(ciphertext)
        .withOptions(producerOptions); // pass in the options object

Streams.pipeAll(plaintext, encryptionStream); // pipe the data through
encryptionStream.close(); // important! Close the stream to finish encryption/signing

EncryptionResult result = encryptionStream.getResult(); // metadata

Use the EncryptionStream in Spring batch OutputStreamWriter.

As EncryptionStream is also a sub-class of OutputStream, so we can wrap it into the Spring batch writer like

new OutputStreamWriter(EncryptionStream, StandardCharsets.UTF_8);

So now we will get a Encrypted output stream, we can write the encrypted data into the output stream in Spring batch.

How to Setup the ConsumerOptions when Decrypt

new ConsumerOptions()
.addDecryptionKey(SecretKeyRing, SecretKeyRingProtector)
.addVerificationCert(PublicKeyRing)

Build the DecryptionStream

// this is the file we are going to decrypt
InputStream inputStream = Files.newInputStream(inputFileLocation, StandardOpenOption.CREATE_NEW);

DecryptionStream decryptionStream = PGPainless.decryptAndOrVerify()
    .onInputStream(inputStream)
    .withOptions(ConsumerOptions)

Reuse this DecryptionStream in Spring batch reader

new InputStreamWriter(decryptionStream, StandardCharsets.UTF_8);

Decrypt the file

if you have an existing encrypted file, and you want to decrypt it to another file location. You can initialize the ByteArrayOutputStream which will receive the decrypted data.

ByteArrayOutputStream decryptedContentOutput;
Streams.pipeAll(decryptionStream, decryptedContentOutput);
// must close before we can get the metadata.
decryptionStream.close();
MessageMetadata messageMetadata = decryptionStream.getMetadata();
logCompleted(messageMetadata, inputFileLocation);

SameSite cookies and CSRF explained

wennan xu — Mon, 14 Oct 2024 06:15:42 +0000

We might normally heard the terms of SameSite and CSRF, What are they on the earth, and what's the relationship between them?

What is HTTP cookies

A cookie (also known as a web cookie or browser cookie) is a small piece of data a server sends to a user's web browser. The browser may store cookies, create new cookies, modify existing ones, and send them back to the same server with later requests. Cookies enable web applications to store limited amounts of data and remember state information; by default the HTTP protocol is stateless.
Typically, the server will use the contents of HTTP cookies to determine whether different requests come from the same browser/user and then issue a personalized or generic response as appropriate.

The user sends sign-in credentials to the server, for example via a form submission.
If the credentials are correct, the server updates the UI to indicate that the user is signed in, and responds with a cookie containing a session ID that records their sign-in status on the browser.
At a later time, the user moves to a different page on the same site. The browser sends the cookie containing the session ID along with the corresponding request to indicate that it still thinks the user is signed in.
The server checks the session ID and, if it is still valid, sends the user a personalized version of the new page. If it is not valid, the session ID is deleted and the user is shown a generic version of the page (or perhaps shown an "access denied" message and asked to sign in again).

What is a site in the context of SameSite cookies?

Firstly we need to understand what is same site and what is same origin.

Request from	Request to	Same-site?	Same-origin?
`https://example.com`	`https://example.com`	Yes	Yes
`https://app.example.com`	`https://intranet.example.com`	Yes	No: mismatched domain name
`https://example.com`	`https://example.com:8080`	Yes	No: mismatched port
`https://example.com`	`https://example.co.uk`	No: mismatched eTLD	No: mismatched domain name
`https://example.com`	`http://example.com`	No: mismatched scheme	No: mismatched scheme

How does SameSite work?

All major browsers currently support the following SameSite restriction levels:

Strict：If a cookie is set with the SameSite=Strict attribute, browsers will not send it in any cross-site requests. This is recommended when setting cookies that enable the bearer to modify data or perform other sensitive actions, such as accessing specific pages that are only available to authenticated users.

Although this is the most secure option, it can negatively impact the user experience in cases where cross-site functionality is desirable.

Lax：Lax SameSite restrictions mean that browsers will send the cookie in cross-site requests, but only if both of the following conditions are met:
- The request uses the GET method.
- The request resulted from a top-level navigation by the user, such as clicking on a link.

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

With a cookie set to Lax as follows: Set-Cookie: promo_shown=1; SameSite=Lax
When the browser requests amazing-cat.png for the other person's blog, your site doesn't send the cookie. However, when the reader follows the link to cat.html on your site, that request does include the cookie.

We recommend using SameSite in this way, setting cookies that affect website display to Lax, and cookies related to user actions to Strict.

None：If a cookie is set with the SameSite=None attribute, this effectively disables SameSite restrictions altogether, regardless of the browser. As a result, browsers will send this cookie in all requests to the site that issued it, even those that were triggered by completely unrelated third-party sites. When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them: Set-Cookie: widget_session=abc123; SameSite=None; Secure

Bypassing SameSite Lax restrictions using GET requests

As long as the request involves a top-level navigation, the browser will still include the victim's session cookie. The following is one of the simplest approaches to launching such an attack:

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

Even if an ordinary GET request isn't allowed, some frameworks provide ways of overriding the method specified in the request line. For example, Symfony supports the _method parameter in forms, which takes precedence over the normal method for routing purposes:

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>

see we can put <input type="hidden" name="_method" value="GET"> in forms to override the override the original POST request.

Bypassing SameSite restrictions using on-site gadgets

One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.
DOM-based open-redirection vulnerabilities arise when a script writes attacker-controllable data into a sink that can trigger cross-domain navigation. For example, the following code is vulnerable due to the unsafe way it handles the location.hash property:

let url = /https?:\/\/.+/.exec(location.hash);
if (url) {
  location = url[0];
}

An attacker may be able to use this vulnerability to construct a URL that, if visited by another user, will cause a redirection to an arbitrary external domain.
As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.
How to prevent DOM-based open-redirection vulnerabilities, you should avoid dynamically setting redirection targets using data that originated from any untrusted source.

Bypassing SameSite Lax restrictions with newly issued cookies

Cookies with Lax SameSite restrictions aren't normally sent in any cross-site POST requests, but there are some exceptions.

As mentioned earlier, if a website doesn't include a SameSite attribute when setting a cookie, Chrome automatically applies Lax restrictions by default. However, to avoid breaking single sign-on (SSO) mechanisms, it doesn't actually enforce these restrictions for the first 120 seconds on top-level POST requests. As a result, there is a two-minute window in which users may be susceptible to cross-site attacks.

Note
This two-minute window does not apply to cookies that were explicitly set with the SameSite=Lax attribute.

References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions
https://web.dev/articles/samesite-cookies-explained