Cross-Site Scripting Attacks: What You Need to Know Now

Summary

In this 'Coffee with PR' session, the host delves into the world of application security, focusing on Cross-Site Scripting (XSS). The video explains the difference between client-side and server-side scripts, illustrating how XSS exploits client trust in servers. It differentiates between stored and reflected XSS attacks, providing examples and discussing their impacts. The host also covers prevention strategies, such as using HTTP-only and secure flags in cookies, and emphasizes the importance of secure coding practices and regular security assessments. The session ends with a teaser for the next video on Cross-Site Request Forgery (CSRF), inviting viewers to explore the nuanced differences between XSS and CSRF.

Takeaways

• 😀 The session focuses on application security, specifically discussing cross-site scripting (XSS) and its differences from CSRF.
• 🎥 The speaker introduces the series with a focus on subscriber feedback requesting more content on application security.
• 👤 XSS is a client-side vulnerability where an attacker injects malicious scripts into web content that is executed on the user's browser.
• 💻 The script explains the difference between client-side and server-side scripts, emphasizing that XSS is a client-side issue.
• 🔍 The speaker uses a diagram to illustrate how an attacker might exploit a vulnerability in a forum by injecting a malicious script that gets executed when a user visits the site.
• 📈 The video outlines the two types of XSS: stored and reflected, providing an example of each and explaining how they work.
• 🛡 To mitigate XSS, the speaker recommends using HTTP-only and secure flags in cookies to enhance security.
• 🔒 The HTTP-only flag prevents client-side scripts from accessing cookie data, while the secure flag ensures cookies are sent over HTTPS, protecting against man-in-the-middle attacks.
• 🔎 The script discusses methods for identifying XSS vulnerabilities, including manual testing, code review, and the use of automated scanning tools.
• 🛠 Prevention strategies include output encoding, implementing content security policies, and regular security assessments.
• ❓ The script anticipates common interview questions related to XSS, such as explaining the concept, differentiating between stored and reflected XSS, and demonstrating reflective XSS with a simple script.

Q & A

What is the main focus of the 'Coffee with PR' session discussed in the script?

The main focus of the 'Coffee with PR' session is discussing cross-site scripting (XSS) as part of the application security series.

What is the difference between client-side and server-side scripts as explained in the script?

Client-side scripts are executed on the user's browser and are used to improve website performance and user experience, such as form validation, image sliders, and interactive maps. Server-side scripts run on the server, fulfilling user requests, authenticating users, and processing data, with only the results sent to the client browser.

How does cross-site scripting exploit the trust between the client and the server?

Cross-site scripting exploits the trust a client has in the server by injecting malicious scripts into web content. When the client's browser renders the web page, the malicious script is executed on the client side, potentially leading to data theft or other malicious activities.

What is the stored cross-site scripting attack as described in the script?

Stored cross-site scripting is an attack where malicious scripts are permanently stored on the server and served to users viewing the content. An example is when an attacker posts a comment containing a malicious script on a blog, and every user who views the comment section has the script executed on their browser.

How does reflected cross-site scripting differ from stored cross-site scripting?

Reflected cross-site scripting occurs when a malicious script is embedded in a URL and sent directly to the client via a phishing link. The script is not stored on the server but is executed immediately upon clicking the link, making it a non-persistent attack.

What are the two types of cross-site scripting attacks mentioned in the script?

The two types of cross-site scripting attacks mentioned are stored and reflected. Stored attacks involve scripts permanently stored on the server, while reflected attacks involve scripts embedded in URLs and executed immediately upon user interaction.

How can HTTP only and secure flags in cookies help prevent cross-site scripting attacks?

HTTP only flags restrict client-side script access to cookie data, preventing it from being stolen by malicious scripts. Secure flags ensure cookies are sent only over secure channels like HTTPS, reducing the risk of cookie theft in man-in-the-middle attacks.

What are some methods to identify if an application is vulnerable to cross-site scripting?

Methods to identify vulnerabilities include manual testing with malicious payloads, code reviews to find places where user input could be rendered as HTML, and using automated scanning tools to detect potential XSS vulnerabilities.

What are the prevention strategies discussed in the script for cross-site scripting?

Prevention strategies include output encoding to validate and properly handle user input, implementing content security policies, following secure coding practices, regular patching and updating of servers, conducting regular penetration testing, and using web application firewalls.

What are some common questions asked in application security jobs related to cross-site scripting?

