What is Open Redirection?

Open redirection occurs when a web application accepts a user-controlled input (such as a URL parameter) and redirects users to that location without proper validation.

Example:

https://example.com/redirect?url=https://malicious-site.com

If the application does not validate the url parameter, an attacker can craft a link that appears legitimate but redirects users to a malicious website.

Why is it Dangerous?

At first glance, open redirection might seem like a low-severity issue, but its real impact is often underestimated.

1. Phishing Attacks

Attackers can abuse trusted domains to trick users into visiting fake login pages.

2. Credential Theft

Users redirected to attacker-controlled sites may unknowingly enter sensitive information.

3. Token Leakage

In OAuth or authentication flows, tokens can be exposed via manipulated redirect URLs.

4. Bypassing Security Controls

Open redirects can sometimes be chained with other vulnerabilities to bypass access controls.

How Attackers Exploit It

Attackers use various techniques to bypass weak validation:

• URL encoding (%68%74%74%70%73://evil.com)
• Double encoding
• Using subdomains (trusted.com.attacker.com)
• Protocol-relative URLs (//evil.com)
• Mixing HTTP and HTTPS
• Exploiting poorly implemented allowlists

Real-World Attack Scenario

1. Attacker crafts a malicious URL using a trusted domain:

https://trusted-site.com/login?next=https://evil.com

2. Victim clicks the link believing it is legitimate.

3. The application redirects the user to the attacker’s website

4. The user enters credentials on a fake login page

5. Attacker captures sensitive information

How to Identify Open Redirection

Security testers typically:

1. Look for parameters like:

• redirect
• url
• next
• returnUrl

2. Modify values to external domains

3. Test encoded and obfuscated payloads

4. Analyze behavior in authentication and password reset flows.

Prevention Techniques

To mitigate open redirection vulnerabilities, organizations should implement the following:

1. Use Allowlists

Only allow redirection to trusted, predefined domains.

2. Avoid Direct User Input

Do not use user-controlled URLs directly for redirection.

3. Validate and Normalize URLs

Ensure proper decoding and validation before processing.

4. Use Indirect References

Map user inputs to internal identifiers instead of full URLs.

5. Restrict External Redirects

Block or warn users before redirecting to external domains.

6. Secure Authentication Flows

Carefully validate redirect URIs in OAuth and login systems.

Best Practices for Developers

• Implement strict server-side validation
• Avoid relying on client-side checks
• Use frameworks that provide secure redirect handling
• Regularly test applications for URL-based vulnerabilities
• Conduct secure code reviews

Conclusion

Open redirection vulnerability is a subtle yet powerful security risk that can significantly impact users and organizations when exploited. By understanding how it works and implementing proper validation and control mechanisms, businesses can protect their users from phishing attacks and maintain trust in their platforms.

In this blog, we will explore what CSTI is, how it works, the risks it poses, and how you can protect your web applications from this dangerous attack.

What Is Client-Side Template Injection (CSTI)?

Client-Side Template Injection (CSTI) is a vulnerability that arises when user-controlled input is incorporated into client-side templates without proper sanitization. In simpler terms, it’s when an attacker can inject their own code into a template that is rendered in the browser.

Templating engines are commonly used in modern web applications to dynamically generate HTML content. These engines take a template (an HTML structure with placeholders) and inject dynamic data into it (like user names, profile pictures, etc.) when the page is loaded.

The problem arises when the data being inserted into the template is directly controlled by the user, and the application fails to sanitize it before rendering. This opens up the potential for an attacker to inject malicious code into the template, which will then execute in the user’s browser.

How Does CSTI Work?

To better understand how CSTI works, let’s break down the process:

1. Templating Engine Integration: Many modern web frameworks and libraries, like Angular, Vue.js, and React, use templating engines to insert dynamic content into HTML pages.
2. User Input: Web applications often take input from users, such as search terms, form data, or query parameters, and incorporate it into templates. If an attacker can manipulate this user input (for example, through URL parameters), they might be able to inject their own content.
3. Lack of Sanitization: If the web application does not properly sanitize or escape the user input, the injected data might be processed as part of the template, potentially executing malicious code on the client side.
4. Template Execution: When the template is rendered in the browser, the malicious code gets executed, either by manipulating the DOM (Document Object Model) or by triggering specific client-side vulnerabilities (like JavaScript execution).

Example of CSTI Attack

Imagine a web application where a user can search for items by entering a query into a search box. The application uses a templating engine to display the results. For instance, it may take a search query like this:

<h1>Search results for: {{ searchQuery }}</h1>

Here, {{ searchQuery }} is a placeholder that gets replaced by the actual search term entered by the user.

However, if the application fails to sanitize the user input, an attacker could craft a search query like:

{{ 7*7 }}

This input would cause the templating engine to evaluate the expression 7*7, which could potentially result in arbitrary JavaScript code execution or even a more complex attack that exploits other client-side vulnerabilities.

In a more dangerous scenario, the attacker could inject malicious JavaScript into the template, potentially stealing cookies or other sensitive data from the user’s browser.

Risks of CSTI

CSTI can lead to a variety of severe security risks, including:

1. Cross-Site Scripting (XSS): CSTI is essentially a variant of XSS, where malicious code gets executed in the user’s browser. If the attacker injects JavaScript code into the template, it could execute in the context of the user’s session, stealing sensitive data like authentication tokens or cookies.
2. Data Exfiltration: An attacker can steal sensitive information, such as user data or session tokens, by injecting JavaScript into the template.
3. Cross-Site Request Forgery (CSRF): CSTI can also be used as a vector for CSRF attacks, where malicious JavaScript on a page sends requests on behalf of an authenticated user without their consent.
4. Denial of Service (DoS): If the template engine evaluates malicious input in a way that causes excessive computation or infinite loops, an attacker could overload the server, potentially causing a denial of service.
5. Privilege Escalation: If the attacker can inject certain expressions or functions into the template, they could escalate their privileges on the system, gaining unauthorized access to resources.

How to Protect Against CSTI

Protecting your web applications from Client-Side Template Injection requires a multi-layered approach. Here are some best practices to mitigate this vulnerability:

1. Validate and Sanitize User Input

One of the most effective ways to prevent CSTI is to validate and sanitize all user inputs. Ensure that inputs like query parameters, form data, or URL parameters are strictly controlled and only accept expected values.

For example:

• Reject any input that contains characters like <, >, or {{ }}, which are typically used in templating engines.
• Use a whitelist approach by defining exactly what type of input is valid (e.g., alphanumeric characters, no special characters).

2. Escape User Input

If your application needs to display user input in the template, ensure that the input is properly escaped to prevent it from being interpreted as part of the template. Many templating engines provide functions or built-in mechanisms to escape characters that could lead to code execution.

3. Use Templating Engines with Built-in Protection

Choose templating engines that have automatic escaping mechanisms to prevent client-side injection. For instance:

• Handlebars (JavaScript) automatically escapes variables inserted into templates by default.
• Angular and React sanitize data automatically before rendering it to the DOM.

If you are using a templating engine that does not have automatic sanitization, consider switching to one that does or implementing your own escape mechanisms.

4. Content Security Policy (CSP)

Implementing a Content Security Policy (CSP) can reduce the impact of CSTI attacks. By setting strict CSP headers, you can limit where scripts can be loaded from and what they can do, thus preventing malicious scripts from executing even if they are injected into the page.

Conclusion

Client-Side Template Injection (CSTI) is a dangerous vulnerability that can lead to a variety of attacks, including Cross-Site Scripting (XSS), data exfiltration, and more. By understanding how CSTI works and following best practices like input validation, escaping user data, and using templating engines with built-in protection, you can significantly reduce the risk of a successful attack.

As web applications become more complex, security needs to be a top priority. By adopting secure coding practices and continuously auditing your code, you can ensure that your users’ data remains safe and that your application stays protected against evolving threats.

What is Hashing?

Before diving into salt hashing, it’s important to first understand what hashing is. Hashing is the process of converting a piece of data (like a password) into a fixed-size string of characters, typically using a cryptographic hash function. The output, often referred to as the hash value, is a one-way transformation — meaning it cannot easily be reversed to reveal the original input.

For example, the password “password123” might be hashed using an algorithm like SHA-256, resulting in a hash like:

ef92b778bafe771e89245b6a2f72c8f3b44178e9f81e96bcbb99d2ef54296c22

In theory, even if someone gains access to the hash, they cannot easily retrieve the original password.

Why Hashing Alone Isn’t Enough

While hashing is a powerful technique, there are a few limitations. One significant issue is that if two users have the same password, they will have the same hash value. This makes it easier for attackers to identify users with common passwords in the event of a data breach. Additionally, attackers can use techniques like rainbow tables — precomputed lists of hash values for common passwords — to quickly find the corresponding plain-text password.

Enter Salt Hashing

To address these vulnerabilities, salt hashing was introduced. A salt is a random value that is added to the input of the hash function before hashing it. The salt ensures that even if two users have the same password, their hashes will be different because the salt values will be different.

How Salt Hashing Works

The process of salt hashing involves the following steps:

1. Generate a random salt: When a user creates or updates their password, the system generates a random salt. The salt is typically unique for each user.
2. Combine the password and the salt: The password is combined with the salt before it is hashed. This can be done by appending or prepending the salt to the password.
3. Hash the salted password: The salted password (the original password plus the salt) is then passed through a hash function.
4. Store the salt and hash: Both the salt and the resulting hash are stored in the system. When the user logs in, the system retrieves the salt, combines it with the entered password, hashes it, and compares the result with the stored hash.

For example, if the password is “password123” and the generated salt is “XyZ123”, the salted password would be:

password123XyZ123

This salted password is then hashed to produce a unique hash value that is stored.

Why Salt Hashing Matters

1. Prevents Rainbow Table Attacks: By adding a unique salt to each password before hashing, attackers cannot use precomputed rainbow tables. Even if two users have the same password, their hashes will differ due to the unique salts.
2. Makes Identical Passwords Unique: Without salt, identical passwords would produce identical hashes, making it easy for attackers to identify common passwords. Salt ensures that even identical passwords result in different hashes, making the system more secure.
3. Improves Protection Against Dictionary Attacks: In dictionary attacks, attackers try to guess a password by hashing common words or phrases. Salt significantly increases the complexity of these attacks by requiring the attacker to hash the salted password combinations individually.
4. Better Overall Security: Salt hashing enhances the security of passwords by making brute-force and other attacks far more time-consuming and resource-intensive, reducing the likelihood of successful unauthorized access.

Best Practices for Salt Hashing

While salt hashing is an essential security measure, there are several best practices to keep in mind to ensure it is implemented effectively:

1. Use a Long, Cryptographically Secure Salt: The salt should be sufficiently long (typically 16 bytes or more) and generated using a cryptographically secure random number generator. This ensures that the salt cannot be easily predicted.
2. Store Salts and Hashes Securely: Both the salt and the hash must be stored securely in the database. They should be stored in such a way that an attacker cannot access them easily.
3. Use a Strong Hashing Algorithm: Using a strong cryptographic hash function like bcrypt, Argon2, or PBKDF2 is important. These algorithms are specifically designed to be computationally expensive, slowing down brute-force attacks.
4. Consider Peppering for Added Security: While salts provide unique randomness, adding an additional layer of complexity (a pepper) can enhance security further. A pepper is another secret value that is added to the password before hashing. It’s not stored in the database, which makes it harder for attackers to guess.

Common Algorithms for Salt Hashing

Several modern algorithms support salt hashing by design, allowing developers to easily implement secure password hashing. Some of the most commonly used include:

• bcrypt: A popular and secure algorithm that automatically handles salting. It’s designed to be slow, making brute-force attacks more difficult.
• PBKDF2 (Password-Based Key Derivation Function 2): Another widely-used method that uses both a salt and multiple iterations of hashing to make the process slower and more resistant to attacks.
• Argon2: The winner of the Password Hashing Competition (PHC) and known for its resistance to both GPU and side-channel attacks. It’s the most modern and recommended password hashing algorithm.

Conclusion

Salt hashing is a simple yet powerful technique that significantly improves the security of passwords and other sensitive information. By adding randomness to each password hash, it ensures that even if two users share the same password, their stored hashes will be unique, protecting against common attacks like rainbow tables and dictionary-based brute force.

As security threats continue to evolve, implementing salt hashing along with strong hash algorithms and secure storage practices will ensure that your system remains resilient to attacks. Whether you’re developing a new application or reviewing an existing system, adopting salt hashing is a critical step in safeguarding user data and maintaining trust.