okay
good here we are uh our last
session is about web security so we have
uh
two talks the first one is uh uh by
avinash
ework is a security researcher for a
white ops
and he's originally from india and i
guess it would be
q a live from india
um he knows pretty well italy because he
did his phd in university of trento
uh so down here in italy trento there is
a research lab focusing on
security so we've been there and they've
also been with bruno casler
a research institute down here in italy
after that he moved to france
where he worked for sub lab france uh we
have similarity
uh between myself and himself i'm not
sure
amina she's aware of that but i also
work for uh sap lab france
in uh south france sophie antipa is
close to nica
and so yeah we can then you know
offline maybe share some uh thoughts
about
this experience with uh uh with this
company in the
french riviera uh after that he worked
as a researcher as a postdoc for
uh india with professor juan caballero
a good friend of mine he did a lot in
malwa research while avinash focus
exclusively on web so actually it's the
first time that i hear someone
uh working with juan but doing uh uh web
instead of malware so
uh very happy to know that uh you know
that one is also looking to
other aspects of security apart from
malware search
so in this presentation avinash we
talked of
cozy uh c-o-s-i which stand for
cross-origin state interference
uh he came up with this name and i'm
very much supportive
of having someone that formalized under
a single
umbrella a bunch of different attacks
that have been present over the last
five to six years but went with
different terms so now
we have a term that indicates a group a
family of attacks
and uh i'm looking for maybe to have
something or an organization like owasp
that would integrate such new term into
their
uh collection of uh of you know
security and web security
vulnerabilities all right so that's all
my side i would say
uh sit down relax have a coffee and
enjoy the next presentation
hello everyone i am avinash sudhodonan
first of all i would like to thank the
organizers of nohat2020
for giving me the opportunity to present
my research in front of such an amazing
diverse audience so today i am going to
be presenting
about cross-origin state inference
attacks so since it's a long name
throughout this presentation i'm going
to be referring to these types of
attacks as cosi attacks
so this is a joint work with sohail
khodayari from
cispasar broken and juan cavajero from
india software institute in madrid
so what is a koshi attack in a cosy
attack
a malicious website infers the state of
a user
at another website so let's see an
example to
further understand this attack so in
this example
there is a user alice who is playing the
role of the victim
alice has a web browser so
alice is a security researcher so alice
gets invites for being the reviewer of
security conferences
so here is a conference named foo foo
conf
that is using hotcrp.com for managing
its review process
so if any of you are into academic
security research
you know that most of the top security
conferences
now use a hot crp for managing their
review process
so same like that foo conf is actually
using hotcrp.com for
managing its review process and alice is
one of the reviewer of this conference
as you can see alice has been assigned
two papers for reviewing paper number
278
that was unfortunately rejected by alice
and then paper number 997 which was
accepted by alice
now let me introduce you malice who is
playing the role of the attacker
the goal of malice is to actually check
whether
alice is the reviewer of one of the
papers let's say paper number 278
but fucon fuses an anonymous review
system
so the authors will not know who
reviewed their papers
and the goal of malice is to exactly
break this anonymity
in the sense that malice wants to know
who reviewed
which paper so in this case let's say
malice wants to know
let's say malice was the author of paper
number 278
malice would like to know whether it was
alice who actually reviewed their paper
so in order to perform this attack
malice first
sends an email to alice saying
pretending to be let's say the
pc committee chair saying hi alice click
here to finalize your reviews of
foconf so alice if alice thinks
that they should click on this link and
accidentally clicks on this link
then a malicious website is actually
loaded at the web browser of
alice so this malicious website is
actually controlled by malice
and it is actually through this website
that malice
infers whether alice is actually the
reviewers of
some of the papers so
the goal of this malicious site is
actually to infer
cross origin across origins the state of
alice at different websites
so some of you must be thinking like
what does it mean by inferring the state
at food.hotcrp.com so let me explain
to you what are these states so
first let me show a simplified
representation of the attack there is
alice there is the web browser and the
two websites food.hotcrp.com
and the malsite.com which is actually
controlled by the attacker
and the male site's goal is to actually
infer the state of alice at
food.hotcrp.com
so what are the states that can be
inferred by mildside.com
the first type of state is the login
state the login state can have two
values
logged in state and logged out state so
inferring the login state can be seen as
the mail site.com inferring whether
alice is actually logged in at
food.crp.com or logged out of
food.hotcrp.com so
this type of attack where a website
infers the login state of another
website is commonly referred to as login
detection attack or login oracle attack
another type of state inference is the
account type state inference
that is the malsite.com inferring
whether alice has a reviewer account at
food.hotcrp.com
or whether else is simply an author or
if alice is the admin let's say the pc
chair of
food.hotcrp.com
another type of state inference is the
content ownership state in france
so let's say if alice is the reviewer of
paper 278
then alice will have ownership over the
reviews of paper 278
however if alice is not the reviewer of
paper 278 then alice will not have
access to the
reviews of paper 278.
next state is the account ownership
state so let's say there is
a user account uh with the user id user
217
so from the string user to n7 it is not
clear who actually owns this account
so if mal site wants to know
whether alice is the owner of this
account user 217
then that type of inference is called
the account ownership state inference
so this type of attack were
a malicious party links
an online account to a real world
identity that is user 217
to alice is commonly referred to as
de-anonymization attack
so to summarize what we discussed in the
slide in a cozy attack
the attacker's goal is to infer the
state of a user
at another website and cosi attacks have
been known by different names such as
login detection attack login oracle
attack the anonymization attack and
whatnot
so in order to understand how cosy
attacks can be performed
we need to understand what are state
dependent urls
because in cosy attacks state dependent
urls are leveraged
so what are the state dependent urls so
state dependent urls
are those urls that return different
http responses
depending on the requesting browser's
state
let's see an example of a state
dependent url so
in food.hotcrp.com there is
a url that is food.hotcrp.com
api.php slash review question mark p
equal to 278 so basically this
url is pointing to the reviews of the
paper number 278.
so why is this a state dependent url
it is a state dependent url because if
you access this url
from the state where you are logged in
at food.hotcrp.com
and you are logged in as a reviewer and
you are the reviewer of the paper number
278
then the http response returned will
have a status code of 200 and it will
return
in the response body the reviews of the
paper
however if you are in a state where you
are logged in at food.hotcrp.com
and you are a reviewer but however you
are not the reviewer of paper number 278
then an http response code of 403 is
returned
so comparing this to our example
let's say if mal site wants to know
whether alice is the reviewer of paper
number 278
then mal site can actually send a
request to this specific
state dependent url pointing to paper
number 278
and then the response returned will be
either 200 will have the status code of
200 or 403
depending on whether alice is the
reviewer of that paper number 278
or not however one thing must be noticed
the domains of the domain of malsite.com
and food.hotcrp.com
they are two different sites so they
don't have the same
web origin because of this difference in
the origin
the web browser will not allow
mildside.com to directly read the
response
response headers response code and the
response body
so because of this restriction mild site
will not be able to directly read the
response and infer that
alice is actually the reviewer of paper
278.
because of this restriction the attacker
will have to come up with different ways
to know what was the
response status code this is
where cross site leaks constant comes
into play
cross site leaks are basically browser
side channels
for inferring the response of
cross-origin responses
there are different types of cross-site
leaks discussed in the literature
i have actually listed some of them with
their references
due to lack of time we won't be able to
go through all of them but we will
go through one of them in very detail so
let's go through the events fired
cross-site leak
so let me give you a quick background of
what are like
dom events or browser events so
this is a bit basic information for
people who are
like already familiar with web
applications but
since we have a diverse audience i
wanted to make sure that everybody
understands what i'm saying
so web pages are basically defined using
the hypertext
markup language and there are html
elements
that are the building blocks of these
html pages
and each html elements are
actually defined using html tags for
example there is the head tag where all
the
uh links to the css and javascript goes
and then there is the body tag
and then there is the script tag and
there are many more tags
and some of these html tags can load
or include external resources for
instance here i have actually listed
some of the
top html tags so
these are the tags and they have some
attributes that basically takes as
values different urls
and these urls are actually pointing to
let's say if it is a
alpha applet html tag which is currently
deprecated
uh it has this code attribute pointing
to an
applet so basically these are tags that
can be used to
include different types of resources
so dom events can be leveraged to check
the status of these resources
so using those special html tags we are
actually including different types of
resources
so dom events are a feature that can be
leveraged to check
whether these resources were loaded
correctly or not
let's see an example so there is the
script
tag that that has the attribute
src in which you can actually point to a
script
javascript and then there are these
events on load and on error
so basically what happens is is if the
loading of this script is success
then the on load event is triggered and
then as a result of that the success
function is executed
if this url did not return
a javascript then the on error event is
actually fired
and this will result in the fail
function being executed
so why are we discussing about this it
is because in the
event fired access leak the
dom events are basically abused by the
attacker
so let's see how this is done so
in the malicious site the attacker here
uses the embed html tag and
points to the state dependent url that
we discussed earlier that is pointing to
the reviews of paper 278
and then the attacker defines the onload
event pointing to the reviewer
function and the on error event pointing
to the not reviewer function
so what happens when there is an html
tag defined like this
when when the user's browser loads
this mild site.com as a result of
this html tag an http request will be
sent
to this state dependent url and
if the user is actually logged in as the
reviewer of paper 278
then a 200 response code is returned
and as a result of that the on load
event is actually triggered because it
was a 200 response
and then the reviewer function is
actually executed so this means
alice is actually the reviewer of the
paper 278. similarly
if alice was not the reviewer of paper
number 278
then a response for of with code for not
three is actually returned and this will
cause the on
error event to be triggered and the not
reviewer function will be executed so
in this way mal site.com cano can know
what was the cross origin response that
was received
and then thereby determine whether alice
was the reviewer of paper number 270
paper number 278 or not
this might seem very easy in this
example
however there are different challenges
for mounting these types of attacks
so the first challenge is that multiple
states can have the same response
so here i just discussed the two states
where the user is the reviewer of paper
278 and not the reviewer of papers 278
and they have two different response
code however
what if the user was not even logged in
at hot
crp.com that is like the user is logged
out of hotcrp.com
when the attack has been performed when
this happens
then also a response code with
an http response with the status code
200 is
returned as you can see this is the same
as
the case where the user is actually the
reviewer of the paper
so what might happen is if the user
simply depends on the on load even being
fired
if the user is not even a member of
hotzierfood.crp.com
the attacker might think that they are
the reviewer of the paper
so this can lead to false positives
so as i said
uh the the the first and the last states
will
have similar uh impact that is the
onload event being fired and
lead to false positives so the second
challenge
the second challenge is that uh
different
exercises the same exercises access leak
payload
may work differently in different
browsers so let's see an example so the
example i
uh showed were the attacker is actually
using the embed.html tag to determine
whether the user is whether alice is a
reviewer or not a reviewer
it actually works only in firefox
and microsoft edge it will not work if
alice was using
a google chrome browser so
in order to handle google chrome there
is a way
the only difference is that instead of
the embed tag
the link tag should be used this is
because different tags
and the event even events fire
differently in different browsers
i think this is mainly because of the
difference in the underlying browser
engines
so in order to perform a cross-site
um leak attack uh in order to perform a
cosy attack
uh in a robust way
the attacker has to accommodate for
multiple states having the same response
and then
the same payload behaving differently in
different browsers
so in order to make the job of the
attacker easy
or in order to help security researchers
job easy
we defined or we introduced what is
known as
cosy attack classes so what are these
attack classes
they have a name and they have
the state dependent url responses that
it can differentiate
and then the cross site leak associated
to the attack class
and then the browser support details so
let's see an example
so this is one of the attack class that
we defined it basically
has the name event fires data error
script
it basically can differentiate between
a response with status code 200 and
a javascript content type and a response
with
a status code for xx or 5xx
response and the excess leak that is
used in this attack class is the script
html tag and the manifestation
of the difference in the response is
actually
visible through the on load and on error
events being fired
and this this attack class is basically
supported in all the three browsers
because we conducted various experiments
on these browsers with this type of
setting so same way
we identified a lot of different attack
classes
we conducted a lot of experiments with
with we tried to cover
almost all the html tags and
cross origin request sending
so precisely we identified 40
different attack classes for performing
cosi attacks
out of these 40 attack classes 21 of
them
were new attack classes in the sense
that they were not discussed previously
in the literature
and in as a part of this research we
even identified a completely noble
cross-site leak method a browser site
channel leak method
it is actually based on the post message
api so let me quickly explain to you
what is this novel
cross site leak method so
in order to understand this i will have
to quickly explain to you what is the
post message api
so the post message api allows windows
browser windows to talk to each other no
matter whether they are from the same
origin or a different origin
so to give you an example site1.com
can open site2.com in a new window
and then exchange messages with it using
the post message api
so this cross site leak that we
identified
that uses the post message api works in
the following way
so it is actually applicable to state
dependent urls having the following
property so
let's say there is a blog website
and there is a blog article with the id
123
so if someone visits this url that is
trying to fetch the admin panel of
this blog article then
if they are actually logged in as the
owner of this blog article
then an http response containing a
post message admin is actually returned
in the response
however if they are not the owner of
this article number one two three
then a post then a response with a post
message
error is actually returned when this
happens
uh let's say i'll let's say
there is a controversial blog posted in
blog.com with the id
123 and the malicious party wants to
know whether
alice is actually the author of this
this controversial blog article
what they can do is uh from ali's web
browser
they can actually uh open a malicious
site
and this malicious site can actually
open this
state dependent url in a new window and
as i said if alice is actually logged in
as the owner of this
article so in that case alice will have
the state
owner of article 123 in blog.com
what happens is that the state dependent
url
that is in this window will there will
be
the code for sending the post message
admin as i said
this is the response received if the
alice was the owner of the article 123
and what this will cause is that since
it's a
broadcast post message
this message is actually received by the
malicious side
it is a broadcast message so it is
actually received by
all the sites which are actually opening
it and
since the message is admin as you can
see the message
admin is received on if the state is
actually the owner of article 123
so in that way the malicious site can
know that alice is actually the owner of
this controversial article
123 returned by an anonymous
user account at blog.com
so yeah this is basically the code to
check whether if it's the admin
message received then it's like the
status that the or it is the owner of
the article
so there are actually a lot of related
work
done uh when it comes to cosy attacks
however
there are some limitations so it is a
bit
messy in the sense that different people
call these attacks different names like
login detection login oracle url status
identification etc
and there is not much discussion on the
need to handle these
overlapping states and then the support
for multiple browsers that is the same
attack payload working differently on
different browsers and all this
and then there is also not much
discussion on automatic detection of
cosy attacks
and the automatic creation of attack
pages
so this is where we focused on our
research so
these are the contributions of our
research
we present cozy attacks as a
comprehensive category
instead of calling them different names
and then we introduce the concept of
attack classes
to know which attack class works on
which browsers and
is based on which leak method and then
we identify
a new cross site leak method based on
the post message api i explained this
earlier
and then uh we present bastakosi
uh italians must be familiar with the
name bastakosi
uh and it that's the name of our tool
that can be used to
automatically identify uh kosi attacks
and build complex attack pages
so if you have a website you would like
to check for
cosy attacks you can just run basta oc
against your website
so once we had the tool we tested four
standalone web applications and 500 top
websites from the alexa top sites and we
discovered cosy attacks on all of them
so let me explain to you the basic
architecture of our tool
so the tool basically takes as input
selenium scripts to load different
states in web browsers
and then after uh after we have the
selenium scripts we know how to load the
states in the browsers
and then we want to collect different
state state
dependent urls so we leverage
a web app crawler to in order to
automatically identify different state
dependent urls
then once we have the state dependent
urls of the application under test
uh we identify the attack vectors that
are perfect or suiting for these state
dependent urls
and then we combine these identified
attack vectors
and generally automatically generate
attack pages
and then these attack pages can be
are like proof of concept to show that
uh there is a cross-site cosy attack
against the web application under test
so as i said we conducted an evaluation
using our tool on top
websites so we tested four standalone
web applications such as
hot crp gitlab github enterprise and
opencart
and 58 websites from the alexa top 150
sites
since we since we deal with states
we focused only on those top websites
having
the account creation feature the result
was that we found at least one cosy
attack on all the tested sites
we responsibly disclosed uh the
identified vulnerabilities and
most of them were confirmed and some are
already fixed and
we even received bug bounties for our
report
so let me explain to you some of the
most interesting ones that
uh well vulnerabilities that we
identified so in hotcrp.com which is
used by most of the top
security conferences for anonymous
reviewing system we identified that an
attacker can identify
the anonymous reviewers of any paper
and then in blogger blogger.com which is
owned by google we
identified that it is possible for an
attacker to
identify and the author of an anonymous
blog article
then in google drive it is possible to
know whether the victim is the owner of
a
sensitive file that was uploaded to
google drive
and then in pornhub it was possible to
know
if the user the victim is the owner of a
specific porn channel
this can be a very sensitive information
so for some people
and then in websites such as imdb inger
and linkedin we noticed that an attacker
can
track users by abusing cosy attacks
across different browsers and across
different devices this is because the
website in website in which they are
logged in that is imdb linkedin and
inger are actually leaking their
identity to other websites
and uh just to clarify this uh
these attacks work even if you use like
uh
um anonymization services such as store
because these are like browser leaks and
then
in github and git lab it was possible
for the malicious party to identify the
roles of the victim on private reports
so let's say there is a private github
repository with a very
sensitive hacking tool these
nation states can actually determine who
actually worked
on those tools and who has access to
those repositories
so all these experiments were
performed in a very responsible manner
using the accounts that we controlled so
how can we defend from cosy attacks
so there are two types of defenses one
is the website based defense that the
website can actually
use to defend against these attacks so
the first type
uh should be famous for people uh
working in the web security domain that
is same site cookies
so same site cookies automatically
prevent
uh the sending uh sending of
cookies in a third party context so we
saw that the malicious site is sending
requests to
food.hotcrp.com and it is actually
when this happens the cookies are
automatically sent with this request so
basically same side cookies are a way
to prevent the automatic sending of
these cookies and then there are other
header based defenses such as
cross origin resource policy fetch
metadata and cross
origin opener policy you can read more
about them
in their documentation to understand
more of how these can be
implemented then there are browser-based
defenses
that can be used uh by uh you like
users who use the browse on the web to
defend against cosy attacks
so one of the defense is to enforce the
default
uh same site policy most
top browsers are actually moving in this
direction and some of them have already
implemented this protection
the tor browser interestingly when we
tested
it behaved as if it had the default
same site protection that is not sending
uh cookies in the third party context
however during our experiments we notice
that it
this does not prevent window based
attack such as the post message attack
that we explained
and there is also this other attack
using the frame count
so we actually responsibly reported this
to tor
and they actually took our report
seriously and they are actually planning
to fix this
so to conclude my talk uh
we present different cosy attacks uh as
a comprehensive category introduced the
concept of cosy attack classes
we identified a new cross-site leak
based on the post message api
we present basta kosi a tool to
automatically identify cosy attacks
and then we test different standalone
applications and
top websites and identify cosy attacks
on each of them
so the technical details of our work are
actually available
in archive so you can click this link
to actually get more details so
if you have any questions please
please let me know
hello my friend do you hear me yeah i
can hear you can you hear me
yeah perfect perfect she was from italy
i was in india
it's fine i just got married two weeks
ago so yeah
you told me i was to get married with a
lockdown yeah it was challenging but
also
uh it was fun because usually in india
there are like a thousand people
attending the wedding because of
lockdown it came down to like 50 so it
was less challenging
it's okay
yeah yeah
cool so uh thanks for submitting to our
conference
and i hope you enjoyed what you've done
so far
uh so we had a lot of questions coming
up i can count at least
five of them uh so the first one here i
can read
is about fact that uh
yeah you define the new term if you want
i mean all these different
vulnerabilities that
were unclassified before now they go
under the same category that you define
as cosi
so the question is if you add any
feedback from always for our
standardization community and try to
adopt
such new category for example in uh
in to community vulnerabilities closure
or
that kind of things basically so this is
actually a good question
so but if you think in a critical way
what happened was
there are already a lot of different
names for these attacks and although we
systemized it we also introduced a new
name so it's like we
added a bit of more mess right so
uh when we actually observed uh during
the time this research was conducted
there was already an active discussion
on like you know how to call these
attacks like you know to bring under a
common umbrella and everything
and uh google was actually uh taking a
lot of effort in doing this
and finally the term that was actually
after a lot of service and everything
the term that they agreed to call these
kind of attacks was
access leaks and recently they even
started a website
uh called uh access yeah access
leaks.com
where like uh to actually modify uh yeah
the different ways to perform them so
excess leaks became like the most like
you know the common terminology that can
be used to call the
attack so i'm happy in a way that i
didn't contribute to a new name and then
like you know people had
learned this new name but like the
community adapted to the name which was
mostly familiar with among a lot of
people
so yeah well it's a great recognition
when you do research
to see that what you do actually has an
effect on
some form right so good stuff uh
okay great i will maybe uh discuss this
later on with michael and giuseppe that
come after your talk
and they also work in web security
domain so i want to hear their feedback
on this
but let's move forward with the next
question which
there was someone that was uh
yeah i didn't really understood the way
in youtube you can
automatically map the return code to the
different status of application
as you saw in this show in the slide now
if the returns code is for example 200
then
it means that the user is logged into
the web application and possibly
assigned to review a
paper right if instead if it's for free
is it it doesn't have a
ground it's not granted to uh to review
a paper
so uh do you need to uh
to have like access to the web
application under test like to be able
for example to
load the application source code and so
on or can you do like a black box
testing of application to drive uh this
mapping
yeah sure so it is possible to actually
do both
in fact we did both approaches like
uh we tested this for uh standalone
applications
and a lot of alexa sites and these top
websites
their source code is actually not
available so we used a
black box approach for these top sites
like we created accounts in them
and we crawled the application and we
fetched a lot of these
state dependent urls and then we tried
to access these urls from
different states and see saw whether
they are returning different responses
or not
uh okay okay yeah and then for the white
box approach like hot crp it's actually
an open source
uh application so we actually identified
because
uh by crawling the application we did
not find those because we wanted to
know whether we can be anonymize
reviewers and through a black box
approach
uh we our automatic cloud did not find a
url that can actually do this
then we actually check the source code
to see whether there access such urls
and we identified the url that actually
showed in the
uh paper and then we actually through a
white box way we identified that url so
an approach that mixes both styles is
actually better for this
yeah for sure you have a you have a
larger
you know testing environment basically
uh that also bind also to the next
question which is how you select the
application i mean you mentioned that
you select the top
alex of replication that's a common
technique when you do like a research
just like top
ten top one and whatever so did you just
pick up the top android whatever or did
you go for those one uh i don't know
if you can elaborate on that aspect
sure yeah so this uh research was done
uh
mostly from like you know academic uh
point of view
but then we also wanted to have an
impact in the uh
like you know among like you know people
working on web security but who are not
very much linked to the academic
side so that's why we chose applications
in which there are sensitive states for
example um
hotcrp.com de-anonymizing the viewer is
interesting for like the academic
security side community
and then like you know knowing whether
someone wrote an
uh an anonymous blog is interesting for
like you know the general community
and then we wanted to show that these
attacks exist or these vulnerabilities
exist
on top websites so to do like a
systematic research we chose the top 150
sites
and as i said it's a bit uh it's a bit
uh
time consuming in the sense we have to
create accounts in these sites multiple
accounts because we want to see whether
one user can infer another user's
details
and then like create different states
and then as i said we use an automatic
tool so we have to like write selenium
scripts of these tools
and then like you know run the crawler
so it took a lot of effort this is why
we could only test one fixture inside
yeah for sure
so yeah understand understand yeah let's
also bind to the next question again
so you use selenium basically to test
the application
in this case uh do you find the way do
you think
it would be possible to automatically
patch an application to make actual
attack more difficult so
suppose the application or use different
return codes
you decide actually to merge this return
code so you just use a subset of
this return code is there a way to
automatically patch this application or
yeah so there are like uh two different
types of defenses as i showed like
the browsers can take some steps and the
web applications can take some steps
so uh uh this is what the hot crp
application does
when did when we actually reported to
them they actually standardized uh
decided to standardize their response
codes like so that it always returns a
200
with the same type of response body so
it's not
possible to actually infer through side
channels like you know what was the
uh response because it's always a 200.
so it is possible to implement these
kind of defenses
but then there is always like you know a
url that you did not patch or something
so
when you try to like patch the
application itself it becomes more
challenging
this this is the reason why like same
sites cookies is actually been pushed by
google because
it is like one of the defense that as
you can imagine it can actually break a
lot of applications but still
google decided to actually uh and a lot
of other
top browsers to decided to make it
default it's because like you know
uh it makes these attacks very difficult
so both sides are actually it's possible
to actually
kind of like in an automatic way reduce
the impact of these kind of attacks
yeah maybe left for future work i mean
it's not as easy you know this
automatically
yeah then we have someone
actually visual we have name okay we
have so many questions
so i will go i guess for two more
because we're already out of time here
so jennifer is asking
isn't csp supposed to mitigate this
category of attacks
and if it's not the case do you think it
should be extended to cover cozy
so uh like if you check the paper
uh if you will know that one of the side
channels
is basically csp so as a security
um a security feature that was actually
used that is actually meant to protect
the application is kind of can be used
as a side channel to leak
uh perform this attack so uh
i mean there are actually uh
preventive measures browser-based
preventive measures like csb
which is actually i showed in the
defense system there are different
headers
that are actually uh available to
prevent mitigate these attacks
but i would actually agree to this like
uh making it like instead of telling
different headers for different
responses
making it kind of like you know part of
let's say csp so that it can actually be
used to
uh prevent this kind of attacks it's
kind of like a sensible way
so yeah the community is actually moving
in that direction but csp has its own
problems like
many people are not willing to adopt it
because of a lot of issues
so there are also different challenges
so if you go through the csp approach
okay thank you and then we have uh
giovanni that says thank you for the
talk great uh would you mind clarify our
post message is fire when visiting
a targeted as the url
yeah so there are like post messages
that can be sent to specific uh domains
so let's say your page wants to send a
message to your
parent window you can send you can
verify the origin and send that message
however if there are ads on your page
ads are shown on different
pages right so they don't they cannot
send a targeted message
so what they do is like they broadcast
the message so that like
whichever page opened them receives that
message
so then you send a broadcast post
message
or if the sd url returns an html
page that broadcasts a message then it
can be
received by the attack page if it just
opens it in a new window
so this is actually the broadcast
feature and post message that just can
be that can be abused and
in google uh blog blogger of google this
was the problem like
the ad was actually broadcasting a
message and through this we were able to
infer the state so it's the broadcast
message feature
okay thank you uh i would say it's going
to conclude the last
question so there is someone asking if
this
basta cozy tool can be downloaded i mean
if you are planning to
release it or you are still working on
that so if you can elaborate on this
tool yeah so this was actually
developed as part of a larger open
source project on
testing applications so a mini minified
version of this
tool is available uh as part of this uh
project called elast
so it is already available the open
source but as i said it's a it's for
large
uh large type of testing like it
includes functionality testing
and normal cross browser testing and
everything so if you are interested you
can check from there otherwise it's just
bring me
right and i can send you the full
version uh yeah
okay great uh so do you have other
comments do you have anything to say to
our audience
or you happy with that or yeah
like i would like to congratulate the
organizers because we had so many
challenges
extending the deadlines and pandemic but
in the end i'm really happy that
everything went well
today and there are there's a lot of
participation so i'm happy to see this
yeah i will give some numbers in the
closing after
uh the next talk about how many people
participate and we're actually pretty
happy
so if you will be online you can uh
you can attend the closing session uh so
thanks a lot for being with us and i
hope to see you
again at some conference in person when
we have a
chance to travel thank you and
see you soon thank you