Common questions include explaining what cross-site scripting is and how it works, differentiating between stored and reflected XSS, identifying vulnerable code, demonstrating reflected XSS with a script, and discussing the implementation of content security policies.

Outlines

00:00

🔐 Introduction to Cross-Site Scripting (XSS)

The speaker introduces the topic of Cross-Site Scripting (XSS) as part of an application security series. They mention receiving feedback from subscribers requesting more content on this topic. The session aims to differentiate XSS from Cross-Site Request Forgery (CSRF), with a detailed discussion on CSRF planned for the next video. The speaker encourages viewers to subscribe to the channel for updates on similar topics and to check their LinkedIn profile for more information.

05:00

💻 Understanding Scripts and Their Role in XSS

The paragraph explains the concept of scripts, which are activities run on both the server and client sides. Scripts are responsible for actions and automations within a system, such as graphical representations and popups on websites. The speaker distinguishes between client-side scripts, which execute on the user's browser, and server-side scripts, which run on the server. An example of client-side scripting is form validation, while server-side scripting involves user authentication, data retrieval, and processing. The paragraph sets the stage for understanding XSS as a client-side vulnerability.

10:01

🛡️ How Cross-Site Scripting Works

This section delves into how XSS works, with an emphasis on the attacker's ability to inject malicious scripts into web content served to users. The speaker uses a diagram to illustrate an example where a hacker exploits a server's vulnerability to input validation by injecting a script into a forum. When a user visits the forum and clicks on the injected script, it executes on their browser, potentially leading to data theft or system crashes. The paragraph explains the concept of stored XSS, where the malicious script is permanently stored on the server and served to users viewing the content.

15:02

👀 Identifying and Preventing XSS Attacks

The speaker discusses how to identify vulnerabilities to XSS by looking for places where user input is expected, such as text fields and URL parameters. They explain the difference between stored and reflected XSS attacks, using examples to illustrate each. The paragraph also covers prevention strategies, including the use of HTTP-only and secure flags in cookies, output encoding, and implementing content security policies. The speaker emphasizes the importance of regular security assessments, secure coding practices, and the use of web application firewalls to block malicious inputs.

20:02

📝 Conclusion and Future Discussion on CSRF

In the concluding paragraph, the speaker summarizes the key points about XSS and sets the stage for the next video, which will focus on Cross-Site Request Forgery (CSRF). They highlight the differences between XSS and CSRF, emphasizing that XSS involves executing malicious scripts in the user's browser, while CSRF tricks the user into performing unwanted actions on a web application. The speaker invites feedback and encourages viewers to watch the upcoming video for a deeper understanding of CSRF and its distinctions from XSS.

Keywords

💡Cross-site Scripting (XSS)

Cross-site Scripting (XSS) is a type of security vulnerability that allows attackers to inject malicious scripts into web applications. These scripts are then executed on the client-side, potentially leading to data theft, session hijacking, or defacement of the website. In the context of the video, XSS is the main theme, with the script explaining how it differs from CSRF and providing examples of how an attacker might exploit a vulnerable server to inject malicious scripts into a website's content.

💡Client-side Script

A client-side script is a piece of code that runs on the user's browser, as opposed to server-side scripts which run on the server. The video explains that client-side scripts are responsible for actions like form validation, image sliders, and interactive maps, enhancing user experience by executing on the user's device after the web page has loaded. An example from the script is the chat popup or discount popup seen when visiting a website, which is a result of client-side scripting.

💡Server-side Script

Server-side scripts are executed on the server and are responsible for fulfilling user requests, such as user authentication and data retrieval from databases. The video uses the example of entering a username and password, which gets sent to the server for validation, to illustrate server-side scripting. These scripts are crucial for creating interactive websites and interfaces with databases.

💡Input Validation

Input validation is the process of checking user inputs to ensure they are valid and safe to process. The video emphasizes the importance of input validation in preventing XSS attacks, as it involves verifying and sanitizing inputs to avoid malicious scripts from being executed. An example given is how a server might accept any input without verification, making it vulnerable to an attacker injecting a script.

💡HTTP-only Flag

The HTTP-only flag is a security measure used to prevent client-side scripts from accessing cookie data. As explained in the video, when a cookie is marked as HTTP-only, it can only be accessed by the server, not by client-side scripts, which helps mitigate the risk of XSS attacks. This is a key strategy for enhancing web application security by protecting sensitive data from being stolen.

💡Secure Flag

