231–240 of 241 posts
In Chrome, you can just do as the author says, right click and "Save Image As". Then just go to the folder where it is being downloaded, and copy/paste the file "lisa.jpeg.crdownload" to "lisa.jpeg.crdownload copy". Rename to "lisa.jpeg" and cancel the download. You now have the image. What's interesting is that you ARE actually downloading this image. It's just that they don't terminate the connection.
Earlier quoted context omitted.
I don't know about browser internals, but I would guess that the browser decodes the image once into a format that can be shown on the page (so from PNG/JPG/WEBP into a RGBA buffer) and then discards the original file. This saves a bit of memory in 99.99% of cases when the image is not immediately saved afterwards.
One cool related thing is that (I believe) modern graphics cards (even Intel) can store and use JPG blocks directly from GPU memory, so it's not necessarily beneficial in the long term to convert to RGBA in advance. Though I think no modern browser actually does this, especially given how power-cheap decoding jpeg (with SIMD) already is and how likely it is that gpu bugs would interfere.
In Chrome, you can just do as the author says, right click and "Save Image As". Then just go to the folder where it is being downloaded, and copy/paste the file "lisa.jpeg.crdownload" to "lisa.jpeg.crdownload copy". Rename to "lisa.jpeg" and cancel the download. You now have the image. What's interesting is that you ARE actually downloading this image. It's just that they don't terminate the connection.
If Web 3 is just willfully misunderstanding how computers work, I don't see a very bright future for it.
The problem with leaving connections open is that there's a limit on how many you can have on the server... I think the author has committed self-DoS :) https://en.wikipedia.org/wiki/Slowloris_(computer_security)
It would be possible to really close the connection but hack something to don't inform the client. (maybe just doing close() with SO_LINGER=0 and dropping outgoing RST in iptables would be enough)
Earlier quoted context omitted.
Those controls on a proxy are to protect against the careless and the clueless. No competent security team will rely on them to prevent ingress/egress of data or malicious code by skilled individuals.
Correct - this is an attack on the other side of the airtight hatchway (i.e., you must persuade the user to run wget in a certain fashion and run the resulting exe, and if you don't need to persuade the user you could have done something simpler). https://devblogs.microsoft.com/oldnewthing/20170130-00/?p=95...
Earlier quoted context omitted.
It would be possible to really close the connection but hack something to don't inform the client. (maybe just doing close() with SO_LINGER=0 and dropping outgoing RST in iptables would be enough)
The client would eventually time out though, right?
Earlier quoted context omitted.
Modern browsers suppress the referrer. Relying on it for functionality is not a good idea.
Fair point, you can accomplish the same by comparing the ip adress that the image request came from against your servers.
Earlier quoted context omitted.
Fair point, you can accomplish the same by comparing the ip adress that the image request came from against your servers.
Wouldn't that just mean comparing the user's public address? It is the browser that is trying to download the image from your servers.
But the concept is the same, server side check the ip of the request, and take action based on that check.