hidden in plain sight

where developers should never store private & secure credentials

it's all about the souce

unicode has many faces

even invisible ones

Hidden unicodez. The Login code is in the actual html file. It is "hidden" in the string "get a hint here". Multiple invisible Unicode Characters ('ZERO WIDTH SPACE' U+200B) are being used in a morse code like fashion. Using your browsers "View Page Source" may not show you the hidden characters and so won't the dev tools. Curl'in the page won't may not show it in your terminal. But opening the html file in a editor like vim will show you a representation of the invisible unicode. eg. curl ctf1.43z.one | vim - . Or simply look at the actual bytes eg ctf1.43z.one | hexdump -C To get the code one has to count the invisible chars between each visible one. Then concatenating the counts will reveal the code.

global variables are global

global variables belong to the window object

window.name transfers data cross domain

halt js to not overwrite your payload

</script> the forbidden string of javascript

The obvious vulnerable part is the name variable. As the user provided "name" get paramter will end up in the javascript variable with the same name and then be reflected in the page via document.write(name). The first problem arises as the name will be cut off after 9 characters. I don't think there is a xss payload that could fit in just 9 chars. And if there was the objective is still to steal token which should make it even harder (eg. >img src=x onerror=alert(token)>). Every global variable in javascript can also be accessed via it's window object. This makes name === window.name. But "name" is a very special javascript variable as MDN says "The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names." Other domains can set the name variable for another site. This can be used to do cross-domain messaging see https://twitter.com/h43z/status/1133799520419110912. With this knowledge you can upload code on any domain eg. https://editor.43z.one/4yn95 (which is a tiny version of jsfiddle or jsbin aka a live editor, append /i to the url to open the non editor version or click the "open" button). The javascipt sets the window.name and redirects to the ctf2.43z.one domain. The next problem is with line 9 of the ctf name = `!` this sets the name variable and therefore overwrites the window.name from before the redirect the payload will not be written to the DOM. To solve this one somehow has to stop line 9 from ever executing. And what better way to stop the name variable to ever be set than to crash the whole javascript block. As ctf2 has some good server side filtering in place (`,'," will get removed from string) the last resort is the forbidden javascript string of "</script>". Within a javascript file a variable can not hold the string "". Go try it for yourself let myVar = "" it will throw an error as the parser gets confused. What you can have though is an escaped or concatenated version of it let myVar = "<" + "/script>". ctf2.43z.one?name= will effectively crash the whole first scri The obvious vulnerable part is the name variable. As the user provided "name" get paramter will end up in the javascript variable with the same name and then be reflected in the page via document.write(name). The first problem arises as the name will be cut off after 9 characters. I don't think there is a xss payload that could fit in just 9 chars. And if there was the objective is still to steal token which should make it even harder (eg. >img src=x onerror=alert(token)>). Every global variable in javascript can also be accessed via it's window object. This makes name === window.name. But "name" is a very special javascript variable as MDN says "The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names." Other domains can set the name variable for another site. This can be used to do cross-domain messaging see https://twitter.com/h43z/status/1133799520419110912. With this knowledge you can upload code on any domain eg. https://editor.43z.one/4yn95 (which is a tiny version of jsfiddle or jsbin aka a live editor, append /i to the url to open the non editor version or click the "open" button). The javascipt sets the window.name and redirects to the ctf2.43z.one domain. The next problem is with line 9 of the ctf name = `!` this sets the name variable and therefore overwrites the window.name from before the redirect the payload will not be written to the DOM. To solve this one somehow has to stop line 9 from ever executing. And what better way to stop the name variable to ever be set than to crash the whole javascript block. As ctf2 has some good server side filtering in place (`,'," will get removed from string) the last resort is the forbidden javascript string of "". Within a javascript file a variable can not hold the string "". Go try it for yourself let myVar = "" it will throw an error as the parser gets confused. What you can have though is an escaped or concatenated version of it let myVar = "<" + "/script>". ctf2.43z.one?name= will effectively crash the whole first script block. As crashing the script won't even set the token variable we have to get it directly in our xss payload as an alert(token) will throw undefined. The final version https://editor.43z.one/jjgyd/i (would be shared with victim) window.name = ">img src=x onerror='alert(document.scripts[0].text)'>" window.location = 'https://ctf2.43z.one?name=' pt block. As crashing the script won't even set the token variable we have to get it directly in our xss payload as an alert(token) will throw undefined. The final version https://editor.43z.one/jjgyd/i (would be shared with victim) window.name = "<img src=x onerror='alert(document.scripts[0].text)'>" window.location = 'https://ctf2.43z.one?name=</scr' + 'ipt>'

to be written (no hint)

Double encoding. to be written

preg_replace('/<\w+/', '', $_get['name']);

whats a word(w) anyway

first bytes on page have great meaning

to be written