The secure flag in cookies ensures that cookies are sent over secure channels, such as HTTPS, and not over unencrypted HTTP. The video discusses how this flag reduces the risk of cookie theft by man-in-the-middle attacks, as it instructs the browser to only send the cookie if the request is made over a secure protocol. This is another essential measure for robust web application security.

💡Stored XSS

Stored XSS, as mentioned in the video, occurs when malicious scripts are permanently stored on the server and served to users viewing the stored information. An example given is an attacker posting a comment containing a malicious script on a blog, which then executes on the browsers of users viewing the comment section, illustrating how stored XSS can affect multiple users.

💡Reflected XSS

Reflected XSS, as explained in the video, is a type of attack where the malicious script is not stored on the server but is instead embedded in a URL and sent directly to the client. The video provides an example of a hacker sending a URL containing a script to a user; when the user clicks the link, the server processes the script on the client's browser without the user's knowledge, potentially leading to system compromise.

💡Content Security Policy (CSP)

Content Security Policy is a security measure discussed in the video that helps prevent XSS attacks by specifying which sources the browser should consider valid for executing scripts. By implementing CSP, websites can instruct browsers to only execute scripts from trusted sources, thus preventing the execution of malicious scripts injected by attackers.

💡Cross-Site Request Forgery (CSRF)

Although not the main focus of the video, CSRF is mentioned as a separate security vulnerability that should be distinguished from XSS. CSRF involves tricking a user into executing unwanted actions on a web application without their knowledge, typically by exploiting trust that the server has in the user. The video suggests that understanding the differences between XSS and CSRF is important for comprehensive web application security.

Highlights

Introduction to the session on application security focusing on cross-site scripting.

Differentiation between cross-site scripting and cross-site request forgery.

Explanation of scripts, their types, and their roles in client and server-side operations.

Definition and example of client-side scripting, including form validation and interactive elements.

Definition and example of server-side scripting, including user authentication and data processing.

How cross-site scripting works and the difference between stored and reflected XSS.

Stored XSS example involving a hacker injecting a script into a forum.

Reflected XSS example where a malicious script is sent via email and executed upon clicking a link.

Impact of XSS attacks, including data theft, website defacement, and server crashes.

Identification of XSS vulnerabilities through user input fields and URL parameters.

Use of HTTP-only and Secure flags in cookies to prevent XSS attacks.

Explanation of HTTP-only flag to restrict client-side script access to cookies.

Explanation of Secure flag to ensure cookies are sent over secure channels.

Vulnerability detection methods including manual testing and code review.

Prevention strategies for XSS including output encoding and content security policy.

Importance of regular patching, updating, and security assessments for web applications.

Common interview questions related to XSS and how to approach them.

Comparison between Cross-Site Scripting and Cross-Site Request Forgery.

Invitation for feedback and suggestions for future video topics on application security.

Transcripts

hello team welcome to my session on

coffee with PR and today we're going to

discuss about cross-side scripting it is

part of my application security Series

so there was a lot of feedback I was

receiving from the subscriber and please

do some videos on that area so I thought

let me start this initiative so in this

video we're going to discuss about

Crosset scripting and how it is

different from Crosset request FY in my

next video I'm going to discuss about in

detail about the cross request fery my

name is bra ner for more information do

check my Lin profile and if you're new

to the channel do subscribe to my

YouTube channel and click on the Bell

icon to make sure you should not miss my

future videos on a similar topic so

without wasting a time let's start with

the first part thank

[Music]

you okay before we going to discuss

about what is cross-site scripting let's

first understand the concept of scripts

see when you're talking about script is

basically um is the activity which is

run on the server and on the client side

you know if you want to perform any

action or if you want to perform any

activity in the system okay any kind of

automations and all that it is basically

done with the help of script okay so

example like you know when you visit any

website some graphical representation

that show on the browser site right

right capture you know popup so this is

basically done through the help of

script only script is the one which

basically pop up Suddenly visit one

website you can see the chat popup so

that is basically because of the script

now when we talking about script script

is actually two type one is basically

called as a client side script and one

is basically called as a server side

script first of all you need to remember

cross-site scripting is a client side

vulnerability so client side script is a

script which is running on the client

side and server side script is running

on the server s side so here you can see

the client side script refer to a script

that are executed on the user browser

rather than the server how suppose this

is the user we have okay and there is a

system okay he visit one website which

is called suppose infos

train.com infos tr.com page is basically

loaded in his

