logo
0x1 Home0x2 Experience0x3 Portfolio0x4 Blogs0x5 Contact

TIWAP | Official Walkthrough Part - 2

Difficulty: Hard

Cross-Site Scripting (XSS)

These days all modern applications are running on JavaScript, which means that the input or processed data on the client side is being handled by JavaScript itself. At times, the data being passed to the database or being fetched is done directly from the frontend. In such a case, there could be a lack of data validation or the validator code can be read and bypassed.

Another case could be that the data is being processed at the backend. In that case, validation bypass is tough but there could be a chance that the data is not being validated at all. In both the cases, some malicious javascript input could be passed which could result in information disclosure or could possibly be chained with other attacks.

This method of passing malicious input to an application is known as Cross-Site Scripting or XSS.

XSS is of three types:

Reflected XSS

In Reflected XSS, when the attack sends a malicious URL, the script executes and result is displayed with the response from the webserver.

So this time, the lab is almost similar, the only thing is that the "script" tagged as well as HTML element attributes like onerror, onfocus, etc. so we need to look for some uncommon attributes.

<body onpageshow=alert(1)>

And I was able to trigger the alert using the script.

XSS-1

Vulnerable Code:

if session['level'] == 2:
    if "<script>" in entry.lower() or XSS.filter_input(data=entry):
        msg = "Try Harder"
    else:
        msg = "Hi, " + entry

def filter_input(data):
    filters = ["onerror", "onfocus", "onfocusin", "onfocusout", "onload", "onresize", "onscroll", "onclick",
               "onkeydown", "onkeypress", "onkeyup", "onselect"]

    for f in filters:
        if f in data:
            return True

    return False

Stored XSS

As you might have noticed that in Reflected XSS, the payload is not persistent, therefore you need to pass the payload every time.

The reason that the payload is not persistent is that it is not getting stored or saved anywhere in the application. If the payload is being stored somewhere and is getting executed every time the data is being fetched and displayed, such a scenario is known as Stored XSS.

In this lab, I already have certain comments and in addition to that, I can add some of my own. Here, once again, I will be passing the same payload as Reflected XSS and as soon I do that, I will get the alert box triggered.

XSS-2

Vulnerable Code:

# Common Filter - Hard
def filter_input(data):
    filters = ["onerror", "onfocus", "onfocusin", "onfocusout", "onload", "onresize", "onscroll", "onclick", "onkeydown", "onkeypress", "onkeyup", "onselect"]

    for f in filters:
        if f in data:
            return True

    return False


# Stored - Hard
def stored_xss_hard(comment):
    if "<script>" in comment.lower() or filter_input(data=comment):
        return "Try Harder", {}
    else:
        return stored_xss_low(comment)

DOM Based XSS

As you already know that all the modern websites use JavaScript, and the same can be used to modify the web page content. DOM Based XSS is mostly used to deface a website.

This time again, the lab has most of the things filtered, so I used the one below.

<body onpageshow='document.getElementById("vuln-name").innerHTML="Hacked XSS"' />

As soon as I passed the script above, the title changed.

XSS-3

The vulnerable code that can be seen here is the same as Reflected XSS.

HTML Injection

As we know, HTML is the base of all websites running on the internet and just like XSS, the data being passed by the user could not be trusted. This is because passing some malicious HTML can deface the website or could be chained with other exploits like XSS.

The impact of HTML injection is similar to XSS.

In this lab, we need to enter our name and if there is no valid injection code, we get the message, "Try Harder". I tried with the previous payload but it didn't worked so I URL Encoded the whole payload and passed the same.

%3c%68%31%3e%48%61%63%6b%65%64%3c%2f%68%31%3e

The code above is URL Encoded HTML, although when it runs successfully, it means the Injection is working.

HTML Injection

Vulnerable Code:

if session['level'] == 2:
    try:
        if "%" in entry:
            entry = parse.unquote(entry)
            msg = "Hola! " + entry + ", How are you? "
        else:
            msg = "Try Harder"
    except error:
        msg = "Try Harder"

Improper Certificate Validation

All the web applications work on two protocols, HTTP or HTTPS. We know that HTTPS is more secure than HTTP due to employment of SSL/TLS protocols.

These SSL/TLS protocols work on the concept of Digital Signatures and Certificates to maintain integrity of the content. At times, these certificates might get expired or the organizations alternatively use self-signed certificates; both the cases are highly insecure.

In this lab, there is a self-signed certificate installed to implement HTTPS protocol on the target.

Improper Certificate Validation

Hard-Coded Credentials

In some applications, the developers tend to hard-code some complex credentials into the application in order to prevent most of the authentication bypass attacks.

At times, there are scenarios when these credentials are leaked in the open-source code, or are placed in a public platform, hence this vulnerability is mostly linked to Sensitive Data Exposure.

Hard-Coded credentials have no difficulty level.

© 2024 Simardeep Singh | Some Rights Reserved