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.
In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.
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. XSS Attack Vectors
Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.
If you would like a deeper discussion on the different XSS attack vectors and examples of what they look like you should refer to the following article, which explains XSS, it's attack vectors and some more examples of what an attack looks like.
5. 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.vulnweb.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: <br><br>Please login with the form below before proceeding:<form action="destination.asp"><table><tr><td>Login:</td><td><input type=text length=20 name=login></td></tr><tr><td>Password:</td><td><input type=text length=20 name=password></td></tr></table><input type=submit value=LOGIN></form>, then simply hit the search button after inserting the code.
Please login with the form below before proceeding: <br><br>Please login with the form below before proceeding:<form action="destination.asp"><table><tr><td>Login:</td><td><input type=text length=20 name=login></td></tr><tr><td>Password:</td><td><input type=text length=20 name=password></td></tr></table><input type=submit value=LOGIN></form>, 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:
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.
6. 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”.
7. Preventing Cross Site Scripting Attacks
The purpose of this article is define Cross Site Scripting attacks and give some practical examples. Preventing XSS attacks requires diligence from the part of the programmers and the necessary security testing. You can learn more about preventing cross-site scripting attacks here.
8. 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 visithttp://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.
you also can follow this video
Whats Going down i'm new to this, I stumbled upon this I've found It absolutely useful and it has helped me out loads. I'm hoping to give a contribution & help other customers like its helped me. Good job.
ReplyDeleteTYC 20-6022-00 Dodge Driver Side Headlight Assembly