browser okay infos in page loaded in his

browser now he can see some popup of

chat he can see the discount popup he

can see the graphical representation so

this is basically running on the browser

because of the client side script it

means script which is running on the

client side browser so example like form

validation so example like when we

browse the page we get a registration

page portal where you need to enter

details if you feel some values in valid

and all that immediately there itself it

stop it's a invalid value right sometime

registration page is there it ask for

the invalid valid value so because there

is a client side script which is running

on the client site okay so we have a

image slider you know image is basically

change we have an interactive map we

have animation so the execution is the

script is execute on the user device

after the web page has been loaded and

it was there because it is used to

improve the performance of the uh

website and it is basically used to give

a good environment to the user so this

is called as a client side script on the

other side the server s side script is a

web server technology in which user

request is full fill uh you know by the

by the server how so example like this

is the client we

have and this is basically my

server now please try to understand okay

so user basically requests for a

page the page is basically

load

okay on client

device so the page was load now here we

have some scripts offer offer like this

kind of a script was there offer click

to claim so client what he did he click

on this particular link it mean he

requested server please open the script

for me so there's a script which is

running on the server side which review

which receive the request and then they

process the script on the server site

and according to that it provide the

result back to the user so the script

which is running on the server side that

is basically called as a server side

scripting example when you enter usern

and password that information goes to

server server is the one which validate

that password authenticate the password

there's a script which is running on the

server so sometime what happen we create

a script in such a way to Target the

server we create a script in such a way

to Target the client but this is

basically where the script running on

the server side so it is often used to

create interactive website and to the

interface to database and execution is

the script is executed on the the server

and only result is sent to the client

browser okay so user authentication

retrieving displaying data from the

database processing user data so these

are the examples we have for the server

site scripting

okay okay so now you understood about

cross side scripting sorry you

understood about the client side and

server side now now let's understand how

cross-site scripting works so first we

basically go by the description so if

you see the description it say attacker

inject the malitia script into the web

content that is then served to user and

when user browser render the web pay the

malitia script is executed on the client

side that is a user browser to

understand this in detail let me explain

you with the help of diagram okay so

this is basically my

client okay so we have a client

here okay and uh let me change the

color and this is basically my server

now just imagine this this basically a

server is just like a

forum a very known Forum people use to

post lot of content there lot of people

visit the Forum and review the content

and all that so now what happened we

have a hacker

here we have a

hacker

or

researcher what he found that server is

basically accepting server is basically

accepting any input it mean the server

is vulnerable for

input

validation now when we say input

validation input validation mean without

verifying it process the input example

if I say it to my friend 1+ one I said

so I told him 1+ 1 is three he said yes

you right three but without verifying he

just reply and say yes but when I say 1+

1 3 no no no it's not 1 + 1 3 it is 1 +1

2 understood so here he verified the

input and he react so here we understood

server accepting all the input without

any verification okay so what hacker did

hacker basically discovered like this

website is basically have a great

reputation in the market a lot of people

visit this page so in this particular

page he injected one

script like this

way

dumps

100% so now what happen

server accept this particular input and

now that server on server that script is

pop up on that Forum now this is the

client is preparing for some

certification he visit this particular

website

and the server basically load the

page

page okay for the

user so now what happened the page was

loaded on the client side now when the

page load he can see there is a popup

Dump Dump

Dump what he did he click on that link

it mean he want want to see what is this

dump all about that request is basically

sent to the

server

request sent

to server server without verifying it

process the script and the script was

executed on the client site and it lead

to like server got client got hang the

credential was stolen that script has

has basically installed the thren so if

you notice in this attack what happened

hacker basically inject the script on

the

server script is now pop up on the page

client visit the page he brows the page

on his browser he click on the link the

link request spent to the server server

thought user want to open that server

without verifying he process back on the

client and based on that server trust

client basically open the script and

that basically crash the client system

so here we exploit the trust okay of the

server sorry export the trust of the

client toward the server see Crosset

scripting is basically occur okay

because of two things one the data enter

a web application through untrusted

source and second is data is included in

the dynamic content which is sent to the

web user without being validated from

the malicious content so this is the

example what we have seen was the

example of the stored crossed scripting

so crossed scripting are exit on the

client side the vulnerability enabled

the attack can present in both servers

and client but I'm talking about the

vulnerability in the server without

verifying input but by the end of the

day it is a client side attack because

we want to crash the client by

exploiting a trust toward the server so

attacker inject a script into the

