Forum Discussion

netcat's avatar
netcat
Icon for Bronze III rankBronze III
11 days ago

Human Connection Challenge: Season 1 – Web Exploitation - XSS

Question: Identify a reflected XSS vulnerability on the web application that reveals a token in the error message.

There are a few forms on the web page:

  • / -> submit reloads /, the attachment isn't even uploaded => no user input displayed
  • /register -> submit loads / => no user input displayed
  • /member-login -> submit reloads the page with the entered data => user input. But it seems impossible to get working script tags though
  • /<another login page> -> submit loads yet another static page => no user input displayed

There's also a path traversal, however it seems impossible to e.g. execute a command to update a field the database. And there's SQL injection, and it seems impossible to insert/update a field in the database.

Still, my best guess would be to insert a user "<script>alert()</script>" in the database. Then I can display the user list to trigger the script.

Any hints on where to go?

  • For the XSS, I would recommend you to test all of the available fields, one of them is the one and you should see the token in the same page, if it redirects to the main page, then that was not the correct field. Tip, try your script in all the fields at the same time!

    Directory Traversal, you need to find a url with something like /test?field=something.txt, this could be an indicate of path traversal.

    For SQL, only extract data is possible no modifications are allowed.

    • miclib's avatar
      miclib
      Icon for Bronze II rankBronze II

      Every lab has to have at least one. Otherwise they'd be boring. 

      For me, to crawl out, I read an article about reflective XSS where it mentioned the types of urls to look for, in order to find a compromise. Burpsuite happened to be open and there it was staring me in the face. Doh. 

  • I'll take another look, with the summary of three answers: Try all fields, including those that don't display anything.
    Yet, I never saw an error message when putting invalid data in other fields than the member login. In my opinion these fields should lead to the answer. I mean, there's an error message with the user input:

    (sqlite3.OperationalError) near [...]: syntax error [SQL: SELECT [...] FROM [...] WHERE username = [...]<script>alert(1)</script>[...]

    Is this just a rabbit hole placed entertainment? Nobody could get past it?

    • miclib's avatar
      miclib
      Icon for Bronze II rankBronze II

      Look at what the error returning is trying to tell you. Sometimes we look for one thing and another gift falls in our lap. 

    • netcat's avatar
      netcat
      Icon for Bronze III rankBronze III

      Got it. I'd rewrite the question: Find a purpose-build backdoor that can be opened with <script></script>.

  • welcome on your journey down the rabbit hole of the secret mysteries in IL Labs :)
    my tip (after solving ~2500 labs): sometimes don't think too far, how this is linked to reality. in this lab I agree with you: in reality the attacker would make sure that the XSS would probably be written in a database, to steal e.g. credentials from the victim when he's logging onto a website where the message/content gets loaded. but yes, the rabbit hole in IL labs can be deep and wide and strange ;-)

    here the tricky part is, that only one field will react to the XSS. so just put your payload to all fields and hopefully one will respond magically with a token when the page gets loaded again.

    regarding path traversal: theres a file which gets "loaded" ... just get the path straight. /etc/passwd is always a good way try and find the hole.

    for the SQL injection this is not possible unless you can highjack an update command. so don't waste your time here but use the mighty power of the rabb.. erm... sqlmap. good luck!

  • hmm.. welcome down to the rabbit hole of IL labs :) 
    sometimes don't think too far, because the labs not always mimic reality. in reality yes, the XSS would be probably stored in a db, so the target would execute it. 

    but here: there are some "magic" fields which will magically convert the input to some web output, just find the right field or just use all fields :)

    for the traversal... the include is quite straightforward. just abuse it, /etc/passwd is also accessible.

    hope this will help you, to finish the lab.

  • >Still, my best guess would be to insert a user "<script>alert()</script>" in the database. Then I can display the user list to trigger the script.

    I had the same thought and wasted a bit of time on it haha. Worth bearing in mind that the question specifies 'reflected xss' and not 'persisted xss'. It might be possible, but that's not how I ended up getting this one.

    Suggest using burp repeater and try every single form input available on the site, at least one of them works - possibly one you have tried already ;)  

  • For the XSS, I would recommend you to test all of the available fields, one of them is the one and you should see the token in the same page, if it redirects to the main page, then that was not the correct field. Tip, try your script in all the fields at the same time!

    Directory Traversal, you need to find a url with something like /test?field=something.txt, this could be an indicate of path traversal.

    For SQL, only extract data is possible no modifications are allowed.