Extbasic 7

[vh04x]

I know there's been a lot of confusion with ext 7, especially with the numerous changes to the code. Since so many people have asked for a push in the right direction, I shall give you a gentle tug. This is NOT A SPOILER (or at least I hope not), a guide, or a tutorial of any sort, but it may bring some light and allow you to take a different approach.

The mission in this case is not only to fix errors in the script, but also to secure a vulnerability in the script. In parsed languages such as PHP, when we speak of vulnerabilities, we usually deal with unsanitized user input. Now, where does the user have the opportunity to submit input?

[deadmoo]

This challenge is annoying. There are so many possible ways to filter/escape the input, how am I supposed to know which one i the "correct" answer?

[eclipse_sphere]

This challenge is annoying. There are so many possible ways to filter/escape the input, how am I supposed to know which one i the "correct" answer?

Well, you can only change one line (should be able to see which) and only one thing in that line is unsecure, your looking for the easiest way to fix it.

[deadmoo]

Maybe I am just completely off track. I understand all of that. My problem is all the solutions I have come up with only modify one line. There are probably over 2 dozen applicable functions in the standard PHP distribution, and you can use many different combinations of those functions with each other on the same line ( like the following code).

Code: Select all


<?php
// possibility one (this is the simplest one, but which of the 2 dozen applicable functions do I use)
$var = func1($var);

// possibility two
$var = func1(func2($var));

//possibility three
$var = func1(func2(func3($var)));

//possibility four (technically one line)
$var = func2($var); $var = func1($var);
?>
 

[McGregBB]

Am I right that the vulnerability lies in the form declaration where an xss exploit might be possible?

[SuperScience]

Am I right that the vulnerability lies in the form declaration where an xss exploit might be possible?

Thats the only vulnerability that I can see too. I tried fixing it by replacing it with the static URL but that didn't work, and REQUEST_URI is no better. Any hints would be appreciated.

[addik]

The post/get mistake just gives a hint of what line has a mistake...

http://blog.phpdoc.info/archives/13-XSS-Woes.html will give you a hint, one thing I will say, make sure you try every variant of x function even if the differences are subtle.

[I-MrKnox-I]

This challenge is just guessing... Hoped we were done with that in the logics, but apparently not.

I really think HTS should consider changing their way of validating answers to contain several correct answers on challenges like this!

[I-MrKnox-I]

Okay... I got it!
God, this was lame, but anyways...

I hope it is not to much of a spoiler - if so, feel free to edit!

Posible spoiler:

There are many ways to sanitize PHP_SELF (assuming you all know this is the vuln) as you might know by now. However, most of the ways will sanitize a lot of "innocent" chars too. We do not want this to happen. Luckily there is an alternative which is very alike, but only sanitizes the most "dangerous" chars like '<', '>' and quotes. This is what we are looking for.

[Mindzai]

Okay... I got it!
God, this was lame, but anyways...

I hope it is not to much of a spoiler - if so, feel free to edit!

Posible spoiler:

There are many ways to sanitize PHP_SELF (assuming you all know this is the vuln) as you might know by now. However, most of the ways will sanitize a lot of "innocent" chars too. We do not want this to happen. Luckily there is an alternative which is very alike, but only sanitizes the most "dangerous" chars like '<', '>' and quotes. This is what we are looking for.

Thanks for that. So many answers to this the validation code really should check for all possible answers (and convert case of the input for comparisons too!)