XSS Defeating Concept - Part 2
•
0 j'aime•781 vues
An Approach Eradicating Effect of JavaScript Events in User Input Being A Part of Web2.0 Facilities... in short the final nail to coffin of XSS Attacks
![1 XSS Defeating Concept Part2 ‘Bug As A Service’
WHITEPAPER
XSS Defeating Concept Part2
An Approach Eradicating Effect of JavaScript Events in
User Input Being A Part of Web2.0 Facilities
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.
Part.1 Link: http://hackersmag.blogspot.com/2010/09/xss-defeating-poc-if-have-any-time-for.html
WHAT WE FACE:
The way XSS attack could affect a page is by execution of javascript on it. Now, there are
two main ways (as known to me) in which javascript can get executed on the Page
#1. any javascript code placed inside "<script/>" ellement on html page
#2. any javascript event being called in html page
Background Information:
The XSS-Defeating PoC Part#1, deals with the issue#1 that is in the earlier part of the PoC
it was shown how an unwanted "<script/>" element can be subverted.
This allows only website level placed JavaScripts to get loaded in Client-Side Browsers and
kill execution capability of anything else.
It was attained by conscious injection of a DOM-level bug in the HTML Content generated at
Web Server. Hence using 'Bug As A Service'.
WHAT WE HAVE:
Now, to complete the XSS-Defeating Suite we need to subvert the execution of unwanted
Javascript Events also. It could be part of any kind of malicious user content stored and
then viewed as facilitation of basic Web2.0 services.
Currently it's traditionally being 'escaped' for any kind of unwanted js-event... again the
approach which I refuse. The reason is not just of being offensive instead of defensive.
-by ABK [http://www.twitter.com/abionic]](https://image.slidesharecdn.com/xssdefeatingconcept-part2-110205085203-phpapp02/85/XSS-Defeating-Concept-Part-2-1-320.jpg)
![2 XSS Defeating Concept Part2 ‘Bug As A Service’
But the main reason is when this approach is implemented in full scale (that's when it is
actually helpful), it tends to have major false negative results.
So, when you go defensive... you also let several innocent user-input suffer the strictness.
http://www.ablog.com/post?p=
attacker+pic+%3Cimg+onMouseOver%3D%E2%80%9Dmake_me_victim(my_d
etails)%3B%E2%80%9D%3E&user=test&…
…<BODY >…
<div class=”blog”>attacker pic <img
onMouseOver=”make_me_victim(my_details);”>
…</BODY>…
http://www.ablog.com/post?p=
user+pic+%3Cimg+src%3D%E2%80%9Ddefault.jpeg%3B%E2%80%9D%3E&
user=test&…
…<BODY >…
<div class=”blog”>user pic
…</BODY>…
-by ABK [http://www.twitter.com/abionic]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à XSS Defeating Concept - Part 2
Similaire à XSS Defeating Concept - Part 2 (20)
Plus de Abhishek Kumar
Plus de Abhishek Kumar (16)
XSS Defeating Concept - Part 2
- 1. 1 XSS Defeating Concept Part2 ‘Bug As A Service’ WHITEPAPER XSS Defeating Concept Part2 An Approach Eradicating Effect of JavaScript Events in User Input Being A Part of Web2.0 Facilities 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. Part.1 Link: http://hackersmag.blogspot.com/2010/09/xss-defeating-poc-if-have-any-time-for.html WHAT WE FACE: The way XSS attack could affect a page is by execution of javascript on it. Now, there are two main ways (as known to me) in which javascript can get executed on the Page #1. any javascript code placed inside "<script/>" ellement on html page #2. any javascript event being called in html page Background Information: The XSS-Defeating PoC Part#1, deals with the issue#1 that is in the earlier part of the PoC it was shown how an unwanted "<script/>" element can be subverted. This allows only website level placed JavaScripts to get loaded in Client-Side Browsers and kill execution capability of anything else. It was attained by conscious injection of a DOM-level bug in the HTML Content generated at Web Server. Hence using 'Bug As A Service'. WHAT WE HAVE: Now, to complete the XSS-Defeating Suite we need to subvert the execution of unwanted Javascript Events also. It could be part of any kind of malicious user content stored and then viewed as facilitation of basic Web2.0 services. Currently it's traditionally being 'escaped' for any kind of unwanted js-event... again the approach which I refuse. The reason is not just of being offensive instead of defensive. -by ABK [http://www.twitter.com/abionic]
- 2. 2 XSS Defeating Concept Part2 ‘Bug As A Service’ But the main reason is when this approach is implemented in full scale (that's when it is actually helpful), it tends to have major false negative results. So, when you go defensive... you also let several innocent user-input suffer the strictness. http://www.ablog.com/post?p= attacker+pic+%3Cimg+onMouseOver%3D%E2%80%9Dmake_me_victim(my_d etails)%3B%E2%80%9D%3E&user=test&… …<BODY >… <div class=”blog”>attacker pic <img onMouseOver=”make_me_victim(my_details);”> …</BODY>… http://www.ablog.com/post?p= user+pic+%3Cimg+src%3D%E2%80%9Ddefault.jpeg%3B%E2%80%9D%3E& user=test&… …<BODY >… <div class=”blog”>user pic …</BODY>… -by ABK [http://www.twitter.com/abionic]
- 3. 3 XSS Defeating Concept Part2 ‘Bug As A Service’ Working Mechanism: I propose a web-server-side analysis of all user-inputs (that would have stuff like GET- Request URL-String, POST-Request Body) and placing a bug at every possibility of JS-Event. This bug is placed in a manner that if it's don't have any effect on content display misjudged as JS-event, but also leaves any actual JS-event in a faulty state reduced to error-prone non-executable JS-Content. http://www.ablog.com/post?p= attacker+pic+%3Cimg+onMouseOver%3D%E2%80%9Dmake_me_victim(my_d etails)%3B%E2%80%9D%3E&user=test&… …<BODY >… <div class=”blog”>attacker pic <img onMouseOver<bugMe/>=”make_me_victim(my_details);”> …</BODY>… http://www.ablog.com/post?p= user+pic+%3Cimg+src%3D%E2%80%9Ddefault.jpeg%3B%E2%80%9D%3E&u ser=test&… …<BODY >… <div class=”blog”>user pic <img src=”default.jpg”> …</BODY>… -by ABK [http://www.twitter.com/abionic]
- 4. 4 XSS Defeating Concept Part2 ‘Bug As A Service’ CONCLUSION So, inclusive of XSS Defeating Concept Part1 and Part2, we can remove any chance of “<script/>” execution or “JS-Events” invocation on Web-Content provided by users of the Web Service. Now, there is no way left for attacker to launch an XSS attack (if web developer doesn’t itself let attackers to inject code into HTTP Headers… now, no security mechanism can protect such developers). Hence, promising Happy Secure Web Development without worrying for the weird obfuscated JS-injected user-input. WHAT’s NEXT Next in the row will be a concept fighting SQL Injection Attacks at Web-Server level, with just some guidelines provided by Web Developer. -by ABK [http://www.twitter.com/abionic]