Why isn't this XSS working? The Next CEO of Stack OverflowPHP: if charset mismatches (htmlentities UTF-8) viewed by client as ISO-8859-1 (or vice versa)How is this XSS attack working?Why doesn't this XSS attack work?XSS - Bypass this RegExpWhy do ID attributes need stricter validation?XSS via JSON: Why does a web application not sanitize either its incoming params hash or its outgoing JSON values of malicious tags like Script?Why isn't this code running?Why does this XSS challenge require %0A to work?BeEF XSS - internal workingWhy this XSS payload doesn't work?

How can I separate the number from the unit in argument?

Car headlights in a world without electricity

How to find if SQL server backup is encrypted with TDE without restoring the backup

Planeswalker Ability and Death Timing

Is it OK to decorate a log book cover?

pgfplots: How to draw a tangent graph below two others?

MT "will strike" & LXX "will watch carefully" (Gen 3:15)?

Can I cast Thunderwave and be at the center of its bottom face, but not be affected by it?

Why do we say “un seul M” and not “une seule M” even though M is a “consonne”?

A hang glider, sudden unexpected lift to 25,000 feet altitude, what could do this?

Can I hook these wires up to find the connection to a dead outlet?

That's an odd coin - I wonder why

Loop in macOS not working

Find the majority element, which appears more than half the time

Horrendous Scope of Text

Small nick on power cord from an electric alarm clock, and copper wiring exposed but intact

How to compactly explain secondary and tertiary characters without resorting to stereotypes?

Could a dragon use hot air to help it take off?

is it possible to ice skate on an ice moon/world

Is it a bad idea to plug the other end of ESD strap to wall ground?

How to pronounce fünf in 45

Is there any pdf viewer with dark mode?

Was the Stack Exchange "Happy April Fools" page fitting with the 90s code?

Is this a new Fibonacci Identity?



Why isn't this XSS working?



The Next CEO of Stack OverflowPHP: if charset mismatches (htmlentities UTF-8) viewed by client as ISO-8859-1 (or vice versa)How is this XSS attack working?Why doesn't this XSS attack work?XSS - Bypass this RegExpWhy do ID attributes need stricter validation?XSS via JSON: Why does a web application not sanitize either its incoming params hash or its outgoing JSON values of malicious tags like Script?Why isn't this code running?Why does this XSS challenge require %0A to work?BeEF XSS - internal workingWhy this XSS payload doesn't work?










5















I'm learning DOM XSS and I have this code :



<html>
<body>
Select your language:
<select>
<script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script>
</select>
</body>
</html>


but I don't understand why this payload doesn't trigger any XSS :



t.html?default=test</option><img src=x onerror=alert(1)/>


It looks like the symbols are encoded and I don't understand why...



I took the script from https://www.owasp.org/index.php/DOM_Based_XSS so I guess it's vulnerable but I don't know how to exploit it...










