One of the largest portals was in news recently when their website was exploited by targeting an XSS vulnerability. This was after the application audit for the website was concluded. This attack showed that injecting XSS is possible using the “Custom XSS attack vector” method.
In this paper, I will be explaining two major aspects of Cross-Site Scripting Attack:
A quick look into the types of XSS
Stored XSS – Stored XSS are the ones where the injected code is permanently stored on the target servers, such as in a database, message forum, visitor log, comment field, etc. The victim retrieves the malicious script from the server when it requests the stored information.
Reflected XSS – Reflected XSS are the ones where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected XSS is delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.
DOM-based XSS – DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client-side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
XSS attack – more patience, more possibility of an attack
Regular XSS attack strings: –
This can be explained by the following examples:-
Custom Attack Vector – I
It has been observed that a STYLE attribute is ignored by some of the developers. They block all the miscellaneous events like on click, on mouseover, etc. STYLE attribute XSS has a limitation that it gets executed only in IE but that does not mean that it can be ignored.
There are many more victim websites which are available on the internet. It’s just a matter of expertise and you can spot the vulnerabilities. For Reflected XSS, how your input gets reflected on the entire HTML page is a matter of concern.
After successfully exploiting XSS in web applications, let’s see how an attacker can take full control of the victim’s browser using BeEF.
“The Browser Exploitation Framework (BeEF) is a powerful professional security tool. BeEF is a pioneering technique that provides an experienced penetration tester with practical client-side attack vectors. Unlike other security frameworks, BeEF focuses on leveraging browser vulnerabilities to assess the security posture of a target. BeEF hooks one or more web browsers as beachheads for the launching of directed command modules. Each browser is likely to be within a different security context, and each context may provide a set of unique attack vectors.” – http://beefproject.com/
Disclaimer: In this entire example section I have used http://demo.testfire.net as a victim site. This website is handled by a security vendor which contains a number of vulnerabilities by intention only.
BeEF framework code is available athttp://code.google.com/p/beef/downloads/list.Anyone can download and install BeEF, who requires a web server, PHP and ruby installation as pre-requisites. Backtrack (BT) has an inbuilt setup of BeEF in it. BT users can use it without any installation. In this article, I have used BT to demonstrate.
Let’s start \by narrating a simple XSS example. Below is the search filed to pass the simple XSS vector,
Now, let’s start the attacker machines. And let’s initialize the BeEF on the machine. Below is the screenshot for the BeEF login page.
After logging in into the BeEF framework, below is the first look or we can say a home page of the initialized BeEF.
At the victim side, earlier we have seen the normal XSS on demo site. Let’s apply the BeEF attack payload on the site.
Simply apply this script code in the search box of the application. The IP address is live, IP address of a machine on which BeEF is configured. Hook.js will hook a browser into BeEF.
There are many other ways which can be possible to force a victim user to click on this payload, for example by sending one image which has a malicious link behind it, or by clickjacking attack, or by email, etc.
When victims execute BeEF payload, they won’t see any changes on their side, but at the attacker’s side, they can see one ZOMBIE created.
Now the entire browser is in the attacker’s hand. He can check the system information for the created information.
The alert box gets populated at the victim’s end.
BeEF can also detect the social networking site status on the browser. Detect Social networks module will detect if the victim’s browser is authenticated to Gmail, Facebook or Twitter.
Facebook has been opened in the victim’s browser.
BeEF plugin has detected that Facebook is initiated in the victim’s browser.
BeEF can also be useful to capture the keystrokes of the victim’s browser. One test page has been opened at the victim’s browser which has one textbox field. “Secret password” has been typed as the textbox value.
At the BeEF framework, event Logs will have an entry that on victim browser user typed “secret password” in one textbox.
This was all about some tricky and advanced stuff of XSS. Sometimes one wonders what if attackers hook cyber café’s or libraries or publicly available computer into their BeEF!! All those who access these machines will suffer a lot. One should try their level best to prevent XSS by applying well encoding techniques, also do not allow insertion of any HTML tag or attribute in editable input option (i.e. textbox, list box, text area) and hidden variables. XSS attack may harm a lot, it all depends on how bad development skills of the application developer is and how good attackers skills are.
Prevent cross-site scripting attacks with AppTrana
Founder & Chief Marketing Officer, Indusface
Venky has played multiple roles within Indusface for the past 6 years. Before this, as the CTO @ Indusface, Venky created the product/service offering and technology team from scratch and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in the security industry and had held various mgmt/leadership roles in Product Development, Professional Services, and Sales @Entrust.