Your SlideShare is downloading. ×
  • Like
XSS Defeating Concept - Part 2
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

XSS Defeating Concept - Part 2


An Approach Eradicating Effect of JavaScript Events in …

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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 @ Objective: “Let Security Be Served By Web Server", dont push it on Web Developer. Part.1 Link: 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 its 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 []
  • 2. 2 XSS Defeating Concept Part2 ‘Bug As A Service’ But the main reason is when this approach is implemented in full scale (thats 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. 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>… 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 []
  • 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 its dont 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. 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>… 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 []
  • 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 []