All right, so everyone, this is a snitch again, and this session is about security challenges, security
challenges of war with JavaScript.
Right.
Oh, really?
Yes.
So you will be talking about some security challenges for JavaScript.
Does it still exist?
I would say yes, but maybe not.
But I'm talking about from the nutshell and how it has been improved and what are the security measures
with JavaScript in order to protect from JavaScript and which has been taken by many institutions in
institutions and on the Web that application agencies.
Right.
So let's get started.
We'll take the same example.
And in our last example, we had user machine talking to a website, website as a example, dot com.
And now in the same example, user is having a Web browser that the clanged machine and he's sending
a certificate request in order to get the response from the website.
What would be the response?
It would be simply the EDP page of response, what it might carry.
It can carry these images, text, text that might be redirected to another pages and all those stuff.
In our case, it just is simple SCDP.
In our case, just the title is Web site.
That's it.
So it's going to be completely blank website, but the blank page basically.
So users sends a request, a request, but in return it get these blank page.
But you what you would see if you imagine if you sorry.
If you recall correctly in our last session we have seen JavaScript for better purpose.
For what purpose.
Basically for, for prompting or giving some alerts to the user about welcome to the world and all those
are.
But this can even be used for malicious purposes.
Right.
We know that JavaScript can be used for making your website beautiful enough, making the conversation
dynamic in nature or making the conversation or the transaction between client machine and the server
more and more a, you know, dynamic, proactive in nature and the real time as well.
But this can also be used for some malicious activity.
And this is what it can be done.
I mean, it can have a redirection of us with JavaScript.
We can even redirect the user response to another website.
Right, by making user.
So that's the syntax there.
And you still have your script starting with that.
And at the end and the ending syntax.
And in between that we can have another website.
If you see that malicious site example dot com, I just take it as an example and then you can redirect
or some other website.
But wait, how would this happen?
Why would a genuine website would send your traffic to some other.
Well, not for this to work.
This website has to be either compromised or it is already infected or already have one already a malicious
site maybe.
So whether it might be owned by a hacker or it might be affected or infected by and hacker.
Right.
So in that case, it might send a malicious code or maybe the code which has been enforced, which has
been programmed by the hacker.
Right.
So in that case, it might send a link.
And once you once you see any any link on those blank page, you click on it and you get redirected.
So that could happen.
And even if you don't click on it and the script, basically what happened is the JavaScript engine
on your browser basically basically downloaded all the content, all the content on the website image.
Even if it he didn't even if it is not anywhere and even mentioned as a part of a link, it still be
downloaded and you get you have to your browser follow the exact guideline given by the Joester.
Right.
In some situation you might have to click.
But another situation, your browser simply download all the content of that Web page and it would also
be downloading this script as well.
So in that case, it will simply follow the response.
All right.
So this is a big challenge.
But what is really happening, if you understand this, what are the points where the problem could
arise?
Right on the website.
The first part we have already discussed in the input site.
This is where we have discussed in case of a injection.
If you remember correctly, correctly, sorry, if you remember correctly, that's where the input sanitisation
wasn't really happening properly, right?
Because of lack of input sanitisation, any user can send any kind of malicious query and it can disrupt
the database or the application or can retrieve the desired information from the website, our web application.
Now, this was pretty much vulnerable in case of when when input sanitisation is not happening properly.
And in that situation, the client were very, you know, clim most of the user or there could be a
malicious actor who can leverage the info, who can leverage such kind of attack to get information
or desired information.
In this situation, the output, sanitation or output part is something which can lead to trouble.
How exactly is that in this situation, if the output is sending some information or the output side
is sending some information from the website?
This could lead to a challenge on the website.
So it has to be sanitized that what information is really going out of the application?
Let me tell you something you might be wondering.
I mean, if it is really a malicious side, why would it why would somebody stop it from doing that?
Of course not, if it is already an malicious site.
I mean, it's a job of a malicious cyber hacking side to do this activity.
We are talking about an infected site, a vulnerable site or maybe a compromised site in that situation.
If it is an infected site where there is lack of standardization, it might send any sort of data out
from the letting go from the network.
Right.
And in that situation itself, such kind of challenges might arise.
So we are still not at the crosshatch scripting, but we are at the initial problem of JavaScript.
Let's understand the real problem here.
We understood that there is some information can be sent to a website and website, can send any kind
of a JavaScript and it can be sent for a better purpose.
It can be sent for, you know, some malicious activity as well.
Now, let's understand, the real challenge here will be consolidating the same problem here as well.
The user is sending a request on a site over here.
Right in our example, it was w w w dot example, dot com.
We got some response back the JavaScript engine on the browser loaded doege loaded those.
You downloaded those JavaScript file JavaScript and it performed the required activity.
Now, if that carries these same sorts of redirection, you know, redirection or the same JavaScript
that we have just seen, it might be related to malicious site example, dot com.
Right.
And in that case, it would be forward to really a malicious side or a side which is completely been
controlled by a hacker.
This is what it is.
And this lead to the compromise completely compromised situation.
Right.
So we understood the problem.
Now, we understood the problem that the first website is where it can be an infected site.
First Web site can be an infected site, which might be sending which might be letting the data to go
outside without any standardization.
So that data is being received by the user.
And based on the data that there might be some redirection javascript with the associated text that
would be seen in the last session, the request will be forwarded to the malicious site, the site which
has been completely in control with the hacker.
That's where the, you know, the request goes.
And in the response to that, it will be completely compromised.
Right.
Sorry.
So the problem is the problem is the injecting script on the another domain, because we are not really
in the same domain to we are injecting this script so that the the traffic can be redirected to another
domain because the source is not from the same domain, isn't it.
Read the same script is being delivered from example dot com, but this goes to the malicious site example
dot com maybe as an example that's really a problem and that's called domain redirection.
I mean, that's really the problem, which is wherein we can inject this script to another domain,
right.
That's really a problem.
For this to solve, the S&P was up, which is the same origin policy, if the same origin policy is
not there with JavaScript, will never.
I mean, whatever the kind of malicious code we have developed, this will never work because of this.
Most of the hacks has been unsuccessful in the past.
And this was developed specially for this purpose after the evolution of JavaScript.
So this has been developed for the same reason.
And this is really a solution so that we can not have such a redirection where the not any of the site
can relate to you on any other site without looking at the multiple parameter.
It depends on the JavaScript.
I'm not talking about the Jurel that you go right example when you go to example one dot com and then
it'll redirect you to another site that's altogether different.
And we are talking about JavaScript, which is embedded on your website right in that situation and
won't be redirected as it is.
All right.
So that's what goes about the problem that exists, used to exist, I would say, with JavaScript,
and that has been solved with the S.O.P.
Now we need to really understand what is there any criteria with S.O.P?
I mean, does how does it really works?
How does it in the standard the redirection is happening, is it happening on the same side?
Is it really relevant or not on this parameter?
So let's get into detail in the next session and understand what are the parameters that needs to be
satisfied before it can be redirected.
Right.
Because I might be redirecting the content from my own site to my own website, maybe some other pages.
It should be genuine in that situation.
It should not be taken as the militias attempted.
I should not be blocked by somebody.
So that has to be some parameter.
Right.
So that is something will which we'll be covering in the next session.
And we'll get you there.
Thank.