If people think StackOverflow users are condescending, try talking to Arch Linux users
"I'm trying to do X and Y is happening. I've tried looking for A, B and C for errors, but couldn't figure out why Y is happening." "Read the documentation, retard"
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
(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
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-
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
What I really bothers me (since it might indicate I dont understand something) is how the utf-7 script above can be decoded with utf-8 and then decoded back to the corresponding text when it is decoded by the utf-7 (assuming the browser charset is utf-7)
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?
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
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