comment section of a Blog which

basically steal cookies from any user

viewing the content okay so that is how

it works now when we're talking about

impact what is happen is impact is that

script when it running on the client

site it can identify the theft it can uh

do the data theft it can defas the

website also because the script which he

request for open might be it is Target

on the server it crashed the server also

server thought client has requested

client thought server has requested so

that is how this attack is basically

initiated so when we're talking about

cross-site scripting we have a two type

of crossed scripting one is basically

called reflected and one is basically

stored the example which I shown you

right now was the example of the stored

crossed scripting because in a stored

crossed scripting the Malicia scripts

permanently is stored on the server and

serve to user view that the stored

information so attacker post a comment

containing a malicious script on the

blog and every user who view the comment

section of the blog will have a script

execute on the browser the same example

we have discussed right so we have a we

have a client

here okay we have a

server client basically post the script

on the server use sorry hacker basically

post the script on the server now user

is there he basically visit the page

page is loaded on a client browser and

that script crashed the system okay so

this is basically what is happened in

the case of um stored cross scripting

but here in this attack we are waiting

for the user to click on the link okay

but if my target is very specific so in

that case I will basically perform the

uh reflective Crosset scripting okay so

how it works so example like here is a

hacker

this is the

hacker okay he know his Target is

specific domain okay the domain is

basically

suppose kk.com and there is a user is

basically name is user at

theate

kk.com okay so instead of sending a

script directly or sending a posting a

script on the server he sent the script

by the URL on his email so this is

basically where we sent the URL here we

have he sent a script on an email like

this way

HTTP okay gmail.com so he basically used

one legitimate domain slash he add the

script he add the script just give me a

second he add the script like uh script

scpt hi and

script so this is the script he

basically inserted with this URL and

sent a fishing email to this user which

is called kk.com so when user receive a

email he click on the link when he click

on the link it redirect to

Gmail Gmail received the complete URL

gmail.com with script so Gmail thought

user has requested for the script

without verifying he process script back

on the client system and by this way the

client system basically got crashed so

here we are not posting any script on

the server okay we using a script

embedded in the website web page web URL

sorry and we sent the script directly to

the client okay by a fishing link user

click on the link it basically request

server to open the

script if server is vulnerable for the

input validation it revert back the

script on the client system so this is

how the cross-site scripting reflective

cross scripting work that's why it's

called reflective it is a URL Bas it's

also called as a non-persistent stored

attack is called as a persistent and

reflected is called as a non-persistent

that's why we say malitia script

embedded in the URL executed immediately

upon clicking the link and the script is

not stored on the server so attacker

send a link containing a malitia script

and a URL parameter when user click the

link the server include the script in

the response execute in the user browser

so let me discuss how to identify

whether you are vulnerable or not see

when we talking about Crosset scripting

we look for many places where the user

input is expected like example where the

entering the text fields we basically

enter the search bar in the search bar

we also enter the scripts forms we have

user registration forms we have there we

enter then we have a URL parameters in

HTTP header we add there so this is how

the we enter the script script alert

script so this is the message which is

display okay

so sometime what happen we also need to

check how the application is basically

handle and render the user input if I

enter some suppose how to test so there

is a user form we have okay in which we

have a username and password in which I

will try to enter this particular script

if I enter the script and click on

submit and I'm getting a pop called xss

it means the server is vulnerable for

Crosset scripting if it's say invalid

value it mean it is protect from Cross

scripting so this is how you can able to

check how the application handle the

input sometime we have to review the

code and search for the place where the

input from HTTP request could possibly

make in a way of HTML output so these

are basically the parameters we have

that we consider so the question is now

how to basically secure so to secure the

things we basically use HTTP only and

secure flag in a cookie preventing

settings okay so this is something we

are using Okay so let's discuss this in

detail so first we're going to discuss

about uh HTTP only flag

see if you see the statement HTTP only

flag is used to enhance security by

restricting

access to cookies data from a client

side

script so question is how it work see

when any

cookie is basically set with the HTTP

only or HTTP only flag okay it is

basically tell the browser that

particular cookie should only be

accessed by the

server it mean this is basically a

client we have and he basically access

this particular site okay so this is the

site we have so this cookie is basically

access for this site only this cookie

cannot be misplaced or misused by any

other user because cookie is the way by

which we can able to track the session

because it's a HTTP is a stateless

protocol so any attempt to access the

cookie from a client side script which

is called Java is basically block and

