It's time we get started with the biggest vulnerabilities or bugs on our Web page, not by biggest,
I don't mean most dangerous.
However, these ones are still not something that you want to have on your Web page.
We will be starting in this section with Crosseyed scripting vulnerability or also known as access.
Now, you might have noticed that in the upper right corner, we have this JavaScript icon.
This can give us a hint as to what this vulnerability is.
So let's explain it.
First of all, access is very similar to HTML injection.
Those two are executed almost the same way.
And since we already covered the HTML injection, this will be a lot easier for you to understand and
perform.
Access is based on injecting JavaScript code in the Web page.
As with the HTML injection, we're looking for a vulnerable user input field that reflects our output
somewhere on the page.
Once we find it, we try to inject simple JavaScript code to see how the page would react and whether
it would execute.
One thing to keep in mind is that access is not a vulnerability, that Target's server, it is a vulnerability,
the target's clients that use that server.
If we are able to inject our malicious JavaScript code in the Web page, then that JavaScript code will
also run once a different client visits that Web page.
Now, whether the client visits the Web page directly or through a link makes a difference, depending
on what type of access vulnerability it is.
And we will discuss different types in just a second, right after we discuss the process of why our
JavaScript code executes on a vulnerable Web page.
So imagine we have this code as an example, it's the same code that we showed inside of our HTML injection
just this time, instead of injecting HTML, we want to try to inject JavaScript.
And the most simple thing we can find with JavaScript would be the alert function.
Of course, once embedding JavaScript inside the HTML code, we must add the open script tags where
our JavaScript code starts and close script tags where our JavaScript code ends.
This is how the browser will know that it's JavaScript, so it doesn't try to render it as an HTML code.
This code being simple code that asks for someone's name and then reflected on the page would look something
like this once we inject our alert function.
And if the website doesn't filter the input, it will process this is JavaScript code and we will get
a small popup window which is tied to this alert function.
That's when we would know that there is an excess vulnerability.
Of course, Web page can also have filters that are not properly set, usually a page can have a filter
that says everything between the HTML tags where the user input gets reflected, process it as a regular
string or regular text to bypass only that filter.
We could then do something like this.
We can first close tags for that line and then run our JavaScript code.
In this case, the end closing tag will get left out and it will no longer consider our script as being
as part of the open pretax.
Of course, this is all working, considering there are no other input filters.
Now let's talk about two main types of access and how they differ.
These two types are called reflected exercice and stored access.
Let's explain, reflected Exercice first.
In reflected access, we have an attacker injecting JavaScript code inside a certain Web page, the
webpage processes that input this JavaScript and runs it, letting the attacker know that it's vulnerable
to access.
Then the attacker sends the link to that Web page with the JavaScript code set as an input to the vulnerable
parameter.
Once the target opens the link, it will also run the JavaScript code on the vulnerable website.
The access where the JavaScript code we inject doesn't get stored and saved on the server is called
Reflected X. It says.
On the other hand, stored access is the exact same attack.
Just this time our JavaScript code gets saved and stored on the server and on the Web page.
This can be perhaps a Web page that offers comment section, if we inject JavaScript code in the comments
section, it will run every time someone opens that page.
And that's the main difference between these two instant access target doesn't have to click on any
link at all.
They can just go straight to the Web page and it will run nonetheless.
The stalled access is more dangerous since it doesn't require the target to open any links, they only
need to go to that website now.
Besides these two, there is also something called Dumex SS or Domme based Exercice, and it's an access
attack where the attack payload is executed as a result of modifying the dorm environment in the victim's
browser used by the original Clydeside script so that the Kleinsmith code runs in an unexpected manner.
We will see examples of different Texas types throughout this section.
So this is one of the most common vulnerabilities on the Web page.
We will devote a little bit more time to it, then to other vulnerabilities.