> For the complete documentation index, see [llms.txt](https://unsbotch.gitbook.io/unsbotch/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsbotch.gitbook.io/unsbotch/my-writeups/xssy/href-xss-2.md). # Href XSS 2 Href XSS 2 (medium difficulty) with 5 solutions - continuation of first easy [challenge](https://xssy.uk/lab/12), so before read this, try to solve first part and then come back.

As you solved first challenge you understand that main concept of this challenge is to reproduce:\ `javascript:alert()` in href attribute to get XSS

So firstly we should check where is our input placed?

How you can notice, our payload directly locate in href attribute, whats talking about we can trigger XSS with just simple payload `javascript:alert()` how it was in the first part.

But as expected it doesn't work, web site has a filter and just don't accept dangerous input. On this stage we should turn on our creative thinking and check, from what point does the server block our input. Let's check it char by char testing.

With the following steps we can determine break point

Now we understand that the site is triggered by the final word of "javascript" and completely filters our input. There are many ways to confuse the filter, one of the most popluar is to use newline, as the web-site think that t is a new line letter and final word will not be "javascript" he will allow to input that.

So lets try to do use it and check responce

Website accept our input and just replaced t to new line, its look that how will it work, because of t is on new line and href will not accept is a word "javascript", BUT no, it will still allow us to reproduce xss in href attribute, now we should check any filters for `:alert()?`

Amazing! no filters for payload, now paste payload in browser and look at result