The Easiest Way to Bypass XSS Mitigations

628人阅读 评论(0) 收藏 举报

The most straightforward and reliable way to bypass any protection between a tester/attacker and a target application is to use some filtering practices against these very protections.

For a security reason or not, a developer makes some sort of filtering in his/her own code without realizing it can be used to trick any other device or code that will stand between his own and user of application. In this post we will see this affecting a WAF (Web Application Firewall) and a browser anti-XSS filter, both common mitigation solutions.

By using language native or custom functions, a developer can strip or replace what he/she thinks is a dangerous (or unnecessary) character or string. So let’s first see what happens when an application strips spaces from user input.

Here is a PHP page with reflections of 2 URL parameters, “p” and “q”. The first one, “p”, is just a simple

echo $_GET[“p”];

and then, because this page is not whitelisted in my WAF (Web Application Firewall) settings, we are not able to exploit this flaw in a common situation like we can see below. In fact, this (excellent) security solution from Sucuri, named CloudProxy, can detect the XSS attempt even without the alert(1) part, with just a “<svg onload=” input.


The second parameter, “q”, is there to exemplify the bypass. Here is its PHP code:

echo str_replace(“ ”, “”, $_GET[“q”]);

which replaces any white spaces from input. This is enough to trick CloudProxy and XSS Auditor, Google Chrome’s mitigation solution, at the same time.


By adding “+”, usually parsed as white spaces by applications, in strategic places of vector/payload, both security solutions fail because of stripping of a single character. No WAF can see this as a XSS attack because “<” is not immediately followed by a alphabetic character and Auditor can’t see this as similar enough to what is reflected in source, the way this solution uses to catch XSS attempts.

They stand between what is sent by an attacker and what is really echoed back by application, which is not necessarily the same. Without a minimum match there’s no way to identify it as malicious.

Another way to use application against security measures is by abusing char/string replaces. Here is another page, this time with 4 URL parameters, “p”, “q”, “r” and “s”. This page is white listed in WAF settings, because none of these will be enough to bypass it: the presence of this replaced string (“<script”) in every request triggers WAF blocking. But it will work against Auditor.

echo $_GET[“p”];
echo str_ireplace(“<script”, “”, $_GET[“q”]);
echo str_ireplace(“<script”,“InvalidTag”, $_GET[“r”]);
echo str_ireplace(“<script”,“<InvalidTag”, $_GET[“s”]);

As we can see below, using the “p” parameter, Auditor catches it easily.


With “q” parameter, we can see “<script” being stripped.


So by using it right where it would confuse Auditor (in the middle of “on” of event handler), we can alert it.


In the “r” parameter, the replacing issue is “fixed”. A developer replaces it with a harmless string (like we can see in the wild), that mess with our previous construction.


So we try to use the replaced string (“InvalidTag”) as a javascript string. But doing it in the wrong way, browser throws an error (in red).


That’s because we are passing to event handler only the string, enclosed by quotes. This is the standard way to assign values to attributes in HTML, so javascript parsing stops in the second quote and there’s no “InvalidTag” defined. So we try to fix the syntax.


It doesn’t work. It becomes too obvious for Auditor to catch it. But what if we try theES6 way to enclose javascript strings?


Nice. Another interesting way to do this, though not universally applicable as the previous one (because it can’t accept special chars), follows.



Using the replaced string as a label, it’s also possible to alert in a very elegant way.

Unfortunately, none of the above replacing tricks can be used with the last parameter, “s”. Auditor seems to flag the input due to presence of “<” character  in both request and response.


But, developers beware: this can’t be considered a XSS solution, even if employed against all HTML tags (with a regex, for example). It opens another door to a tester/attacker by using the resulting “<InvalidTag” string with any of the agnostic event handlers to form a new attacking vector.




android 调试工具adb在mac上安装方法

Option 1 - Using Homebrew This is the easiest way and will provide automatic updates. Inst...
  • samrtian
  • samrtian
  • 2018年01月22日 23:36
  • 22


Note from the author: XSS is Cross Site Scripting. If you dont know how XSS ...
  • eroswang
  • eroswang
  • 2007年10月19日 16:33
  • 5344

AppScan-Authentication Bypass Using HTTP Verb Tampering

话说到盖哥我继前段时间各个行业同时进行各个版本平台的安全测试,为此大忙特忙了一段时间,之后就开始重返之前的工作内容了。   经过之前的工作,也开始有点了解Web安全相关的知识了,虽然买的书还没怎么看...
  • chenzeyi_java
  • chenzeyi_java
  • 2017年07月09日 01:57
  • 1368

【XSS】XSS Bypass学习笔记1

  • qq_37706414
  • qq_37706414
  • 2017年12月10日 13:07
  • 40

UVa 11207 - The easiest way

题目:给你很多张矩形的纸,问哪张可以剪下四个面积相同的最大的正方形。 分析:简单题。只有两种减法:1.剪成2*2的;2.剪成1*4的。 注意:计算后的正方形边长可能是小数,例如:2*2的比3*3的...
  • mobius_strip
  • mobius_strip
  • 2013年10月12日 16:37
  • 1063

一个绝种的漏洞——IIS 5.1 Directory Authentication Bypass

Bugtraq ID: 41314 CVE ID:CVE-2010-2731 CNCVE ID:CNCVE-20102731   漏洞发布时间:2010-07-01 漏洞...
  • kuxing100
  • kuxing100
  • 2013年07月11日 10:12
  • 773

基于IBM Appscan 扫描的网站安全问题修改(.Net MVC)

  • qq_24033949
  • qq_24033949
  • 2016年10月13日 13:18
  • 1984

Another XSS auditor bypass

This bug is similar to the last one I posted but executes in a different context. It requires an exi...
  • qq_27446553
  • qq_27446553
  • 2015年05月05日 17:31
  • 302

Bypass XSS filters (Paper)

Bypass XSS filters (Paper)
  • cnbird2008
  • cnbird2008
  • 2010年11月08日 10:57
  • 637

centos6.4 安装mysql(the easiest way and best way)

可以参考 安装mysql(必须同时安装以下三个,否则死都不知道怎么死的): yum -y in...
  • u012307002
  • u012307002
  • 2015年02月04日 15:46
  • 440
    访问量: 84万+
    积分: 8604
    排名: 2792