« first day (4930 days earlier)      last day (179 days later) » 

13:52
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"
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
14:08
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
 
7 hours later…
X4J
X4J
21:34
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
don't ask to ask, just ask:
https://dontasktoask.com
X4J
X4J
22:12
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
X4J
X4J
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...
X4J
X4J
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
X4J
X4J
22:27
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)
encoding is hard... PHP right now have a vuln on some languages that allows for remote code execution because of encoding mistakes
X4J
X4J
@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
X4J
X4J
@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...
X4J
X4J
22:36
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...
X4J
X4J
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
X4J
X4J
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
X4J
X4J
22:40
but why would it revert
it won't, not anymore
X4J
X4J
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
X4J
X4J
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
X4J
X4J
22:51
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
23:15
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

« first day (4930 days earlier)      last day (179 days later) »