Scribd Logo
Carica

Benvenuto in Scribd!

  • XSS Defeating Concept - Part 2

    Caricato da

    AbhishekKr
    28 visualizzazioni4 pagine
    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

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Formati disponibili

    PDF, TXT o leggi online da Scribd

    Hai trovato utile questo documento?

    Questo contenuto è inappropriato?

    Segnala questo documento
    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

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Scarica in formato PDF, TXT o leggi online su Scribd
    Segnala contenuti inappropriati
    28 visualizzazioni4 pagine

    XSS Defeating Concept - Part 2

    Caricato da

    AbhishekKr
    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

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Scarica in formato PDF, TXT o leggi online su Scribd
    Segnala contenuti inappropriati
    di 4

    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 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 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 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]

    Potrebbero piacerti anche