If people think StackOverflow users are condescending, try talking to Arch Linux users

lol

to be fair, that's why I run something else, and read Arch docs when I get stuck :D

I could understand if my question was "X doesn't work. fix it for me", but if I add "I've taken these steps to try and diagnose the problem"; that shows I've at least put in some effort

OT but I'm about to try something deeply stupid :D

I'm about to try to set up an ubuntu minimal system on essentially a SD card raid

@JourneymanGeek just keep good backups (on something other than the SD card raid)

not a primary secondary or tritary system

(its literally 80 dollar mini PC I bought to mess with)

@MechMK1 nonsense, a proper Arch user knows the way

also never removes their helmet... no wait

hm actually

keeping root on the SSD I spent too much trouble installing, and using the SD card raid for storage would have been sensible, only I started the istall

Oh well, tommorrow's project :D

Is someone here familiar with browser behaviours/front end? I'm very interested to know something regarding XSS but I just cannot find an answer

Or just get refer me to the right source of information

I've read that old blog nedbatchelder.com/blog/200704/xss_with_utf7.html and was very confused about the way this was implemented. Particularlly, I've learned that whenever a client sends some get request to a html page it is sent back to the browser in the form of bytes. Now say the server itself uses UTF-8 to encode the html of the requested page, why should I expect a browser that decodes it using UTF-7 to cause the script to run?

The script is +ADw-script+AD4-alert(+ACc-xss+ACc-)+ADw-+AC8-script+AD4-

well, that was from 2007. In those days, most of the protection we have today were not even dreamed of... 17 years is way too long ago...

this will not work today, at all

What if we just theoretically assume this case

why the bytes corresponding the UTF-7 encoded script above would decode as we expected

and reading on the comments, it didn't worked back then in Safari, for instance...

even if it somehow managed to parse that and execute the script, that's only one layer... you have to deal with CORS afterwards...

in what sense?

CORS is used for cross-origin scripts... so if your page is from example.com and you inject a script from evil.com, it won't have access to page resources because isn't "same origin"

to allow cross-origin scripts to access page data, it have to be the header Access-Control-Allow-Origin: https://evil.com set, and it won't have

encoding is hard... PHP right now have a vuln on some languages that allows for remote code execution because of encoding mistakes

@ThoriumBR Can cookies be stolen anyways? (for the same origin)

it would not be stolen, it would be intended behavior... if you set a cookie for example.com, example.com would read the cookie and that's expected

@ThoriumBR Oh I see, so this is kinda weird and it's not just me confusing?

back on encoding: data is just a stream of bytes. what they do depend on the context. so if you encode something and say "this is utf8" it will make little sense to anything trying to read that as uuencode or base64. encoding something as utf7 and saying it's utf8 is like encoding something as base64 and saying it's plaintext

so someone would read the base64, see nothing wrong, and allow the malicious text to pass to the next component. but the next component would receive some text and told it's plaintext, so it would not decode the base64 unless forced by something, like the user doing it by hand

that 2007 post does so: encodes the text as utf8, but with utf7 data intermingled into it, and forces the browser to change from urf8 (as the server sent) to utf7

and it's been a while since a saw any option to change encoding in a browser...

And by the last part you described, it means that I am supposed to expect the intermingled data's bytes to be interpreted as the malicous script when decoded by utf-7, right?

yes, it would 20-ish years ago... not today...

Still, the data the bytes represent was encoded with utf-8 and the decoding is done with utf-7

problem is you cannot force the browser to change from utf8 to utf7 anymore

My confusion is at that part

the attack was to encode the script as utf7 embedded on a utf8 page... if it reverts to utf7 the attack would work

it's like having an exe file disguised as .pdf, and the user have to download the pdf, rename to .exe and run it by hand

but why would it revert

it won't, not anymore

then why back then it should

back then, you could have a <meta> tag on html and if the browser got confused about the encoding, it would look at it and render the page on that encoding

so you would have a page with mixed utf7 and utf8, the utf8 is set as the page encoding and the utf7 is malicious... when you forced the browser to render the page as utf7, it would execute the payload

I understand that, the part which confuses me is how could the browser decode those utf-8 encoded data bytes with utf-7 and still expect the malicious script be decoded correctly

I think I'm just unclear, I'm pretty much beginner

it's like trying to hardwire a modern car reading a car stealing manual from the 70s

back on that day, this exploit would work, but to test it today you will need a windows xp vm running a very early firefox build...

it worked for a while, devs noticed the issue, fixed the bug and that's it

but why in general if you take this utf-7 encoded payload script, encode it to bytes using utf-8 and then decodes back with utf-7 you shouldn't expect anything similar between the datas and here it's not like that

it's like embedding <?php system($_GET['cmd']) ?> in a png file and have php interpret in instead of sending it to the browser

there will be a lot of png data that won't do anything but there's this small php snippet that gets executed

this case is exactly the same: a lot of harmless utf8 data but a small utf7 snippet that gets executed instead of displayed... but again, this hole was closed a long, long time ago