Description

Title : XSS ?No

What a shame on me, I didn’t know that flaw. I already read some papers on it, but as it’s a really old vulnerability and no one uses that nowadays, I never really checked.

So, what do we have here ? A classic form with three fields, one for the first name, the second one for the last name, and the last one for the age. When we entered datas, the page replies us with our strings.

As the title of this challenge is about XSS, I tried. Logic. XSS worked, but as you can imagine, the vulnerability wasn’t here ! So I began to look for vulnerabilities which looked like XSS and I faslty found SSI vulnerabilities, thanks to the OWASP.

The best thing to do was to try the most basic test <!–#printenv–>…

It worked. We now just have to find a better SSI directive, by looking on this website. We can begin by listing the current directory, with <!#exec cmd=”dir”–>. Maybe the token could be in another file.

Unfortunately, this directive didn’t worked! The SSI string is escaped. After a bit of troubleshooting, I understood that the space character was the guilty one. But there is still hope. Frequently, parser are lazy and can understand other character as separator, like line feed for example. In order to be sure, I tried to send <!–#exec%0acmd=”dir”–>

The SSI directive worked and sent me the listing of the folde, in which we could find… the TOKEEEEEEEEN folder. We just have to load it to have the flag !

The flag was here, just waiting for me !

This challenge was a bit annoying for the forbidden space character. I mean that it was cool to learn that SSI directive could work with others characters than the space, but I guess that the space char has been forbidden just in order to harden the challenge. In an actual script, I can’t see the reason why SSI could be escaped when a space is inserted.

Enjoy

The lsd