Cross Site Scripting (XSS) – The Underestimated Exploit
Sunday, February 24, 2008
1. What is Cross Site Scripting?
Cross Site Scripting (or XSS) is one of the most common application-layer web attacks. XSS commonly targets scripts embedded in a page which are executed on the client-side (in the user’s web browser) rather than on the server-side. XSS in itself is a threat which is brought about by the internet security weaknesses of client-side scripting languages, with HTML and JavaScript (others being VBScript, ActiveX, HTML, or Flash) as the prime culprits for this exploit. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page which can be executed every time the page is loaded, or whenever an associated event is performed.
A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The malicious page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who can now hijack the legitimate user’s session. Although no real hack has been performed against the shopping site, XSS has still exploited a scripting weakness in the page to snare a user and take command of his session. A trick which often is used to make malicious URLs less obvious is to have the XSS part of the URL encoded in HEX (or other encoding methods). This will look harmless to the user who recognizes the URL he is familiar with, and simply disregards and following ‘tricked’ code which would be encoded and therefore inconspicuous.
2. Site owners are always confident, but so are hackers!
Without going into complicated technical details, one must be aware of the various cases which have shown that XSS can have serious consequences when exploited on a vulnerable web application. Many site owners dismiss XSS on the grounds that it cannot be used to steal sensitive data from a back-end database. This is a common mistake because the consequences of XSS against a web application and its customers have been proven to be very serious, both in terms of application functionality and business operation. An online business project cannot afford to lose the trust of its present and future customers simply because nobody has ever stepped forward to prove that their site is really vulnerable to XSS exploits. Ironically, there are stories of site owners who have boldly claimed that XSS is not really a high-risk exploit. This has often resulted in a public challenge which hackers are always itching to accept, with the site owner having to later deal with a defaced application and public embarrassment.
3. The repercussions of XSS
Analysis of different cases which detail XSS exploits teaches us how the constantly changing web technology is nowhere close to making applications more secure. A thorough web search will reveal many stories of large-scale corporation web sites being hacked through XSS exploits, and the reports of such cases always show the same recurring consequences as being of the severe kind.
Exploited XSS is commonly used to achieve the following malicious results:
* Identity theft
* Accessing sensitive or restricted information
* Gaining free access to otherwise paid for content
* Spying on user’s web browsing habits
* Altering browser functionality
* Public defamation of an individual or corporation
* Web application defacement
* Denial of Service attacks
Any site owner with a healthy level of integrity would agree that none of the above can really be considered us frivolous or unimportant impacts on a vulnerable site. Security flaws in high-profile web sites have allowed hackers to obtain credit card details and user information which allowed them to perform transactions in their name. Legitimate users have been frequently tricked into clicking a link which redirects them to a malicious but legitimate-looking page which in turn captures all their details and sends them straight to the hacker. This example might not sound as bad as hacking into a corporate database; however it takes no effort to cause site visitors or customers to lose their trust in the application’s security which in turn can result in liability and loss of business.
4. A practical example of XSS on an Acunetix test site.
The following example is not a hacking tutorial. It is just a basic way to demonstrate how XSS can be used to control and modify the functionality of a web page and to re-design the way the page processes its output. The practical use of the example may be freely debated; however anyone may see the regular reports which describe how advanced XSS is used to achieve very complex results, most commonly without being noticed by the user. I encourage also those individuals with no hacking knowledge to try the following example, I am sure you will find it interesting.
1. Load the following link in your browser: http://testasp.acunetix.com/Search.asp, you will notice that the page is a simple page with an input field for running a search
2. Try to insert the following code into the search field, and notice how a login form will be displayed on the page:
Please login with the form below before proceeding:
Please login with the form below before proceeding:, then simply hit the search button after inserting the code.
Through the XSS flaw on the page, it has been possible to create a FAKE login form which can convince gather a user’s credentials. As seen in step 2, the code contains a section which mentions “destination.asp”. That is where a hacker can decide where the FAKE login form will send the user’s log-in details for them to be retrieved and used maliciously.
A hacker can also inject this code by passing it around via the browser’s address bar as follows:
http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+
the+form+below+before+proceeding%3A%3C form+action%3D%22test.asp%22%3E%3C
table%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3D
text+ length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3C
td%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput +type%3Dtext+length%3D20
+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput
+type%3Dsubmit+value %3DLOGIN%3E%3C%2Fform%3E
This will create the same result on the page, showing how XSS can be used in several different ways to achieve the same result. After the hacker retrieves the user’s log-in credentials, he can easily cause the browser to display the search page as it was originally and the user would not even realize that he has just been fooled. This example may also be seen in use in all those spam emails we all receive. It is very common to find an email in your inbox saying how a certain auctioning site suspects that another individual is using your account maliciously, and it then asks you to click a link to validate your identity. This is a similar method which directs the unsuspecting user to a FAKE version of the auctioning site, and captures the user’s log-in credentials to then send them to the hacker.
5. Why wait to be hacked?
The observation which can be made when new stories of the latest hacks are published is that the sites which belong to the large brands and corporations are hacked in exactly the same way as those sites owned by businesses on a much smaller budget. This clearly shows how lack of security is not a matter of resources, but it is directly dependant on the lack of awareness among businesses of all size. Statistically, 42% of web applications which request security audits are vulnerable to XSS, which is clearly the most recurring high-risk exploit among all the applications tested. The effort to raise awareness about how easy it is for an expert hacker to exploit a vulnerable application does not seem to be going too far. It is still very common to see the “We’ll see when I get hacked” mentality still lingering among site owners who finally risk losing a lot of money and also the trust of their customers. Anybody with the interest to research this matter will see how even individuals claiming to be security experts feel comfortable to state that XSS is over-rated and cannot really be used to achieve serious results on a web application. However further research will also prove that statistical figures speak for themselves, and those same statistics keep growing at a rate which will eventually overcast the claims of those incredulous “experts”.
6. Scan your site for XSS with the Free Edition of Acunetix WVS.
Acunetix Web Vulnerability Scanner Free Edition offers the functionality for anyone who wants to test their own application for Cross Site Scripting. Acunetix encourages all site owners and developers to visit http://www.acunetix.com/cross-site-scripting/scanner.htm and to download the Free Edition of Acunetix WVS. This Free Edition will scan any web application for XSS and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the application) and indeed can surprise all those who really wish to see where their web site stands from a security point of view.
DOWNLOAD YOUR FREE EDITION AND CHECK IF YOUR SITE IS VULNERABLE TO XSS TODAY!
Cross Site Scripting (or XSS) is one of the most common application-layer web attacks. XSS commonly targets scripts embedded in a page which are executed on the client-side (in the user’s web browser) rather than on the server-side. XSS in itself is a threat which is brought about by the internet security weaknesses of client-side scripting languages, with HTML and JavaScript (others being VBScript, ActiveX, HTML, or Flash) as the prime culprits for this exploit. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page which can be executed every time the page is loaded, or whenever an associated event is performed.
A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The malicious page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who can now hijack the legitimate user’s session. Although no real hack has been performed against the shopping site, XSS has still exploited a scripting weakness in the page to snare a user and take command of his session. A trick which often is used to make malicious URLs less obvious is to have the XSS part of the URL encoded in HEX (or other encoding methods). This will look harmless to the user who recognizes the URL he is familiar with, and simply disregards and following ‘tricked’ code which would be encoded and therefore inconspicuous.
2. Site owners are always confident, but so are hackers!
Without going into complicated technical details, one must be aware of the various cases which have shown that XSS can have serious consequences when exploited on a vulnerable web application. Many site owners dismiss XSS on the grounds that it cannot be used to steal sensitive data from a back-end database. This is a common mistake because the consequences of XSS against a web application and its customers have been proven to be very serious, both in terms of application functionality and business operation. An online business project cannot afford to lose the trust of its present and future customers simply because nobody has ever stepped forward to prove that their site is really vulnerable to XSS exploits. Ironically, there are stories of site owners who have boldly claimed that XSS is not really a high-risk exploit. This has often resulted in a public challenge which hackers are always itching to accept, with the site owner having to later deal with a defaced application and public embarrassment.
3. The repercussions of XSS
Analysis of different cases which detail XSS exploits teaches us how the constantly changing web technology is nowhere close to making applications more secure. A thorough web search will reveal many stories of large-scale corporation web sites being hacked through XSS exploits, and the reports of such cases always show the same recurring consequences as being of the severe kind.
Exploited XSS is commonly used to achieve the following malicious results:
* Identity theft
* Accessing sensitive or restricted information
* Gaining free access to otherwise paid for content
* Spying on user’s web browsing habits
* Altering browser functionality
* Public defamation of an individual or corporation
* Web application defacement
* Denial of Service attacks
Any site owner with a healthy level of integrity would agree that none of the above can really be considered us frivolous or unimportant impacts on a vulnerable site. Security flaws in high-profile web sites have allowed hackers to obtain credit card details and user information which allowed them to perform transactions in their name. Legitimate users have been frequently tricked into clicking a link which redirects them to a malicious but legitimate-looking page which in turn captures all their details and sends them straight to the hacker. This example might not sound as bad as hacking into a corporate database; however it takes no effort to cause site visitors or customers to lose their trust in the application’s security which in turn can result in liability and loss of business.
4. A practical example of XSS on an Acunetix test site.
The following example is not a hacking tutorial. It is just a basic way to demonstrate how XSS can be used to control and modify the functionality of a web page and to re-design the way the page processes its output. The practical use of the example may be freely debated; however anyone may see the regular reports which describe how advanced XSS is used to achieve very complex results, most commonly without being noticed by the user. I encourage also those individuals with no hacking knowledge to try the following example, I am sure you will find it interesting.
1. Load the following link in your browser: http://testasp.acunetix.com/Search.asp, you will notice that the page is a simple page with an input field for running a search
2. Try to insert the following code into the search field, and notice how a login form will be displayed on the page:
Please login with the form below before proceeding:
Please login with the form below before proceeding:, then simply hit the search button after inserting the code.
Through the XSS flaw on the page, it has been possible to create a FAKE login form which can convince gather a user’s credentials. As seen in step 2, the code contains a section which mentions “destination.asp”. That is where a hacker can decide where the FAKE login form will send the user’s log-in details for them to be retrieved and used maliciously.
A hacker can also inject this code by passing it around via the browser’s address bar as follows:
http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+
the+form+below+before+proceeding%3A%3C form+action%3D%22test.asp%22%3E%3C
table%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3D
text+ length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3C
td%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput +type%3Dtext+length%3D20
+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput
+type%3Dsubmit+value %3DLOGIN%3E%3C%2Fform%3E
This will create the same result on the page, showing how XSS can be used in several different ways to achieve the same result. After the hacker retrieves the user’s log-in credentials, he can easily cause the browser to display the search page as it was originally and the user would not even realize that he has just been fooled. This example may also be seen in use in all those spam emails we all receive. It is very common to find an email in your inbox saying how a certain auctioning site suspects that another individual is using your account maliciously, and it then asks you to click a link to validate your identity. This is a similar method which directs the unsuspecting user to a FAKE version of the auctioning site, and captures the user’s log-in credentials to then send them to the hacker.
5. Why wait to be hacked?
The observation which can be made when new stories of the latest hacks are published is that the sites which belong to the large brands and corporations are hacked in exactly the same way as those sites owned by businesses on a much smaller budget. This clearly shows how lack of security is not a matter of resources, but it is directly dependant on the lack of awareness among businesses of all size. Statistically, 42% of web applications which request security audits are vulnerable to XSS, which is clearly the most recurring high-risk exploit among all the applications tested. The effort to raise awareness about how easy it is for an expert hacker to exploit a vulnerable application does not seem to be going too far. It is still very common to see the “We’ll see when I get hacked” mentality still lingering among site owners who finally risk losing a lot of money and also the trust of their customers. Anybody with the interest to research this matter will see how even individuals claiming to be security experts feel comfortable to state that XSS is over-rated and cannot really be used to achieve serious results on a web application. However further research will also prove that statistical figures speak for themselves, and those same statistics keep growing at a rate which will eventually overcast the claims of those incredulous “experts”.
6. Scan your site for XSS with the Free Edition of Acunetix WVS.
Acunetix Web Vulnerability Scanner Free Edition offers the functionality for anyone who wants to test their own application for Cross Site Scripting. Acunetix encourages all site owners and developers to visit http://www.acunetix.com/cross-site-scripting/scanner.htm and to download the Free Edition of Acunetix WVS. This Free Edition will scan any web application for XSS and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the application) and indeed can surprise all those who really wish to see where their web site stands from a security point of view.
DOWNLOAD YOUR FREE EDITION AND CHECK IF YOUR SITE IS VULNERABLE TO XSS TODAY!
Hack yahoo messenger and google talk to open multiple instances at a time
Sunday, February 17, 2008
HERE’s a simple hack for yahoo messneger and google talk through which u can create multiple instances if in case u need to..
FOR YAHOO MESSENGER
Go to Start -> Run -> Type regedit -> hit enter
Go to HKEY_CURRENT_USER->> Software ->> Yahoo ->> pager ->>Test
Right click on test -> choose new Dword value .
Rename it as Plural.
Double click it -> assign a decimal value of 1.
Close registry -> Restart yahoo messenger.
NOW you can open yahoo messenger N number of times
FOR GOOGLE TALK
- Create a shortcut of Google Talk messenger on your desktop or any other location.
- Right click on the Google Talk messenger icon and select properties option
- Modify target location text by this
“c:\program files\google\google talk\googletalk.exe” /startmenu
to
“c:\program files\google\google talk\googletalk.exe” /nomutex
- Click OK
Now you can run multiple instances of google talk .
Posted by
dinesh
at
10:33 AM
0
comments
Labels: google, gtalk hack, how to hack google, internet, messenger hacking, yahoo, yahoo messenger hack
Access Stored User Names and Passwords with rundll32.exe
Thursday, February 14, 2008
The Stored User Names and Passwords applet lets you assign user names and passwords to use when needing to authenticate yourself to services in domains other than the one you are currently logged into. The normal way of running this applet can be difficult to find quickly, so here is a way to launch it using a desktop shortcut using the rundll32.exe program:
Click on START - RUN and type the following (followed by ENTER):
rundll32.exe keymgr.dll,KRShowKeyMgr
Subscribe to:
Posts (Atom)
Posts
