Attacking JavaScript protection (Bypass it like a breeze!)

 

 

Let's learn some great tricks during this f*cking pandemic! 
Yeeeeeehaaaa let's jump in! 

 

JavaScript is one of the most popular languages used in websites. Because of this popularity, you can find a wide variety of JavaScript usage examples. Of these, the most meaningless are:

 

  • JavaScript protection of part or all of the content

  • JavaScript data verification without server-side validation

  • JavaScript access control

By creating a website, it is necessary to proceed from the fact that any data received from any user is unreliable and JavaScript cannot guarantee anything. I really mean it with ANYTHING!

 

To demonstrate the vulnerability of JavaScript, we will bypass the protection in Damn Vulnerable Web Application (DVWA). To install DVWA on your computer.

 

First and foremost we will introduce you to some naked facts! 😂

 

1. Any part of the web page and JavaScript can be randomly changed by the user

 

So, let’s set the low security level in DVWA (in the DVWA Security tab) and go to the “JavaScript Attacks” page and see the following there:

 

 

 

As a task, we need to pass the word “success” through the form on the site. Let’s try: we enter “success” and Sumbit. We get the error “Invalid token.”:

 

 

 

Open the source code of the page. 

 

 

Between the <script></script> tags there is the following:

 

 

 

I can only understand the following lines:

 

 

 

As well look at the form being used to send the word “success”:

 

 

 

 

In the generate_token() function in the first line “phrase” variable is assigned. It got the value that has the field with the “phrase” id in the form. Then, in the second line of the considered function, the value of the phrase variable is processed by two functions and their value is assigned to the element with “token” id.

Outside the function, there is a call code for this function:

 

generate_token();

 

 

This call is not tied to any event (for example, form submission) or condition. This means that when the page is open in our browser, the generate_token() function has already been executed, that is, the token value for the “ChangeMe” string has already been calculated and assigned to the input field with the “token” id. For this reason, when we change the value of the “phrase” input field, it does not coincide with the token, which is what we get the message about.

 

It turns out that the only way to cope with the task is to change the value of the phrase field from “ChangeMe” to “success” before opening it in a web browser.

 

But the BIG question is: How?

 

This can be done in Burp Suite, which, among other things, can change the contents of any part (headers and body of requests and responses) of HTTP on the fly.

 

 

 

But I will show you a completely “childish” method, which I used from the first years of the appearance of my computer, for this method no tools are needed at all.

 

The essence is elementary: we save the page to our computer, open it with an editor (any text or HTML code editor), make the necessary changes, open this page in the browser and submit it!

 

We save (the name I chose is shorter, otherwise there may be problems due to special characters):

 

Open the *.html file and find the form:

 

 

 

As you can see, it has changed, namely, the value is assigned to the token field, apparently, this was done by the browser when saving:

 

 

 

 

 

 

 

 

 

 

 

 

 

So, firstly, change “ChangeMe” to “success”.