share|improve this question




























    5















    I'm learning DOM XSS and I have this code :



    <html>
    <body>
    Select your language:
    <select>
    <script>
    document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
    document.write("<OPTION value=2>English</OPTION>");
    </script>
    </select>
    </body>
    </html>


    but I don't understand why this payload doesn't trigger any XSS :



    t.html?default=test</option><img src=x onerror=alert(1)/>


    It looks like the symbols are encoded and I don't understand why...



    I took the script from https://www.owasp.org/index.php/DOM_Based_XSS so I guess it's vulnerable but I don't know how to exploit it...










    share|improve this question


























      5












      5








      5








      I'm learning DOM XSS and I have this code :



      <html>
      <body>
      Select your language:
      <select>
      <script>
      document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
      document.write("<OPTION value=2>English</OPTION>");
      </script>
      </select>
      </body>
      </html>


      but I don't understand why this payload doesn't trigger any XSS :



      t.html?default=test</option><img src=x onerror=alert(1)/>


      It looks like the symbols are encoded and I don't understand why...



      I took the script from https://www.owasp.org/index.php/DOM_Based_XSS so I guess it's vulnerable but I don't know how to exploit it...










      share|improve this question
















      I'm learning DOM XSS and I have this code :



      <html>
      <body>
      Select your language:
      <select>
      <script>
      document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
      document.write("<OPTION value=2>English</OPTION>");
      </script>
      </select>
      </body>
      </html>


      but I don't understand why this payload doesn't trigger any XSS :



      t.html?default=test</option><img src=x onerror=alert(1)/>


      It looks like the symbols are encoded and I don't understand why...



      I took the script from https://www.owasp.org/index.php/DOM_Based_XSS so I guess it's vulnerable but I don't know how to exploit it...







      xss






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 25 at 10:07









      Alex Probert

      3641216




      3641216










      asked Mar 25 at 5:06









      NeolexNeolex

      10219




      10219




















          1 Answer
          1






          active

          oldest

          votes


















          12














          It doesn't work because the payload is URL-encoded.



          If you navigate to



          https://example.com/?foo=<>"


          you will see the literal characters <>" in your URL bar, but the browser has actually requested



          https://example.com/?foo=%3C%3E%22


          . That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.



          So, if you access location.href via JS, the payload in your example will be returned as



          test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E


          . This does not produce any HTML tags unless you URL-decode it first.



          Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.






          share|improve this answer

























          • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

            – Neolex
            Mar 25 at 5:53






          • 2





            There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

            – Arminius
            Mar 25 at 5:58











          • Ok ! Thanks a lot !

            – Neolex
            Mar 25 at 6:05











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "162"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206018%2fwhy-isnt-this-xss-working%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          12














          It doesn't work because the payload is URL-encoded.



          If you navigate to



          https://example.com/?foo=<>"


          you will see the literal characters <>" in your URL bar, but the browser has actually requested



          https://example.com/?foo=%3C%3E%22


          . That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.



          So, if you access location.href via JS, the payload in your example will be returned as



          test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E


          . This does not produce any HTML tags unless you URL-decode it first.



          Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.






          share|improve this answer

























          • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

            – Neolex
            Mar 25 at 5:53






          • 2





            There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

            – Arminius
            Mar 25 at 5:58











          • Ok ! Thanks a lot !

            – Neolex
            Mar 25 at 6:05















          12














          It doesn't work because the payload is URL-encoded.



          If you navigate to



          https://example.com/?foo=<>"


          you will see the literal characters <>" in your URL bar, but the browser has actually requested



          https://example.com/?foo=%3C%3E%22


          . That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.



          So, if you access location.href via JS, the payload in your example will be returned as



          test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E


          . This does not produce any HTML tags unless you URL-decode it first.



          Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.






          share|improve this answer

























          • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

            – Neolex
            Mar 25 at 5:53






          • 2





            There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

            – Arminius
            Mar 25 at 5:58











          • Ok ! Thanks a lot !

            – Neolex
            Mar 25 at 6:05













          12












          12








          12







          It doesn't work because the payload is URL-encoded.



          If you navigate to



          https://example.com/?foo=<>"


          you will see the literal characters <>" in your URL bar, but the browser has actually requested



          https://example.com/?foo=%3C%3E%22


          . That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.



          So, if you access location.href via JS, the payload in your example will be returned as



          test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E


          . This does not produce any HTML tags unless you URL-decode it first.



          Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.






          share|improve this answer















          It doesn't work because the payload is URL-encoded.



          If you navigate to



          https://example.com/?foo=<>"


          you will see the literal characters <>" in your URL bar, but the browser has actually requested



          https://example.com/?foo=%3C%3E%22


          . That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.



          So, if you access location.href via JS, the payload in your example will be returned as



          test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E


          . This does not produce any HTML tags unless you URL-decode it first.



          Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 25 at 5:53

























          answered Mar 25 at 5:47









          ArminiusArminius

          37.9k13123120




          37.9k13123120












          • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

            – Neolex
            Mar 25 at 5:53






          • 2





            There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

            – Arminius
            Mar 25 at 5:58











          • Ok ! Thanks a lot !

            – Neolex
            Mar 25 at 6:05

















          • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

            – Neolex
            Mar 25 at 5:53






          • 2





            There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

            – Arminius
            Mar 25 at 5:58











          • Ok ! Thanks a lot !

            – Neolex
            Mar 25 at 6:05
















          Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

          – Neolex
          Mar 25 at 5:53





          Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?

          – Neolex
          Mar 25 at 5:53




          2




          2





          There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

          – Arminius
          Mar 25 at 5:58





          There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.

          – Arminius
          Mar 25 at 5:58













          Ok ! Thanks a lot !

          – Neolex
          Mar 25 at 6:05





          Ok ! Thanks a lot !

          – Neolex
          Mar 25 at 6:05

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Information Security Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206018%2fwhy-isnt-this-xss-working%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Adding axes to figuresAdding axes labels to LaTeX figuresLaTeX equivalent of ConTeXt buffersRotate a node but not its content: the case of the ellipse decorationHow to define the default vertical distance between nodes?TikZ scaling graphic and adjust node position and keep font sizeNumerical conditional within tikz keys?adding axes to shapesAlign axes across subfiguresAdding figures with a certain orderLine up nested tikz enviroments or how to get rid of themAdding axes labels to LaTeX figures

          Luettelo Yhdysvaltain laivaston lentotukialuksista Lähteet | Navigointivalikko

          Gary (muusikko) Sisällysluettelo Historia | Rockin' High | Lähteet | Aiheesta muualla | NavigointivalikkoInfobox OKTuomas "Gary" Keskinen Ancaran kitaristiksiProjekti Rockin' High