A proper acronym for cross-site scripting is Exocets as she says is already reserved for cascading style
sheets.
Anyway this attack used to be extremely popular in the past.
It's still very widespread.
Exocets relies on the fact that most Web sites are active to some degree Web sites display information
and also allow users to post some information as well.
Since a two way communication is available we can use this to place something on an external website.
We can run the following attack first.
We'd like to embed a malicious script on a Web site.
It can be embedded directly on the site in the easiest case the site will have a comment box.
This can be exploited to leave DML tags next to a comment so that the script is created.
After this is done we wait for a visitor to display the site
once it's displayed.
A browser will render the entirety of the page including our script the script payload is up to us script
can be embedded on a Web site or placed inside a link to a page that is sent to the victim this variation
is the basis for the division of cross-site scripting attacks into two types.
Reflected Exocets and persistent excesses
are reflected Exocets the attack occurs when an attacker communicates with the victim directly.
We'll see an example of this attack in a moment.
We can for example be persuaded to click on the following address.
Although we're connected to a bank page we also launched a script that is not stored in the page.
The bank website is not compromised.
It has not been broken into.
It's our assertion that is no longer secure.
This attack can be delivered in a number of ways.
We can for example be redirected to a different page without noticing it.
We can also launch a script on a trusted page that comes from a different page
a persistent cross-site scripting attack on the other hand relies on placing malicious code directly
onto a Web site instead of putting it in a link.
For example in an email this type of attack is definitely easier to detect.
It's also larger in scale.
Let's see how this works in practice.
I assume you've received the following e-mail message this message doesn't look too suspicious.
You can see that it was sent from a bank branch.
There are no mistakes in language.
The message reads unambiguous and doesn't seem to raise any doubts the email doesn't ask you for your
log in or password or pressure you to log in the next 35 seconds to get a prize.
There's no such tactics in this message.
All it asks you to click on a link to log in as you can plainly see in the status bar of the browser
a hidden longer address lurks underneath the link.
It's longer than expected anyway.
We still click it we were redirected to a logging page of the bank.
It looks familiar.
The page looks no different than it looked before.
Everything seems in perfect order until you take a look at the address bar.
It turns out that while the bank page is displayed on the screen a script is running at the same time.
To get a better picture of the situation we can copy this script into a notepad.
The script here is not contained in the bank page.
It's a javascript called Snoop.
We can assume that the script will be executed soon because we can see an event that launches it
assume that we haven't caught all of this and decided to log in after clicking a logging link.
There is a window that looks normal but that there's a missing log in and password something strange
pops up.
The right side was never originally part of the window actually even now it's not visible.
The script we show simply aims to demonstrate that an attacker has access to the credentials we submit
if correct credentials are submitted.
We logged in correctly.
There's one problem though we've just fallen victim to across a scripting attack despite the fact that
we're connected to a trusted and unmodified page.
We have connected to it in such a way that the location of the script that will be executed by us in
a moment was also sent.
The script is contained on a server controlled by a black hat hacker
this type of attack can be thwarted quite easily even using automated tools.
Note that when you click on the link in the email again the browser prompts a message stating that it's
modified the page source code.
This time a logging attempt doesn't cause any adverse side effects.
The browser detected that the page code contains links to scripts stored on external servers under different
addresses.
It commented them out before interpreting the code.
Below you can see a script that was executed on this page it aims simply to read the values of user
supplied log in and password fields.
The last topic will briefly cover relates to session hijacking.
Session hijacking is an event of impersonating a user that has been authenticated to an application.
It doesn't involve cracking or guessing a user's password.
An attacker waits for a user to log on and logs as well along that user
this attack scenario is in particular a threat to web applications.
Especially since many of them use h t t p since HTP is a stateless protocol.
It has to simulate a session in some manner.
A session is simulated in this case by the advent of adding identification data to each query
the data in question could be cookies or other data placed inside you are a address's.
This means that a cookie an unprotected text file is a temporary credential.
If someone obtains a cookie that person can impersonate us in the application
if we've been previously authenticated to that application the highjacker will also be authenticated.
See a wireshark session where an HTP cookie has just been intercepted.
This however can be done easier even without resorting to wireshark
a Firefox add on such as fire sheep can be used for this purpose.
The extension works just like wireshark.
It listens on for users transmitting cookies to a selected array of Web sites.
If an exchange is detected the sniffer steals the cookie and shares the use of the cookie with the legitimate
user a server is not alarmed if someone sends more than one copy of a cookie to pull the attack off.
An attacker needs only to share a medium with a targeted user.
This is viable for example in an Internet cafe.
What methods can be engaged to foil such an hijacking.
It's possible to bind a certain identifier to something that identifies a user uniquely for example
by a session identifier to computer data a Mac address or an IP address.
This produces one problem using Wi-Fi networks.
We sometimes switch between various access points computer configuration can change during this process
and losing a session needs to be avoided for example because we're in the middle of some important operation.
The solution is quite intrusive.
An alternative is encrypting all traffic using TTP s this encryption would also make a cookie encrypted
extracting cookies from packets would no longer be possible.
This module discussed typical application attacks.
The major focus was placed on database server.
Since most applications today make use of them even if you're not aware of it.
Other than that buffer overflow attacks were covered as well as cross-site scripting both of these attacks
target web site visitors and now Web sites.
At the end authenticated session highjacking information was proposed to sum up the topic.
Thank you.