this is particularly important in the

content of cross side scripting attack

so if any attacker manage to inject a

delicious script into the web page they

won't able to access the cookie marked

with the HTTP only which basically

prevent the script from stealing the

cookie data because when the script is

basically running on the client side the

script is trying to Fest the cookie so

here it basically prevent that so that

is why it is one of the most effective

Technique we are using in the Crosset

scripting second is basically we using a

secure the flag so secure flag is used

to ensure cookies are sent over the

secure channel so how it works is

normally what happen um you know when

when cookie set with secure flag overall

okay when cookies is basically set with

the secure flag it instruct the browser

to only send the cookie if the request

has been made over the secure protocol

such as https and this mean the cookie

will not sent over the unencrypted HTTP

which reduce the risk of cookie theft by

man in the middle attack so summar is

that HTTP only flag is primarily about

protecting the um cookie data from from

being accessed by unauthorized client

side script and thereby mitigating the

impact of Crosset scripting attack and

the secure flag Ure that cookies are

only transmit over the secure encrypted

connection protecting against the man in

the middle attack and both are the

essential for the robust web application

security

posture so the question is basically how

to review so when we talking about the

vulnerability detections okay so we

identify the user input source as a set

when user input the source and all that

input the value so that need to be

verified we also do the manual testing

on accss payload where we have a

security review the code and search for

all the PRS where input from HTTP

request could make it possible for HTML

output and we also use some kind of

automation scanning tool by which we can

able to identify the vulnerability in

the Crosset

scripting so prevention strategies

output encoding it mean whenever any

user feed

value it need to be verify it need to be

properly validate and we also implement

the content security policy which

inspect the content along with that we

also have a best practice like regularly

patch and update your servers secure

retaining for developers so they know

what is cross scripting so according to

that they write a code regular pen

testing on the application to test the

code and we also look for the monitoring

and auditing of the application along

with that we also have additional layer

like uh we can have a secure coding

practice use a web application firewall

so V we basically installed before

firewall like mode security and all that

and through that we try to block such

inputs and do the regular security

assessment now sometime what happen when

you're going for the application

security jobs they also ask some

questions so there are some questions

which is basically asked based on a

crossed scripting so example like there

will be question on what is crosses

scripting how does it works so you need

to explain

practicality and if you're able to

explain them well with this video also

it will be great second is can you

explain the difference between stored

cross scripting and reflected we already

disc discussed how can access attack be

preventative okay so this is a very

frequent question asked in the jobs then

there's a question on we'll give you the

piece of code identify if it's

vulnerable to accesses here they want to

test your skills whether you know

application security can you write a

simple script demonstrate reflected

across the scripting here they want to

test whether you are depend on tool or

do you have a special skill to send the

malicious URL and how do you implement

the content security policy here they

want to learn about whether you have a

development knowledge okay so that is

what we have

see uh we also have a comparison between

the Crosset scripting and Crosset

request fery uh I'm not going to discuss

Crosset fery in this video I have a next

video in which I'm going to explain the

Crosset request fery my suggestion is

that do watch that video also because by

then you can able to understand the Thin

Line difference between the cross

scripting and cross request fery so

cross scripting allow the attacker to

inject malitia script into the web page

which is view by the user and cross

scripting cross request fery it's a

vulnerability to take the user into

executing wanted action on the web

application so you can see like that in

Crosser scripting we exploit the trust

user has on the server because server is

basically process the script and return

back on the user machine but in the

cross a request fery we exploit the

trust server has on the user because

whatever the user clicks Ser will trust

that primary goal in the Crosset

scripting is to execute malicious script

in the user browser and in the Crosset

fraudery perform the unauthorized access

attack Vector in the Crosset scripting

is malicious script are injected into

the web content but in the cross request

fery maltia requests are sent to the web

application without user consent we'll

discuss okay in my next video we're

going to discuss user interaction does

not require user interaction but here

the user need to perform some action uh

data validation access policy both are

same dependency does not depend on the

user being authenticated because he

click unknowingly knowingly but in this

in the cross request fery he has to rely

on the link execute the content of user

browser and domain where we execute

request to Target site with the user

credentials as I said we'll discuss this

particular Topic in detail and then I'm

going to discuss the same table in my

Crosser request fery video okay then you

get a better visibility so do let me

know how do you find this video shall I

made more videos on the application

security and uh do share your feedback

in the comment section and which help me

to improve my content better thank you

so much good day bye