XSS Defeating Trick ~=ABK=~ WhitePaper

1 PoC of XSS Patch ,-by ABK [http://www.twitter.com/abionic]

WHITEPAPER

XSS Defeating
A Trick to Subvert XSS in JavaScript enabled Browsers
Without Removing or Validating Any User Input
By, ABK [AbhishekKr]
abhikumar163 @ gmail.com
http://www.twitter.com/abionic
Objective: “Let Security Be Served By Web Server", don't push it on Web Developer.

Background Information:
Here, I’m suggesting a method using which Web Developer wouldn’t have to worry of user
input validation to prevent XSS Attack; and User wouldn’t have to block javascript on its
browsers… as this will subvert all the <SCRIPT/> not introduced by Web Developer.

I’ll be using my Web Server just to show my PoC, as I’ve already implemented the required
module in my Web Server.

I’ve been working on a Web Server ‘ABK (secure) SiteHoster’ hosted at
This project is hosted at: http://sourceforge.net/projects/sitehoster
XSS-Patch support is only present in Latest Release:
https://sourceforge.net/downloads/sitehoster/v1.0beta%20RC1/
How To Use PoC:
I have provided ‘ABK (S)SH - XSS Patch PoC.zip’ file at above location which have a
‘StartDemo.bat’ file, so you extract this ZIP file to a folder and run this Batch file to start
the PoC Demo {to run it on linux, give the ‘java –jar …..’ command in Batch file on shell
with Web-Root Path in place of %currDir% and POSIX in place of WIN32}.
Then you can browse ‘http://localhost/tweet.htm’; their enter any <SCRIPT/> you want to
test and ‘submit’ it. The clicking button ‘Read TweeTexT…’ will load your <SCRIPT/> to
Page.
You can even check for the SCRIPT saved in ‘tweet.csv’ file saved at Web-Root.
I have also uploaded PoC Video Demo:
>> as ‘ABK_XSSPatch_PoC_Video’ on SourceForge, it is 7-zipped to 1.x mb download
>> it is can also be viewed at: http://www.youtube.com/watch?v=ENiiAccY1v0

With an aim of "Let Web Security Be Served By Web Server", don't make it a
headache of Web Developer.
I'm a security enthusiast and developer who is trying to build a Web Server secured from
ground level up.


To start with enabling server with the facilities to subvert any kind of XSS attacks. For, this
I’ve implemented a trick I discovered last year for implementing security in one of my
college project. I was just waiting for a proper PoC and more testing on my part, which took
somewhat longer time due to lack of managed time.

Concept:
Browser uses ‘JavaScript Blockers’ but those services even block the legitimate <SCRIPT/>
to run.

So, here I’ve a way using which all the illegitimate <SCRIPT/> can be made inactive
automatically without use of any Blocker/Filter/Validation. So, Web Developer and Web
Browser don’t require any kind of Blocking/Filtering/Validation to implement this solution.
Since Blocking avoids execution of legitimate code also. Filtering and Validation may
sometimes not work due to advanced obfuscation of <SCRIPT/> injected.

Any attacker succeeding in injecting a <SCRIPT/> portion in your Web Content can launch
an XSS Attack.

But, no matter what kind of <SCRIPT/> is injected, that will get loaded as part of <BODY/>
tag.

So, using this method will allow activity of all <SCRIPT/> in <HEAD/> tag.

Along with that, it would make inactive all the <SCRIPT/> injected (sync/async both
modes) in <BODY/> tag.
It doesn’t require any new feature to be implemented for this, but simply uses a Bug
(facility for us) of Browsers to implement this.


Working Mechanism:
Suppose, Web-App has a page with code:

<html>
<head>
<script> function h(){alert(“this is web-dev script in HEAD Tag”);}</script>
</head>
<body>name:<div id=”fromDB” onclick=”h();”>~=ABK=~</div></body>
</html>

Now, if any attacker visiting this web-application have provided data containing ‘any
<SCRIPT/>’ to be inserted in this page.

Even then, implementing this solution web-developer needs to validate no XSS attacks
(remember our aim is leave it to Web Server).

So, suppose there was a <SCRIPT/> provided by attacker, which got saved in your DB and
will be retrieved back to <DIV id=’fromDB’/> present in <BODY/> tag. So, it would look like
something…

<html>
<head>
<script>function h(){alert(“this is web-dev script in HEAD Tag”);}</script>
</head>
<body>name:
<div id=”fromDB” onclick=”h();”>
<script>alert(‘attacker injected it, could do anything’);</script>
</div>
</body>
</html>


Wait, this is not the end 

But, this is just the Web-Page generated at server-side and handled to our Web-Server…
now our Web-Server has a module to transform it into something like this…

<html>
<head>
<script> function h(){alert(“this is web-dev script in HEAD Tag”);}</script>
</head>
<BD>
<BODY >
<script type='text/javascript'>
x=document.getElementsByTagName("BODY");
x[0].innerHTML = "name:<div id="fromDB"
onclick="h();"><script>alert('attacker injected it, could do
anything');</script></div>"
</script>
</BODY>
</BD>
</html>

then, the attackers <SCRIPT/> (which is still present there) would not execute at all.


As below, we can see the modified HTTP Response sent for a normal generated MarkUp
Page

Although, this can also be implemented at Web-Developer side using Server-Side Scripts
and took benefit of until their Web-Server don’t apply such MODs or ‘ABK (secure)
SiteHoster’ is mature enough to suit all their requirements.

Now, here even if any <SCRIPT/> is fetched asynchronously and injected in <BODY/>
part… even that would remain inactive inside the already formed container.

PATCH#2
This disabling <BODY/> inline <SCRIPT/> was noticed failing in cases, user gives
input like <image src=”a.gif” onclick=”javascript:maliciousFunctions(args);”/>

So, here I just used another bug; in all such cases which would not effect in
content display of Page, but just disable these attempts.

It simple replaces all body ‘javascript’ data with ‘javascript<span/>’ and gets
lucky.

CONCLUSION
Currently, my server is not mature enough to serve all kind of Web Applications… but this
approach is not just server-dependent.

So, contributors for other Servers could write a module for other servers manipulating the
Final Web-Page data sent to User in above required manner.

And until then, Web-Developers can themselves introduce a module in their Web-Application
to handle all requests and response… thus just a single point would be able to serve the
purpose.

You can mail me at above e-mail ID if you face any issue in implementing the method, or
think it is flawed in any way.

XSS Defeating Trick ~=ABK=~ WhitePaper

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à XSS Defeating Trick ~=ABK=~ WhitePaper

Similaire à XSS Defeating Trick ~=ABK=~ WhitePaper (20)

Plus de Abhishek Kumar

Plus de Abhishek Kumar (16)

Dernier

Dernier (20)

XSS Defeating Trick ~=ABK=~ WhitePaper